Winbox in the Wild
Port 8291 Scan Results
I’ve written, ad nauseam, about MikroTik routers. I’ve detailed vulnerabilities, post exploitation, and the protocol used by Winbox to communicate to the router on port 8291:
- Make It Rain with MikroTik
- MikroTik Firewall & NAT Bypass
- RouterOS Post Exploitation
- Rooting RouterOS with a USB Drive
- RouterOS: Chain to Root
I’ve spent a lot of time reversing and manipulating these systems. So I admit, I don’t love it when my work is met with less than generous responses:
Rebutting the poster’s seeming assertion that no one opens the router’s port 8291 interface to the internet isn’t easy. Scanning services like Shodan and Censys don’t have results for MikroTik routers on port 8291.
But I do sympathize with the poster’s general point. Does my work carry any value if no one is affected? What if the only real world impact is that I’ve tricked a few dozen people into reading my mediocre writing? As you can probably imagine, I fell into a bit of an existential crisis. I needed answers.
So I wrote my own scanner. It connects to port 8291 and, without authentication, grabs the router’s RouterOS version. I scanned a bunch of addresses. I got the answers I needed.
Scanning Results
The port 8291 scan ran from November 30, 2019 through December 2, 2019. The scan found 578,456 MikroTik routers with port 8291 open to the internet. The raw results are on GitHub.
The scan total, 578,456, should be considered a floor, because I didn’t scan the entire internet. Due to time constraints and lack of infrastructure, I only scanned addresses found in @PACKET_TEL’s March 2019 port 8291 TCP scan and addresses gathered from various MikroTik-centric Shodan queries (FTP, SNMP, HTTP, HTTP Proxy, Telnet, and PPTP).
The scanner extracted RouterOS versions from all 578,456 routers so I have the unique opportunity to opine on the patching habits of RouterOS administrators.
On Patching
During the scan period, the most recent MikroTik RouterOS versions were 6.45.7 (Stable) and 6.44.6 (Long-term). Both were released on October 28, 2019. Administrators had more than a month to upgrade to these versions before I started my scan. The following chart shows how many routers were upgraded to the latest versions of RouterOS.
You aren’t misreading that. Approximately 15% of the scanned routers were using the latest versions of RouterOS. 15%. One month after release.
This is particularly bothersome to me because 6.44.6 and 6.45.7 addressed serious unauthenticated vulnerabilities previously disclosed. The attack vector for those vulnerabilities is the Winbox interface on port 8291, and we’ve observed one of the vulnerabilities (CVE-2019–3978) hitting our Winbox honeypot. Below is 37.49.231.122 poisoning the DNS cache for mikrotik.com, upgrade.mikrotik.com, and about 180 other cryptocurrency related addresses.
Of course, the October vulnerabilities aren’t the only unauthenticated port 8291 vulnerabilities I’ve published this year. In February, MikroTik fixed CVE-2019–3924, a firewall bypass I found. However, less than 50% of the scanned routers have patched against it.
Admittedly, the bypass does have some limitations, but it’s still useful. In practical terms, it’s probably best used for internet or LAN scanning. But, as I detailed in my writeup, it can be used to deliver exploits into the LAN too. So I’m a little bewildered to find a couple hundred thousand routers are still vulnerable ten months after disclosure.
At least most of the scanned routers are patched against CVE-2018–14847 nowadays. Although how much credit goes to administrators or vigilante grey hats is hard to say.
That’s not to say that our honeypot hasn’t seen CVE-2018–14847 thrown around. Quite the opposite. Like other honeypotters, we still see it multiple times a day. Somewhat interestingly, it appears that the attackers are just slinging Exploit-DB 45170.
Full control of the device is possible via the Winbox port, yet attackers are just grabbing our honeypot’s admin credentials and moving on. Perhaps that just speaks to the level of sophistication of spray and pray attackers? Or perhaps stage 2 of the attack is meant to happen later.
Regardless, I guess I can’t expect uniform patch cycles for all MikroTik routers since the models vary so much. The rack mounted CCR10172–1G-8S+ with it’s 72 cores and advertised 80 Gbps throughput has a very different use case than a tiny dual core RB750Gr3. I expect a professional, full time administrator to be maintaining the CCR while the RB750Gr3, like most home routers, probably sees little to no maintenance. With that in mind, I sought to figure out what type of MikroTik devices I had actually scanned.
Approximating Scanned Hardware
Unfortunately, the Winbox interface doesn’t share the platform’s hardware without authentication. But Shodan does have a lot of results from MikroTik routers that have exposed their SNMP interface to the internet.
I downloaded the Shodan SNMP results and matched them up with the IP addresses that my port 8291 scan had identified as MikroTik routers. The overlap wasn’t that great. I could only match about 10% of my scanned data against the Shodan results (58,951 / 578,619). Again, you can grab the raw results off of GitHub.
Perhaps 10% is a bad sample size. I’m a programmer turned bug hunter, I’m not a statistician, but I think it should be representative. Regardless, the results were surprising to me. The chart below maps the top 10 platforms:
If you aren’t familiar with MikroTik routers, only one of these is a small home router (RB951Ui-2Hnd). Everything else is virtualized (x86) or a rack mounted platform. The top two platforms CCR1036–8G-2S+ and CCR1036–12–4S each have 36 cores and are advertised to support 28 Gbps and 16 Gbps throughput respectively. These aren’t sitting in your living room. They are sitting in an ISP somewhere, and should have professionals applying patches.
Don’t Actually Ignore the LAN
The opening to this blog shouldn’t be taken seriously. A vulnerability does not have to be internet facing to be considered serious. It’s easier to quantify the impact of a vulnerability when you can count internet facing hosts. There are plenty of reasons to be concerned about the soft innards of your LAN. Just ask Merck.
But listen, if you want to leave your Winbox port open to your LAN then be my guest. But your trust in your users and the nefarious junk they’ll inevitably invite in is misplaced. Lock it down.
What More Can Be Done?
Honestly, the 15% patch rate is quite bothersome. I’m not sure what more could have been done though. MikroTik issued:
- New RouterOS versions with release notes clearly indicating vulnerability fixes.
- Write ups in their security blog.
- Forums posts announcing the releases
And Tenable:
- Issued CVE with an advisory.
- Wrote up a full disclosure blog to ensure everyone had the chance to know the full impact of the vulnerabilities.
What more can be done to get a better patch rate than 15%? I’m honestly not sure.
Bonus Material!
This section wasn’t originally going to appear in the blog, but I realized that some people might be interested in how version numbers are extracted from port 8291. There are two ways that I know of.
The first method works from RouterOS version 2 all the way through current version 6. This method takes advantage of old logic that has hung around in the RouterOS code base. Specifically, the Winbox client used to load .dll’s straight off of the router. Slingshot APT knows what I’m talking about.
Because MikroTik breaks many of their features down into separate packages, the Winbox client needed to ask the router which .dll it should download. To do so, the client sends a request to the router’s mproxy binary indicating that the client wants to read the “index” file. Also, sort of interesting, is that the request is in a binary format that the router no longer uses. Either way, here’s what a request and response look like on the wire.
The index file is actually a file in /home/web/winbox/. You can alter the request to read other files in that directory or /home/web/webfig/. I’m not the only one that knows about this request. This is how Nessus grabs the router’s version. Also, our honeypot has seen one IP address make this request in the wild. Good for you 109.64.71.76!
The other method, which hit our honeypot much more often, only works for RouterOS version 6. The message is one that the modern Winbox client sends. It’s a Winbox message to system binary 2 (mproxy), handler 2 to read the “list” file. Similar to index, list lives in /home/web/webfig/.
Unlink the request for index, this method requires four total packets:
- The client requests to read the list file.
- The server says “Ok. Cool. Here’s a session ID and the file size.”
- The client says, “Hey, I’d like to read x bytes on session y.”
- The server sends the file data.
On the wire it looks like this:
If you want to see my implementations, you can find them on GitHub.
