Haha, actually no, just one based on an almost complete ignorance of socks!
I did just find some interesting discussion here: http://forum.mikrotik.com/t/winbox-socksv5-proxy/92658/1
I think I now understand: I imagine he used an ssh client to open the socks connection then ssh to connect to his router through that tunnel.
The vulnerability would have been less of a problem if Mik used industry-standard password-hashing methods - since the vulnerability was allowing a remote attacker to download any file, and there’s a file with a very weak encryption of the admin password, it makes getting a legit login really easy. If the password were properly encrypted, then the attacker would be out of luck or at best, have to spend lots of effort cracking the password. And the better your password was, the harder to crack…
The bit about how Winbox fetches unsigned DLLs from the router is frightening as hell. You have a signed app (Winbox) grabbing DLLs (unsigned) from the router - imagine what an attacker could do by loading a trojaned DLL onto your Winbox-running PC.
I also saw a new variation on a hacked router today - they had started a packet sniffer watching for port 20, 21, 110 and 143 traffic and sending it off to a listener on the host 37.1.207.114. Fun trick! Looking for any cleartext passwords I assume. If they were more adventurous, they’d grab 5060 UDP and make some free phone calls too.
Don’t tell me, tell the guy that wrote the blog post. He did see it happen in his tcpdump though, I don’t think he wrote that more than 3-4 months ago.
Here is the script I wrote to clean up after IP-socks/user service attacked some of the old routers I have. After cleaning up it downloads the latest ROS and does a midnight reboot to install the latest ROS and firmware. I do recommend testing in a lab before deploying in production. I did not check for disabled drop rules.
/system logging action set memory-lines=1000 [find where name=memory]
/ip firewall filter remove [/ip firewall filter find where comment ~ "port [0-9]*"];
/ip socks set enabled=no port=1080 max-connections=200 connection-idle-timeout=00:02:00;
/ip socks access remove [/ip socks access find];
/system script remove [find where source~"mikrotik.php"]
/system script remove [find where source~"socks set enabled=yes"]
/system scheduler remove [find where name~"port"]
/system scheduler remove [find where owner="service"]
/user remove [find name=service]
/system scheduler
add name=midnightReboot on-event="/system reboot \r\
\ny" start-time=23:59:00
/system scheduler
add name=updateFirmware on-event="/system scheduler remove [find where name=\"up\
dateFirmware\"]\r\
\n:delay 2s\r\
\n/system scheduler remove [find where name=\"midnightReboot\"]\r\
\n/system routerboard upgrade\r\
\n:delay 10s\r\
\n/system reboot\r\
\ny" start-time=startup
/system package update download
When will you backport this vulnerability patches to the mipsle branch ? I want to upgrade our RB532’s, RB133’s every time, when I read this security warnings, but no .npk available.
How do you recover from this attack? We have 40 Dynadishes that are not responding to Winbox. They do respond partially on port 80, but act strangely. No SSL or telnet was enabled on these CPE’s , so that approach is out. Any suggestions?
They are responding normally on port 80 now that I’ve put them behind a NAT, which I think should cut off access by the hacker. But, the username and/or password has been changed. Seems like there was a “service” entry in the users placed by the hack. Anyone know what the password is for that account?
More after hacking away. Most of them respond on port 80, and able to upgrade, turn off SOCKS, remove service user and change password. About 1/4 of them don’t respond, indicate wrong user/pass, or show an error on the webpage. Noticed that the webserver from some are trying to place malicious code.
Don’t forget, the last version was routeros-mipsle-6.33.5 on the MIPSLE branch, which is vulnerable. So must I downgrade to prior 6.29 to be safe?
(I can’t firewall winbox port, because it must access from anywhere, from mobile or wired internet too. And I can’t predict source IP… geoblocking would be a good solution. )
But wait, there’s more. After three days of cutting the infected devices off from the mother ship (killing all incoming direct connections using NAT), most of the Dynadishes that wouldn’t allow remote access to fix will respond favorably to Netinstall. However, I did run into one today that was rebooting cyclically in such a way that it wouldn’t respond to power off, press reset, power on to put it in Netinstall mode. So, one scrap.
If the hacker has left the devices with old software, u can use the same Holes to get the set passwort, there are some Python scripts avaible for proof of concept…