But in reality the upgrading of RouterOS does not even detect the unwanted/temporary files it creates itself!
I had to rollback an update of a CCR1009 because after that there was almost no diskspace left and I would not have been able to update it again without doing netinstall.
The upgrade procedure and an installation check afterwards did absolutely nothing about it and specific questions about the issue were not answered so rollback was the only thing I could do.
This does not improve my trust in the removing of unwanted files installed by others!
What’s new in 6.38.5 (2017-Mar-09 11:32):
!) www - fixed http server vulnerability;
Just for the record, I don’t think people need to check changelogs “constantly” but probably at least once a year might be cool. Maybe even every six months? Might be a stretch but just actually looking would be a start for most.
Re: … since Mikrotik doesn’t allow us shell access to our routers to perform this kind of examination. Lack of shell access also makes it hard to tell if upgrading a compromised device actually removes the compromise … VPNfilte …
A thought on how to possibly examine a Mikrotik x86/CHR file system.
Because the underlaying ROS operating system is Linux based , I suspect it may be possible to do something like this:
- Using a hypervisor system (in my case VmWare ESXi)
- Configure a Linux machine (in my case Ubuntu)
- Then add a second hard drive which is a cloned copy of an existing x86/CHR you may already have in production use.
- Using the Linux mount commands, mount the ROS hdd file system under the Linux /mnt directory
- Then just cd /mnt/“Mikrotiks-x86-CHR-file-system”
- Then use any Linux utility to scan, search the ROS file system
About 10 years ago I was able to do this with a different type of x86 no-shell-access Linux based device and I was able to see and manage all files on the foreign hdd system. I made my changes then returned the now modified hdd filesystem back into the x86 no-shell-access Linux based device. I also was able to do the same thing a 2nd time using a .bin filesystem also on a Linux computer. The problem for me is I don’t remember how I did this 10+ years ago.
So , anybody got some ideas on how to do this and what can be found/checked/modified/fixed/enhanced/expanded ?
I would guess the bad guys already do something like this all of the time when looking for possible exploits on Internet connected devices.
North Idaho Tom Jones
They are able to release single purpose tool.
I don’t think so, we secure our network pretty heavily. But if we ought to find out we are infected, that means our security is not as good as we think it is.
Mikrotik is our edge device and as you pointed out, if it is infected, we can’t trust it’s tools.
As I said, doing that I would lose opportunity to find out if our otherwise heavily secured network has been breached. So I would really appreciate to know, i mean really know, not only guess if we were infected.
Unlikely. It would need to exploit multiple vulnerabilities, some of them yet unknown.
One of the problems almost all ISPs / WISPs have with firewall protecting large base of server & client CPE devices is that once something behind the firewall gets worm-infected, is that device is inside your protected network and can often have free range access to the rest of your network.
It’s getting to the point that every device on a network (including your DMZs, server networks, workstation networks and client CPE networks all need to be extensively firewall protected not just from Internet attacks - but also from each other device in/on your many networks.
The winbox exploit was a 0-day - meaning it was being exploited in the wild before a patch appeared. If you weren’t paying close attention to forums / changelog you were probably compromised within a week or two.
This is definitely possible, you should be able to netboot to a different Linux distribution then mount and examine the flash memory, but this obviously involves a lot of work and of course downtime for the device compared to simply opening a terminal!
One thing I have started doing as a preventative measure - block everything in the OUTPUT chain except necessary services (eg dhcp client, sntp client, etc). Most exploits can only carry a very small payload, which often downloads a “real” payload from some other infected device. By restricting outbound connections to only necessary services, any 0-day exploit will have a hard time downloading the 2nd stage payload to actually infect your device. And by logging all the blocked traffic, you get immediate insight if something is trying to compromise your device.
I have that for some time. As that router is used as a VPN/Tunnel router it required some more rules but indeed it is a potentially good measure.
Rich/Pe1chi do you mean something like?
/ip firewall filter
add chain=output action=drop protocol=tcp src-port=80
Change that src-port with dst-port …
That’ll stop the check for upgrades of RouterOS from working, so not very clever.
You should at least add a white-list item for upgrade.mikrotik.com first.
To mkx WHY?
What is the functional difference or outcome of
a. src-port=80 What is prevented, what are the outcomes positive and negative?
vice
dst-port=80 What is prevented, what are the outcomes positive and negative?
To Sid5632
So what IP is that? LOL, I don’t know which domain or IP mikrotik uses when checking for updates LOL. I suppose I could add an exception!
Sure it will. I was just pointing master anav in right direction without preventing him from tripping over a stone 
If I can snatch the pebble from your hand, can I use both src and des ports of 80, riddle me what that will do???
let me go down this forbidden path some more.
why not put this as a RAW RULE
-prerouting output chain action=drop protocol tcp dest port or src port 80 - you guys seem awfully pick without logic!!!
Remember chain=output affects traffic generated by router itself.
If you add rule dropping traffic with src-port=80 it’ll drop traffic originating from built-in http service. Either you want to protect WebMin interface from being used by Vogons (but you might just disable the service as well) or you’re targeting malware that does connections around by using local port 80 (which is highly unusual).
If you add rule dropping dst-port=80, then you’re preventing router to initiate any standard http connection (including malicious stage2 servers and legitimate mikrotik upgrade service as rightly pointed out sid5632).
If you don’t even know the difference between source and destination ports, then you need to stop polluting this thread and go and read up about some networking basics.
So what IP is that? LOL, I don’t know which domain or IP mikrotik uses when checking for updates LOL. I suppose I could add an exception!
Who cares what IP it is? Just add an Address List item for the aforementioned name and then use the List name in the filter rule (dest. address list, not source address list!!!).
Once your device is compromised it can do anything. What actual value is there in changing user-level rules within a compromised router for what it can do? It has already been compromised, by no less than one of the most sophisticated state-level malwares seen to date …
The output chain is there for control of services of a normally functioning device.
You could not with a straight face use such modifications for device security without external monitoring for compromised or unknown traffic, which makes such device changes redundant in the first place.
Basic security practice like not running router services on the WAN, preferably having no open ports on the WAN at all, and use of a management VLAN for internal router access in a well-segmented network would have prevent all compromise by remote exploits in any context, regardless of what firmware you are running. Communication methods can and should be greatly improved, but customer behavior is a lot more effective for both good and bad outcomes.
The changes I would like to see are all Mikrotik devices being secured by default from the factory. This is already done for SOHO devices. For enterprise professionals such configurations are a trivial delete away. So, why not have so called Sensible Defaults that do not hurt Mikrotik’s reputation any further than necessary? Why not have it so that simply shipping such an unsecured device out of a Mikrotik door does not already hurt Mikrotik’s reputation before it even gets to the customer?
This is especially as powerful device tech becomes much more affordable for non-professionals, combined with the growth of the Internet, Internet of Things and cybertech sophistication rapidly making security and security options a top priority.
Thanks, so other than the microtik update service there is really no need for port 80 traffic on the output chain (from the router either with a source port of 80 or with a destination port 0f 80).