It all started when we received a response to one of the automatic e-mails generated by our honeypots when they detect an attack attempt or suspicious behavior. These notifications are sent to abuse contacts of the network from which the attack originated. Portscan of the WAN interface:
Reaction to the report from our honeypot.
Such a response to a message from our honeypot has, of course, captured my attention. So I asked the ISP for help and before long I had two lent Billion BiPAC 9800VNXL routers on my table. One was revealed by our honeypots and the other was clean, for comparison whether the infection is inherent.
The first “probe” brought a bit of a disappointment. The device did not have a classic shell, but only a command line on the telnet, which was absolutely useless for further analysis.
When I slowly began to give up my efforts and come to peace with the fact that I wouldn’t be able to compare firmware samples from the two devices, I tried the last option. I connected the device to a public IP address on the Internet. And it was worth it. In the matter of approximately two hours, the router was fully compromised and became part of a botnet. Then I disconnected it from the network and started analyzing the captured data.
It turned out that the router is suffering from a vulnerability that allows a remote unauthorized attacker to execute arbitrary code. The attack consists of two HTTP/SOAP queries with the second one containing the string:
It means that the router downloads and runs the binaries and after the infection, it connects to a botnet. Out of curiosity, I uploaded the binary to Virustotal, but as one might expect, architectures such as MIPS are not very interesting for antivirus companies, so it was qualified as suspicious only by one antivirus software of 55. Based on the gathered data, I wrote a short script that allowed me to send commands to the router. Eventually, all that was left of them were those that shut down the daemon and then ran it again, but this time with the parameter -l /bin/sh, which made me very happy because I finally had access to the classic shell.
Then I could easily extract firmware from both routers and check cryptographic fingerprints of individual sections. Sections with the root directory and the Linux kernel were exactly the same. Only sections of the bootloader and the stored configuration were different. The difference in configurations was uninteresting and in the bootloader, as expected, only the stored MAC address was different. Comparison of the sections, therefore, turned out as expected, as it is not that common for a malware to rewrite the firmware. This is partly because the section with the root directory is used as a squashfs file system and the entire section needs to be rewritten during modifications.
Comparison of cryptographic fingerprints of individual sections.
After comparing the firmwares, I went back to the detected attack and revealed vulnerability. The malware itself was quite decent. It has adjusted iptables, so as to protect itself against a possible subsequent infection by blocking ports of the vulnerable service. From there, it went straight to scanning random IP addresses for the purpose of further spread. After the message about “securing the device” appeared in telnet, it was almost certain that it was the Hajime botnet. Out of curiosity, I made a few more attempts and the shortest time to attack a clean device was under 10 minutes.
The vulnerability allows an arbitrary remote code execution with a maximum string length of 62 bytes. Specifically, it is the “NewNTPServer”, a “property” of the TR-064 protocol designed for configuration through a local network, and which is, apparently as a result of incorrect implementation, also available from the Internet as part of the TR-069 protocol. The vulnerability was discovered on port 7547, but in our case also applies to port 5555, which serves the same program (/userfs/bin/tr69). This vulnerability was first mentioned last year on November 7, in connection with another router, the Eir’s D1000. The vulnerability is extremely easy to exploit and the linked page also contains a Metasploit module.
On the website of the router’s manufacturer, there was nothing mentioned about the availability of other versions of the firmware, so I contacted them with a description of the detected vulnerability and asked whether they will create a fix. However, from the manufacturer I learned that a new firmware version already exists and is distributed directly to target customers (ISPs). Users, in turn, unfortunately have no chance to learn neither about the existence of a new version of the firmware, nor the existence and severity of the vulnerability contained in the product they are using. Therefore, at this moment, we are considering the creation of a webpage where people could perform an automatic test to check their device for this vulnerability. One of the small obstacles, however, will be the need to request the users to turn their device off and back on again, because if the router has already been attacked, the vulnerability would not reveal itself due to a blocked port in iptables.
A search for related CVE IDs was fruitless. After communication with Mitre, a new CVE-2016-10372 was assigned to the vulnerability previously discovered on the Eir modem and, after further examination, either a new CVE ID will be assigned to BiPAC 9800VNXL, or, if it is established that it is the same software with the same error, it will be added to the list of vulnerable devices under the CVE-2016-10372.
Even though it is not a brand new bug and the device is not too widespread, I’m glad we managed to complete the chain of actions from detecting a security incident using our own resources, through the analysis of the incident to communication with the concerned parties.
In conclusion, I would like to express my thanks for his cooperation to Radek Jirout from Dial Telecom for reporting the device, and also Tomáš Hruška and Marek Buchta from Joyce for the lease of the devices.
Links:
https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/
https://isc.sans.edu/forums/diary/TR069+NewNTPServer+Exploits+What+we+know+so+far/21763/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10372
https://www.broadband-forum.org/technical/download/TR-064.pdf
https://www.broadband-forum.org/technical/download/TR-069.pdf