Hidden functionality

Hidden functionality is a class of software weakness resulting from extraneous undocumented or unspecified behavior that is built into a program. In benign forms, it could be a fun easter egg or cheat code in a video game; in more serious contexts, it could mean a backdoor left by a developer or debugging functionality that was left in production.

Depending on the application and the functionality, it could have drastic consequences ranging from unintended information leak, denial of service to remote code execution.

In this lesson, you will learn about the dangers of hidden functionality and how to protect your application from such issues by having proper review and audit procedures in the SDLC (Software Development Life Cycle). We will step into the shoes of Matt, a father in charge of the devices in his home, who discovere an unintentional backdoor built into his router by his ISP (Internet Service Provider) while he was monitoring the network traffic of his own home, which he realized could put his entire neighborhood or even city at risk.

One morning, while digging around his home network setup, Matt decided to sniff some traffic on an ethernet port in his optic fiber modem, which is connected to his home router. Both devices were provided by his apartment's residential ISP, LuckyNetCo, and installed long before his family moved in. His ISP has been giving him some trouble with slow speeds, intermittent internet outages, and rumors of security breaches.

He intercepts the traffic between the modem and the router using a small, embedded Linux device with two ethernet ports, running the classic tcpdump. Then he noticed some very suspicious packets:

His keen eye noticed the IP address of his router straight away (192.168.1.1), which was contacted by an IP he's never seen before (100.64.10.2). A quick DuckDuckGo search revealed that the 100.64.0.0/10 IP space is a non-internet routable address space reserved for Carrier-Grade NAT commonly used by ISPs.

He noticed that the IP was sending a request to the http-alt port of his router (which on a quick grep of /etc/services he realized it was port 8080), and hitting the info_check route with some parameters such as c=ifconfig and f=/var/lib/dhcp/dhcpd.leases. Check out the line that has GET /info_check?c=ifconfig in the terminal above.

Was his ISP spying on him? From his Linux experience, he knows that ifconfig is a command to check network addresses and statistics, while the dhcpd.leases file would contain sensitive information about all devices in his home connected to the router, such as the name of his daughter's iPad (which is actually just her name), and the MAC address of his home PC.

Looking up the model number of his router, he quickly grabbed the latest version of the firmware from their website and unpacked it. He found no mention of info_check anywhere in the code. He downloaded all the technical manuals and documentation he could find on the manufacturer's website. Still nothing.

That made Jason furious, and he decided to dig deeper. Knowing the c parameter in /info_check probably executed commands, he ran a quick curl on his laptop to validate his theory:

Oh, no! That executes commands as root! His other theory on the f parameter was also correct:

Having been to his neighbor's housewarming party and knowing that they probably never changed their password, Jason quickly connected to their WiFi on his laptop and ran the same commands on their router to check for the same backdoor. It was there!

How did this happen? Armed with this newly found backdoor, Jason broke into his own router and found the culprit hidden in a file deep within the www directory:

In just a few lines of code, this hidden HTTP endpoint exposed his home router to anyone who could reach it over the network and execute commands as root, the highest privilege user.

Reading the comments, he realized that if his ISP had put that code there, it was probably for tracking information such as number of bytes sent and received on the router's interfaces via ifconfig, and checking number of devices connected via reading dhcp leases. In an angry call with the ISP's support, they told him that it was for "metering" and "troubleshooting" purposes, like if someone had too many devices connected to the home and their network was slowing down.

Realizing that thousands of apartments in his city use the same internet provider, Jason reported this issue to his country's national CERT (Computing Emergency Response Team) as well as the consumer commission to investigate the ISP.

The resulting impact of hidden functionality is highly context specific. In this case, it exposed thousands of household routers to remote code execution to anyone who could reach them through the network, which includes ISP support engineers and creepy neighbors that know the WiFi password. Remote code execution on routers meant they could spy on or redirect network traffic, and have a foothold to compromise internal devices such as cameras and security alarms.

In this case, the metering and troubleshooting functionality of the ISP to the home router should be clearly documented and tracked in the SDLC internally and clearly communicated to customers externally in the Terms and Conditions of their internet subscription.

The best mitigation is the removal of the hidden functionality. However, if the ISP determines that checking router statistics is a legitimate need, then the endpoint for information gathering should be scoped strictly to what is required. It would look something like this:

With clearer documentation and strictly scoped information, there is no longer risk of remote code execution or information leak. The information from ifconfig only contains the router's MAC address and IP address, which is pretty common knowledge (usually displayed at the back of the devices), so it's okay to disclose over the network.

If a malicious engineer inserted this functionality, then it could only be caught with stricter code peer-review in the SDLC, ensuring that each new software release is reviewed and tested. SAST (Static Application Security Testing) tools could also be utilized to catch security issues such as command injection and block any new releases based on severe findings, which should've caught the code snippet above.

To learn more about type confusion, check out some other great content:

• The CWE page matching this vulnerability type:
• Snyk blog on "What is a backdoor" and how to build one