GPON Home Gateway RCE threatens tens of thousands users

Artem Metla
Tenable TechBlog
Published in
6 min readFeb 27, 2019



It’s been almost a year since vpnMentor published its blog in May 2018 that identified two interesting issues (CVE-2018–10561, CVE-2018–10562), which can be combined to completely compromise GPON home routers. The vulnerabilities have gotten a lot of attention, and were weaponized by a bunch of botnets like Mettle, Muhstick, Mirai, Hajime, Satori etc. That blog felt like an unfinished story, so I’ve decided to poke GPON Home Gateway a little more.

As usual, my curiosity took me the long way to discoveries. In general, GPON Optical Network Terminal (ONT) devices are distributed to end users by their Internet Services Providers (ISPs), to act as end points for Internet access. My research has found at least five vendors producing potentially vulnerable GPON Home Gateways. Searches on Shodan and Zoomeye show a huge number of potentially vulnerable devices:

You’re probably asking, how could that happen? Despite the fact that the devices are produced by multiple independent vendors, the devices utilise similar firmware. Any differences in the firmware are caused by modifications made by each vendor, and oftentimes they are ordered by the ISPs. However, the core of the firmware stays the same. I was able to confirm this by analysing multiple firmwares used by different ISPs. Let’s compare the contents of the web root folder from different firmware packages:

The firmware for GPON Home Gateways is usually not accessible via vendors’ websites, it’s distributed by ISPs and oftentimes either updated automatically without user action, or not updated at all.

A telnet backdoor to warm up

Usually, we need to have a debugger attached to the running services in order to perform serious bug hunting. This means that we have to get an access to router’s console. A full emulation of GPON Home Gateways’ firmware with Qemu could make you sweat. I just decided to buy a real device on eBay. The device I’ve got is produced by Alcatel-Lucent. It is I-240W-Q GPON Home Gateway based on an ARM processor (firmware compiled for armv5tel): Feroceon 88FR131 rev 1 (v5l).

The port scan of Alcatel-Lucent I-240W-Q GPON Home Gateway reveals some peculiarities. The device executes Telnet and SSH services to provide remote interface for ISPs, probably for remote management and troubleshooting. However, those interfaces are firewalled by default. The nmap scan indicates 22/TCP and 23/TCP ports as filtered:

The whole thing looked a bit shady, so I’ve decided to browse the WebMgr binary, and look for a backdoor code. The WebMgr is a part of GPON Home Gateway’s firmware responsible for the web administrative console of the device. From that brief review, the following blocks from “webLoginCheck” function looked promising:

Because the webLoginCheck function processes “ote” and “otd” commands, in addition to handling authentication, we can use these commands to enable or disable the backdoor code.

By sending a simple HTTP GET request we can actually turn off the firewall for a telnet port:

By sending the following command, we can re-enable a firewall filtering:

Next, we need to figure out credentials. We need them to login via telnet. Of course, we can try to brute force the “login/password” pair, but let’s do it the reverse engineering way by looking at “/bin/telnetd”:

The hardcoded password pairs “root / admin” and “root / huigu309” worked like they should and provided access to the shell:

The same credentials for “root” user are also hardcoded into the Dropbear (SSH) service.

Exploiting authenticated buffer overflow in the web interface

Now that we have an access to the router’s console, it’s time to look at usage of unsafe C functions. In a lot of cases, we can start by calling to those and trace the user’s inputs back to HTTP requests processing routines. We all know this function:

is used to copy a string into the destination array. However, we should always keep in mind that strcpy() does not check buffer length and may overwrite a memory zone contiguous to the intended destination. This is the exact behaviour that we want to leverage in order to trigger a stack buffer overflow (BoF).

Let’s have a look at a piece of subroutine used to process “usb_Form” related HTTP requests:

From the IDA Pro output, we see that a bunch of parameters are vulnerable: “ftpusername”, “ftppassword1”, “ftpdirname”, “clientusername”, “clientpassword”, “urlbody”, “webdir”. Users’ input provided via HTTP request is copied by strcpy() without any check of buffer length.

Let’s execute the following curl command to trigger a DoS condition and force the GPON router to reboot:

In order to make this exploit work, we still have to rely on authentication bypass tricks (CVE-2018–10561) or get a “login/password” pair for Web Administration Interface.

We can execute a couple of security level checks against the “WebMgr” binary to find the easiest way of exploitation and turn the PoC into fully functional exploit:

As a result, we have a partial address space layout randomization (ASLR) enabled on the GPON router. Positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions are randomized. But the heap is not randomized! If we can find a copy of the request stored on the heap, we can jump to it via “pc” register modification and trigger shellcode execution. The heap of “WebMgr” is executable and looks promising:

Eventually, we ended up with the following code, which allows us to execute the “tftpd” service as a result of successful ASLR bypass via triggering shellcode stored on the heap:

Exploit execution looks like this:


In the Internet-connected world, a router is the most important device on any network. Oftentimes, home router is the only border device which separates our private network and life from the internet. This small, blinking box tackles persistent external attempts to penetrate your network and keeps your secrets safe. To maintain this protective border, router firmware and hardware both need constant upgrades and improvements. Only updated devices can effectively counteract attackers’ attempts. An old, outdated device is low hanging fruit for a modern attacker and is a serious risk to your business and personal privacy.

According to recent studies, conducted by Cyber-ITL researchers, most routers do not utilize software security features like ASLR, Stack Canaries, and Non-executable stack. Unfortunately, Alcatel-Lucent I-240W-Q GPON Home Gateway is not an exception from this rule. The lack of software security features in combination with poor coding practices made it possible to run an old-fashioned stack smashing attack to take a full control over the device.

Nokia is the official supplier of Alcatel-Lucent I-240W-Q GPON Home Gateways nowadays. We’ve reported all findings to Nokia’s Security Team per our vulnerability disclosure policy and they have already released a patch for all of the affected devices.