In recent years in Italy the development of Fiber To The Home technology has finally started, with the public traded company OpenFiber doing most of the infrastructure work. The network is then resold through the many partner providers.
It has been the case also for other countries in the world and almost everywhere the standard for residential optical connection is GPON. [This research by Pierre Kim is extremely useful to better understand the standard and the network topology](https://pierrekim.github.io/blog/2016-11-01-gpon-ftth-networks-insecurity.html) and also provides a nice overview of its security.
This type of connection requires different equipment than ADSL/VDSL and thus specific GPON gateways are now available on the market, either as standalone devices (GPON to SFP, GPON to RJ45) or as fully featured CPEs.
Technicolor, along with Alcatel-Lucent, Nokia and Huawei are the leading manufactures of these devices and the suppliers for ISPs. Unsurprisingly, many different devices from even different companies have the same components and sometimes even share some software stack: below is a noncomprehensive table of confirmed and suspected devices having the same common problems described later. Apparently there's also a reseller called Zhone that customizes the same CPE for some ISPs. Eltex might be another one.
| CODE | Country | ISP | Manufacturer | Model | SSID Format |
| ETIS | United Arab Emirates | Etisalat | Nokia | [G-240G-C](https://static1.squarespace.com/static/519f78cae4b0cc7b837ad9d2/t/5b339694f950b7fadb98098c/1530107541390/Nokia_7368_ISAM_ONT_G-240G-C_for_Optical_LAN_Data_Sheet_EN.pdf) | `ONT%fs2.4G` |
| ATEB | Saudi Arabia | GO Telecom | Unknown | Unknown | `GO_WiFi_%4s` |
Different enclosures or slight variants of the same board can be identified by looking at the [documents published by Nokia for the FCC](https://fccid.io/2ADZR).
* https://fccid.io/2ADZRG240WG
* https://fccid.io/2ADZRG240WE
* https://fccid.io/2ADZRG241W-A
* https://fccid.io/2ADZRG240WB
* https://fccid.io/2ADZRG240WA
* https://fccid.io/2ADZRI240WA
* https://fccid.io/2ADZRG240WZA
* https://fccid.io/2ADZRG240WE
## Pictures
## Models
The models which share the same firmware, or at least part of it, according to some code we reversed, are:
The board itself has 128MB flash and 256MB RAM. An additional SPI Flash of 16MB is soldered on the back of the board.
`/proc/mtd`
```
mtd0: 00080000 00020000 "cferom"
mtd1: 00080000 00020000 "nvram"
mtd2: 00c00000 00020000 "cfg"
mtd3: 00680000 00020000 "jff2_0"
mtd4: 00680000 00020000 "jff2_1"
mtd5: 02600000 00020000 "rootfs0"
mtd6: 02600000 00020000 "rootfs1"
mtd7: 01a00000 00020000 "log"
mtd8: 0237b000 0001f000 "0"
mtd9: 0000000c 0001f000 "0"
mtd10: 00a0d000 0001f000 "1"
mtd11: 01702000 0001f000 "0"
mtd12: 0237b000 0001f000 "0"
```
It seems to be using the CFE bootloader, which is [described here](https://raw.githubusercontent.com/Noltari/cfe_bcm63xx/master/bcm963xx_bootloader_appnote.pdf).
`/proc/cpuinfo`
```
system type : 968380GERG
processor : 0
cpu model : Broadcom BMIPS4350 V8.0
BogoMIPS : 598.01
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 1
cpu model : Broadcom BMIPS4350 V8.0
BogoMIPS : 606.20
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
```
The main SoC and the GPON module are made by Broadcom.
Both 2.4Ghz and 5Ghz wifi are supported and seems to be made by Quantenna. They seem to be powered by the Topaz chipset, [which has recently been added to the Linux Kernel](https://patchwork.kernel.org/patch/10630331/) for which there's a lack of binaries in `linux-firmware` but there's an [interesting discussion here](https://patchwork.kernel.org/patch/10643357/). Additional code might be present in the [Google Fiber repository](https://gfiber.googlesource.com/kernel/skids/+/master/drivers/topaz).
There are already known backdoors like described [here(https://www.websec.ca/publication/Blog/backdoors-in-Zhone-GPON-2520-and-Alcatel-Lucent-I240Q). While my device does not have the SSH service exposed it does have telnet on port `23`. A root shell can be easily obtained by simply logging in via `ONTUSER:SUGAR2A041`.
Once logged in it easy to find that the manufacturer actually committed all specific customizations to every device. There are indeed plenty of files not useful for this specific model, a dozen different web interfaces and configuration files for any ISP on the table above. There's also a lot of debugging mess, like this one:
`/bcm/script/add_asb_user.sh`
```
#!/bin/sh
#add debug ONTUSER and config ONTUSER env, add by xufuguo, 20120808
#Note: don't chang PS1, bob calibration software need terminal prefix just "#"
#update for R30 read-only rootfs, modify by xufuguo, 20130816
exist=no
preconfig=no
home_dir=/configs/home
while read LINE
do
temp=$(echo $LINE | awk -F : '{print $1}')
if [ "${temp}" != "ONTUSER" ]; then
continue
fi
exist=yes
break
done < /etc/passwd
# BRCM use confignew.cfg
if [ ! -f /configs/config.cfg -a ! -f /configs/confignew.cfg ]; then
preconfig=yes
fi
if [ "${exist}" = "no" -o "${preconfig}" = "yes" ]; then
rm -f /configs/etc/*+ #clean up temp files
[ -d ${home_dir} ] || mkdir -p ${home_dir}
sed -i -e '/ONTUSER/'d /configs/etc/passwd #del username,passwd,config file
sed -i -e '/ONTUSER/'d /configs/etc/shadow
rm -rf ${home_dir}/ONTUSER
op_id=$(ritool get OperatorID | awk -F : '{print $2}')
That's how bad it is and [Wind experienced it first hand when in 2017](https://www.macitynet.it/la-rete-fibra-wind-bloccata-un-malware-mette-uso-modem/) a wrong update exposed the telnet port on the internet allowing the infamous BrickerBot to turn almost 20000 CPEs in total electronic garbage (well, more than they were before). Yep, they had to freely ship a new modem to everybody and people suffered multiple days of total downtime.
## Configuration tools
There are two useful configuration tools called `cfgcli` and `ritool`.
`cfgcli` is used to configure all the properties of the user in an XML like structure. It can be used to retrieve VOIP, PPP, TR69, SLID and many more information.
These OEM binaries manage this data through a lib called `/lib/libri.so` which interacts with a device `/dev/ri_drv`. This device is controlled by a proprietary Broadcom kernel module called `/bcm/bin/ri.ko`. What this module does is basically reading and writing values to an I2C EEPROM.
The most important ones are `G984Serial` which is the serial value actually used in all the system and `OperatorID` which defines the branding of the modem. `PartNumber` defines the actual board model.
It's possible to brand the modem for Mexico's Axtel. To force the modem to reconfigure after a change a factory reset is necessary. To do so press the shortest button on the back for at least 10 seconds while it is powered on.
While it is impossible to know in advance, most of the time this kind of device generates a unique password following a hardcoded algorithm. It is extremely rare for the manufacturer to manually insert secrets in every device and the automatic generation solution may be secure given that the algorithm is seeded by data unknown to a potential attacker.
Bad examples include passwords generated based on MAC Address while password based on serials are often better, given that an attacker has no way to know it and it is not derived from other known data. In this case however the serial is partially predictable and partially known to an attacker thanks to its inclusion in the SSID so a secure implementation should use something else.
Note also that a WPA Key always comprised only of ten digits can be cracked using [Hashcat](https://hashcat.net/hashcat/) with a GTX 1070 in less than 10 hours.
## Where to Look
[There's an interesting file in `/etc/preconfiguration_global.xml`](https://git.lsd.cat/g/nokia-keygen/raw/master/xml/preconfiguration_global.xml). It contains the automatic configuration instructions for every ISP supported.
By looking at other files and binaries, upon parsing this XML do the following:
* For every ISP there's a root element with its code: `ITAX` is Wind Italy
* Every nested element is a configuration section. Useful information includes TR-69 URLs and credentials, PPP credentials and WIFI SSID and Key
* A single line can contain a static value or a string that map to a specific function in a configuration binary:
-`fri` value is the function
-`v` value is an optional argument
[The responsible binary](https://git.lsd.cat/g/nokia-keygen/raw/master/bin/cfgmgr) is `/sbin/cgfmgr` which starts at boot and stays alive during all the normal device operation.
## Reversing
By reversing this binary and using `ritool` to perform dynamic tests it's pretty easy to understand how things work.
Essentially the various fields inside the XML file may be hardcoded or generated using some runtime code and configurations.
Often there is something which looks like a format string and then another attribute which specifies how to use that string.
We leave to the reader the pleasure of reversing the XML and the binary for a complete and detailed understanding of what is going on (BONUS: lots of cleartext hardcoded credentials can be found during this process...)
First of all, these are not exactly format strings. By inspecting the code/doing test with `ritool` it's immediate to understand that the meaning of the most used"format strings" is the following:
- %4s: lower 2 bytes of the serial code, represented in hex
- %4m: lower 2 bytes of the MAC address, represented in hex
- %8m: lower 4 bytes of the MAC address, represented in hex
The point of our research is to find cases where WLAN passwords can be efficiently cracked by knowing public informations such as the SSID and the MAC address.
An immediate case that doesn't even require further reversing is when the WLAN inside the XML uses the lower bytes of the MAC address as a password.
This happens for 3 WLANs described inside the XML.
The other case that we will publicly present is when the SSID contains a piece of the serial code and the password is generated using `gen_mgntlongpw_and_wanpw` function.
Essentially we are now talking about all the WLANs which use a format string containing `%4s` combined with `genssidfmt` for the SSID generation and `gen_mgntlongpw_and_wanpw` for the password generation.
This also works for the WLANs which have `fri=alhn_genssid1` and use `gen_mgntlongpw_and_wanpw` for the password generation.
The actual inputs are only the OUI (available in the XML and also easily bruteforceable) and a serial number, since the other two parameters are just destinations to store the generated passwords.
The code is pretty straightforward, at first it generates two strings and computes their MD5 hashes.
Then it concatenates the first hash and the first 3 bytes of the second, and encodes all of this as base32. The result is truncated and represents the first password.
For the second password instead it generates two numbers using the bytes of the second MD5, which will be used as lower and upper bits of a 64 bit integer. The password is simply this number modulus `0x20x540be400`.
## PoC Keygen
With this information we can write a PoC script that can produce a wordlist to efficiently crack a vulnerable SSID.
We can quickly check this script against a test network. `SSID=INFINITUMF2B0_2.4-3` and `PASSWORD=3345321247`.
```
./keygen.py INFINITUMF2B0_2.4-3 | grep 3345321247
3345321247
```
This is a very basic and partial PoC.
We considered it to be enough to prove the point without publishing too many sensible things, but extending this keygen to handle all the possible vulnerable SSIDs, and the WLANs which use hardcoded password is pretty trivial.
## Wind Keygen
By analyzing listings on eBay and other sites with high-resolution pictures it was possible to build a small statistical set for the serial of devices distributed in Italy by Wind. The first byte of the serial is almost always `B1` with a few exceptions of `F2`.
In most cases also the second byte has just a dozen possibilities. While we're not going to release the dataset, it was possible, using the previous assumptions, to build a keygen with just a few different outputs, sorted by probability.
The number of possible attempts should be low enough to just try manually connecting without the need of aircrack and offline cracking.
[Wind Keygen](https://lsd.cat/keygen/)
## Unlocking
Before everything dump your config:
*`cfgcli dump`
*`ritool dump`
If you don't you may break your internet connection by losing your SLID or break your VOIP number by losing the credentials.
For those looking to use a branded CPE with a different GPON ISP here are the steps:
* If neither telnet nor SSH is available try to enable one of them via the web interface in the `Access Control` page. Admin credentials are all in [preconfiguration_global.xml](https://git.lsd.cat/g/nokia-keygen/raw/master/xml/preconfiguration_global.xml).
* Login via telnet or SSH using `ONTUSER:SUGAR2A041`.
* Run `ritool set OperatorID ALCL`.
* Press the reset button for 10 seconds and wait for a reboot.
* Connect either via cable or using the preconfigured password. SSID will be `ALHN-%4s`
* Router ip will be `192.168.1.254`
*`ONTUSER` backdoor will always be there. User and password for the web panel are `AdminGPON:ALC#FGU`. Also there's a lower privileged user called `userAdmin` with the same password as the wifi.
## Acknowledgements
Almost a decade ago a group of unknown Italian researchers broke the algorithms for two of the local main ISP, Telecom and Fastweb. At the time I was a kid and, while it looked like black magic to me, I still found their research inspiring.
There's also some interesting [work on the topic](https://haxx.in/upc_keys.c) by [blasty](https://twitter.com/@bl4sty).
## Contributions
Contributions of other models, ISP branding and sample data of SSIDs, serials and keys are welcome. Feel free to open an issue or contact us via email.
