Few months after CVE-2015-0558 full disclosure I was contacted by our reader Kara Davis who identified the same WPA key generation algorithm in the model P.DG A4000N, distributed by Portuguese ISP, MEO. Such routers can be recognized for their ESSID and MAC addresses. The ESSIDs are normally following this pattern: ADSLPT-ABXXXXX and the mac addresses are corresponding to the Pirelli brand. When I verified the information, I gave a chance to dump the firmware and see whether the old vulnerabilities (CVE-2015-0554, CVE-2015-0558) were also in there. From testing and evidence we concluded the existing PoC could also generate the default WPA password for this model. Simple changes such as generating from a different mac address interface and reducing length from 10 to 8 chars had to be implemented. However, the algorithm used was evidently the same as in P.DG A4001N distributed by Arnet in Argentina. Kara Davis and I agreed into a responsible disclosure and decided to investigate further.
First of all, we dumped out the firmware image from the router via an OS command injection in the telnet service. After, we managed to do so, same algorithm was eventually found in there. On top of that, the same unauthorized access was discovered as well. Likely this router has plenty of vulnerabilities as well, simply we decided to stop with this model.
Summarizing, the router P.DG A4000N deployed by MEO Portugal presents the following flaws:
- Weaknesses on the default WPA key generation algorithm
- OS command injection through the telnet service concluding with root in the box
- Unauthorized access to almost all the HTML code
Identifying hardware components
Digging into the hardware components can be really useful to achieve information about our target. When we try to extract memory contents or JTAG the device, we do have to know its characteristics and which attacking points we eventually got. Debugging interfaces such as UART or JTAG are commonly in many embedded devices. The majority of routers have a UART port and depending on the SoC also a JTAG port.
Unfortunately, our target only has a UART port. After hooking up some cables into the UART pins, we are able to find out information about how the OS and how the booting process is going on. For instance, when we try to “uart” a device, first we try to access to a shell or command line environment. Moreover, we can recollect useful info such as different Flash memories names which the firmwares could be stored in, the base address where the OS is loaded into, which CPU (SoC) we are dealing with, what WiFi module the device is comprised of and things like that. Zooming the picture in, the reader will recognize the main components in this router. The most important components are the SoC, Flash and debugging interfaces. The System-on-Chip(SoC) is a Broadcom bcm6328. The flash is a Macronix mx25l12845emi-10g which can be read out without desoldering with any decent EEPROM programmer. Fortunately, another flaw allowed me to dump the whole firmware image much faster and easier.
The most relevant lines from the booting process are shown below:
CFE version 1.0.37-106.24 for A4001N TEF 0001 BCM96328 (32bit,SP,BE) Build Date: mar set 6 12:27:14 CEST 2011 (marcodl@localhost) Copyright (C) 2000-2009 Broadcom Corporation. HS Serial flash device: name MX25L128, id 0xc218 size 16384KB Total Flash size: 16384K with 4096 sectors Chip ID: BCM6328B0, MIPS: 320MHz, DDR: 320MHz, Bus: 160MHz Total Memory: 33554432 bytes (32MB) Boot Address: 0xb8000000 Board IP address : 192.168.1.1:ffffff00 Run from flash/host (f/h) : f Default host run file name : vmlinux Default host flash file name : bcm963xx_fs_kernel Board Id (0-4) : 963281TAN Base MAC Address : 84:26:15:ae:bc:13 PSI Size (1-64) KBytes : 64 Enable Backup PSI [0|1] : 0 System Log Size (0-256) KBytes : 0 Main Thread Number [0|1] : 0 *** Press any key to stop auto run (1 seconds) *** Auto run second count down: 0 Booting from only image (0xb8010000) ... Code Address: 0x80010000, Entry Address: 0x80014230 Decompression OK! Entry at 0x80014230 Starting program at 0x80014230 Linux version 2.6.30 (cx1giordan@thor) (gcc version 4.4.2 (Buildroot 2010.02-git ) ) #1 Mon Jan 21 17:14:53 CET 2013 HS Serial flash device: name MX25L128, id 0xc218 size 16384KB kerSysEarlyFlashInit: bootCfeVersion has value cfe-A4001N-V0001 963281TAN prom init CPU revision is: 0002a075 (Broadcom4350) Determined physical RAM map: memory: 01f00000 @ 00000000 (usable) Zone PFN ranges: DMA 0x00000000 -> 0x00001000 Normal 0x00001000 -> 0x00001f00 Movable zone start PFN for each node early_node_map active PFN ranges 0: 0x00000000 -> 0x00001f00 Kernel command line: root=31:0 ro noinitrd console=ttyS0,115200 Serial: BCM63XX driver $Revision: 3.00 $ ttyS0 at MMIO 0xb0000100 (irq = 36) is a BCM63XX ttyS1 at MMIO 0xb0000120 (irq = 47) is a BCM63XX bcmxtmrt: Broadcom BCM6328B0 ATM/PTM Network Device init started: BusyBox v1.00 (2013.01.21-16:17+0000) multi-call binary BusyBox v1.00 (2013.01.21-16:17+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. ===== Release Version PDGA4000N_PT_4.06L.2.2828 (build timestamp 130205_1145) == === SerialNumber: 47502E0021746 SSID: ADSLPT-AB37495 WPA Key: 78leqnej WPS Device PIN = 14258671 Setting SSID: "ADSLPT-AB37495" BCM96328 Broadband Router Login:
For further information of the booting process through UART port: bootlog_pirelli_portugal.
Extracting the firmware image via OS command injection
The router is distributed with telnet enabled by default with the usual admin credentials although there is a constrained shell where not much can be done. Looking into the commands available we do not find much help, therefore I decided to try some simple command injection and in matter of seconds I got into the Busybox ash shell. Once achieved root rights, we noticed that netcat was available in the OS. Having already netcat and root right we easily transfer the mtdblock which stores a backup of the firmware image. To do so, a simple combination of cat and netcat allows us to correctly dump the firmware into our box. At this point the firmware is exposed and the mtdblocks and libraries are completely accessible for a firmware analysis. Any router based on BCM96328 could be affected too as well as many other Broadcoms. The security in routers is quite poor indeed.
To dump the firmware open up several shells. From the router:
$ telnet 192.168.1.1 > ping a; sh # cat /dev/mtdblock1 | ncat -l -p 6666
From our box:
$ nc 192.168.1.1 6666 > me0firmware.bin
The firmware image can be found at the new repository exclusively for firmware images deployed by international ISPs. Please help us!
Default WPA key generation algorithm
Since I have already explained this point at my last entry. It would result repetitive explain it again. Please take a look at the last entry. Once unpacked the firmware image by using Binwalk, we are able to load some libraries and binaries into IDA Pro. An ESSID generation is seen before generating WPA keys. Clearly the ESSID is generated from the mac address as well as the WPA key. Take a look at the highlighted lines into the MIPS assembler code. You will realize how the mac address is definitely involved in such generations.
loc_1E7D8: addiu $v0, $fp, 0x30+var_10 lw $a0, 0x30+arg_0($fp) la $v1, 0xC0000 addiu $a1, $v1, (aWl0 - 0xC0000) # "wl0" move $a2, $v0 la $v0, wlmngr_getPBSHwAddr move $t9, $v0 jalr $t9 ; wlmngr_getPBSHwAddr nop lw $gp, 0x30+var_20($fp) lbu $v0, 0x30+var_E($fp) andi $v0, 0xF sll $v1, $v0, 24 lbu $v0, 0x30+var_D($fp) sll $v0, 16 or $v1, $v0 lbu $v0, 0x30+var_C($fp) sll $v0, 8 or $v1, $v0 lbu $v0, 0x30+var_B($fp) or $v1, $v0 li $v0, 0x14F8B589 mult $v1, $v0 mflo $a1 mfhi $a0 sra $a0, 13 sra $v0, $v1, 31 subu $v0, $a0, $v0 la $a0, loc_186A0 mul $v0, $a0 subu $v0, $v1, $v0 move $v1, $v0 lw $v0, 0x30+var_18($fp) addu $v0, $v1, $v0 sw $v0, 0x30+var_14($fp) la $v0, 0xC0000 addiu $v0, (aAdslptAb05d - 0xC0000) # "ADSLPT-AB%05d" lw $a0, 0x30+arg_4($fp) move $a1, $v0 lw $a2, 0x30+var_14($fp) la $v0, sprintf move $t9, $v0 jalr $t9 ; sprintf
The rest has nothing to be explained again. To sum up, WPA keys are easily recovered by an adversary as I explained in the last entry.
Unauthorized access via HTTP
Meanwhile we were checking one by one the previous problems in other Pirelli routers, we rapidly checked if the WAN access was enabled by default as happened in CVE-2015-0554. To remember readers, both Spain and Argentina had enabled the WAN interface resulting vulnerable from outside. In Portugal (un)-fortunately the WAN access was completely disabled by default. At this point, we are capable of concluding that either our firmware version was disabled or all versions are disabled. This vulnerability can be only exploited within the internal network (LAN). Author has not been capable of exploiting the router remotely with the version FW : PT_4.06L.2.2020 HW: R01.
Problems and models affected
I wanted to do a responsible disclosure, therefore I contacted the Portuguese ISP MEO and was surprised by a quick reply via Twitter, indicating to forward details to a specific person which I immediately did. Unfortunately from this day, I am still waiting for a reply. ADB/Pirelli and Arnet are aware of the vulnerability since 2014. Eventually, I decided to do full disclosure in the new model identified to speed up fixing the problem and/or replacing the affected routers for avoiding intrusions. Once again, neither the ISPs nor the manufacturer have shown interest in discussing the problem after several contacts.
The vulnerability is considered quite serious, a malicious attacker within the WiFi range can calculate the default password and gain access to the network, compromise and use it for malicious purposes.
I strongly recommend everyone using affected units to immediately change their default WPA password.
The models identified as vulnerable are:
- P.DG A4001N – SSID: Wifi-Arnet-XXXX – Arnet Argentina
- P.DG A4000N – SSID: ADSLPT-ABXXXXX – MEO Portugal
More countries will be disclosed soon. Pirelli has made the same mistake around the world.
2015-04-01 Confirmed that the Portuguese ISP “MEO” uses the same algorithm
2015-04-05 Send a message to @MEOpt via Twitter @enovella_
2015-04-05 I got response in matter of minutes \o/
2015-04-05 I send an email to email@example.com , stating the reference 3-78405621289 in email subject
2015-05-07 Full disclosure
This proof-of-concept and many Pirelli default key generation algorithms can be found at my Bitbucket repository. Looking at the first picture of this entry, the reader can prove as the WPA keys can be recovered in matter of seconds for any router with default settings. Checking the mac address in the sticker attached to the router, an adversary will have to tweak the LAN mac address with the WLAN mac address which is public. The difference is just minus 1 (-1). Both Pirelli Arnet and MEO have been combined in the same program. From now on, the Python script called pirelli.py will be responsible for generating such WPA keys.
Disclaimer: Be ethical! I am not responsible for what you do with this script
$ python pirelli.py -b 84:26:15:ae:bc:14 [+] MAC : 84:26:15:ae:bc:14 [+] WPA key : 78leqnejoj SSID: WiFi-Arnet-XXXX (Argentina) [+] WPA key : 78leqnej SSID: ADSLPT-ABXXXXX (Portugal)
Please Pirelli, if you read this please contact with me. You would make me quite happy with some Pirelli tyres for my racing bike