Here is an interesting video by 'Low Level Learning' about some security researcher hacking his own router (and anyone elses at his ISP, cox.com).

On invidious/youtube here:
https://yt.artemislena.eu/watch?v=TFolQUeWoog
https://youtu.be/TFolQUeWoog

#Hacking #LowLevelLearning #TR069

Years ago I was toying with my own #ZyXEL #ADSL modem and found an HTTP form in the #TR069 #RomPager httpd server running on port 7676. The form appeared to be some kind of a test page unrelated to the actual TR-069 functionality of the device. I tried entering a command injection to the form input string and the device promptly rebooted. My first though was the command execution somehow made the httpd time out and some watchdog timer would reboot the device. However, I quickly found out that any long enough string would cause the same effect. This seemed some kind of uncontrolled termination of the httpd process. I downloaded a firmware upgrade for the device and promptly dissected it and located the httpd binary for reversing. The binary had no ASLR, or any other security measures that would even remotely resemble anything modern. The reversed binary looked like it escaped the 90s.

I did find out some unique looking function names, and googling for them and the form URL resulted in locating “RomPager Intro Web Server for ThreadX Programming Reference” (RomPager Intro - Web Server - Version 4.64 - June 24, 2010). This document has an example “RomPager Intro Sample User Exit Routine” (RiCgiTst.c) which matched the forms running on the ZyXEL device.

Fair enough, ZyXEL accidentally seemed to have included the test form to the device. Likely it was included as part of the RomPager httpd by default. When reading the code I quickly spotted something rather alarming:

extern void RpExternalCgi(void *theTaskDataPtr, rpCgiPtr theCgiPtr) {
…
char theName[25];
char theValue[25];
…
else if (theCgiPtr->fHttpRequest == eRpCgiHttpPost) {
/*
We got a POST request, so see if it matches the form that
we know.
*/
if (RP_STRCMP(theCgiPtr->fPathPtr, "/ProcessForm") == 0) {
/*
This is our form, so go retrieve the values.
*/
theFormBufferPtr = theCgiPtr->fArgumentBufferPtr;
theFoundFlag = False;
while (!theFoundFlag && *theFormBufferPtr != '\0') {
RpGetFormItem(&theFormBufferPtr, theName, theValue);

As it turns out RpGetFormItem did not do any kind of bound checking, and long enough parameters and values would promptly overflow the stack buffer. When the RpExternalCgi function returned the overwritten program counter would be followed, leading to the crash I was witnessing. I promptly created a proof of concept that used simple gadget to fetch pointer to the parameter string in first function register and then return-to-libc to system() function to execute shell commands on the device as root. Nice 0-day found and exploited... or so I thought.

Even at this stage I had already established the habit of googling for vulnerabilities by manufacturer and/or product name. Vulnerabilities often cluster, and it’s quite common to find similar issues from different models or even vendors. I did google for ZyXEL vulnerabilities and ran into identical issue, literally. I found out that this #vulnerability was old: It had been found by Peter Gessler and Steven Ketelaar and presented as “How I Met Your Modem” at Hack In The Box 2013. Their #exploit was far superior to mine, employing full ROPchain - but effectively it was the very same vulnerability. I then saw the slide page 43 "Responsible #Disclosure" which stated that the issue had been reported and verified to be fixed, and that everyone was happy. Well, I wasn't! Years later the vulnerability was prevalent in thousands of devices, including mine... To make matters far worse this flaw could be exploited without authentication over the WAN interface (read: internet).

I don’t know who dropped the ball, but it seems that the fix to this vulnerability didn’t reach all of ZyXEL's clients using the affected firmware. ZyXEL provides devices to dozens of different ISPs, and most of them have customized firmware dealing with local differences of the DSL network, such as the address of the ACS server (TR-069 Auto Configuration Server) and similar. My best guestimate is that at least at the time there was no proper coordination when the security fix was applied to all the different forks of the firmware, and this likely lead to the fix being applied to only one or some of them.

The "S" in IoT stands for security.

"How I Met Your Modem" slides, the vulnerability is described page 26 onwards: https://archive.conference.hitb.org/hitbsecconf2013ams/materials/D2T1%20-%20Peter%20Geissler%20and%20Steven%20Ketelaar%20-%20How%20I%20Met%20Your%20Modem.pdf