Many organisations use the same set of SNMP strings across the business. If you manage to compromise it for one device then you stand to compromise it for everything.
More than 7,500 Mikrotik routers have been compromised with malware that logs and transmits network traffic data to an unknown control server. This is according to researchers from 360 Netlab, who found the routers had all been taken over via an exploit for CVE-2018-14847, a vulnerability first disclosed in the Vault7 data …
Since June there have been a number of requests for '/login.cgi' in my web logs (several hundred) with an obvious code injection exploit in the URL, that wget's a file on a server with a specific IP address (several of these observed, looks like they change periodically) which then loads a binary image for MIPS or ARM processors [as appropriate] into /tmp or one of several other directories that it might be able to download something into...
in any case the script it first downloads is called 'izuku.sh' . I reported my logs and findings to several ISPs who either hosted the machines doing the request, or WERE the host for the downloading.
Not sure if this is the same one the article talks about, but the one I saw has been around since June (according to my logs) and always tries to download that script file which then attempts to download the binary into one of several directories, then load/run it. And I think if you disable remote management on your router, this (apparent) virus won't infect it. But it could be a different one, not the one the article is about. I don/t know. So I mention it anyway, just in case. Details are sometimes useful...
Anyway, if you have a web server, look for access attempts for /login.cgi and you'll probably see it (the one I'm talking about). Again, dunno if it's the same as the one in the article, but is similar, probably.
(the first log entry is 15-June at 14:36, in case anybody wonders)
Never underestimate a human's ability to not complete an action properly.
That is a valid remark in all areas of life, but I think it is especially true in IT. Ironically, IT is the only domain where you generally only need a keyboard to do stuff, and even then, people can be too lazy to finish properly.
Sometimes you need a mouse. Especially with Windows... Besides that, couldn't agree more. It the difference between the sloppy (who are perceived as getting things done) vs the thorough (who are perceived as slow).
Anyway. The current RouterOS doesn't seem to have a fix for this bug. So, blocking the management interface from the outside world it is then! But what's wonderful is that CHR reboots so fast. I don't even have to disconnect from my Citrix session.
Blocking an external management interface from direct access from the internet is an absolute must. If you have to, VPN access to the box and do it that way. If nothing else the logs on the box fill up with denied SSH requests and the filesystem gets to 100% and the box does funny things up to and including becoming unresponsive...
unfortunately it seems nothing's been done about the 'izuku.sh' file, though my logs show different IP addresses hosting it now. Yeah, they ignored me. Well that server _IS_ in Poland... they probably can't read or understand the information properly and/or just ignore it because they regularly host criminal services or similar. [I've had 'confirmed kills' before, wtih responses, just not that often - usually it is silently fixed or seems so because the activity stops]. Another possibility is that they leave it on the server to see what IP addresses download it to track the thing. Well I won't interfere with law enforcement if that's the case.
( I also posted the actual URL on USENET, and described it even better there, so not like it's invisible any more, and anyone can see it in web server logs )
Back at the turn o' the century, Code Red lingered for several years after the initial infections started. Someone (allegedly me perhaps?) allegedly had an auto-responder that would allegedly shut down the Code Red infected web server remotely (since it was attempting to spread a virus) via the Code Red back door command/control channel and (allegedly) leave a file on the administrator desktop that said something like "you are an idiot" and explained why the web server was shut down remotely. Both of those factoids should frighten any clueless admin into patching the thing (as it was most likely some old unpatched "oh we have a web server running?" Win2k box in a closet that nobody thought about. But I digress...
"....the controller oddly seems to be interested in collecting traffic from the relatively obscure SNMP ports 161 and 162."
One possibility is that there is some other exploit in the wild, that transfers information using SNMP, on the basis that SNMP packets to and from almost any device would not be considered out of the ordinary and would be unlikely to trigger an IDS/IPS.
FFS. This vulnerability was fixed days after it was discovered. We are now 7 dot releases past this fix at 6.42.7 Any decent Network administrator needs to be monitoring and updating the firmware of your products.
Secondly the exploit relies on remote access to your router. What complete idiot allows this? Never let external internet access to your routers configuration. Are you completely crazy. I include a URL with the rule to prevent WAN access
1) Some code monkey that cut and pasted the code from stack exchange
2) Some code monkey that cut and pasted the code from a higher end product and didn't consider if these functions were necessary.
A code monkey is not a code monkey because their coding skills are s**t.
They're a code monkey because of what they choose to do about it.
Biting the hand that feeds IT © 1998–2019