I have two CCR routers that have been upgraded fully to 6.43.4 and have the routerboard firmware upgraded also. Both units are still exploited. The are no config changes to the router, this is all transparent and going on the background. The way to spot this particular one is to look for people targeting your router port 64312. If your router is hacked with this, port 64312 will be OPEN. It is used as a proxy from the traffic I can see, SMTP and HTTP(S) and other stuff. I can watch with torch and see all the activity.
Is it true that I’m stuck with doing a local in place NETINSTALL to get the router clean?
One unit is 500 Miles away 8(.
Most likely the password was retrieved before you did the upgrade, or some file was planted before, that was still there after upgrade. This is why it’s recommended to change password and inspect files + configuration, even if you have upgraded.
As I said there is not configuration changes to the router at all. Nothing is visible in the config what so ever with this. The passwords were change and the config has been checked. This completely exploits the router and make not changes to the configuration at all, that is the point. There is no FILE being left behind or an addition to the config, nor any script. The traffic was immediately present after upgrading the firmware. The exploit survives the firmware upgrade just fine of both the OS and the routerboard firmware. No config changes to the router at all, everything that is happening is transparent to winbox and can only witnessed going out of the router with Torch. It looks like the OS has been rooted so to speak.
Running the most current firmware and completely exploited. Has anyone seen this?
it must have been exploited before the upgrades.
upgrading does not remove the exploits, it just fixes the holes.
IF your device is exploited, the only thing you can do is netinstall
If you’re correct, this would be new exploit code that I haven’t yet seen. It isn’t a surprise to me that firmware and RouterOS updates don’t remove it. I personally find it a little hard to believe that you have what you think you have because you haven’t provided anything concrete except a belief that your router is listening on a port that you don’t expect it to. However, I’ll be the first to admit it isn’t outside the realm of possibility either.
If your router is listening on port 64312, when you connect to it do you get anything? A header, text, or some other data? That might help in identifying what is going on. It would be awesome to get a packet capture of that traffic.
You should always netinstall after a compromise. Mikrotik have stated that there are ways to get OS root access once you have winbox access, so processes at that point aren’t visible to RouterOS - even after upgrading there may be a persistent backdoor. Formatting / netinstall is the only safe way (until hackers also start compromising the Routerboot firmware…)
I have already submitted supout files for both routers and the response I got back from them says they didn’t read my message in the first place. “Check the proxy, config, etc”. The only way I know it’s active is the output traffic from it’s preferred IP address, and the fact that port 64312 is open. I can telnet to it and connect but it doesn’t say anything and disconnects when you send a line. I have two IP addresses on the router, the exploit only talks on the preferred IP. I have that blocked via the output chain in the firewall but can still reach the device and verify the port via the second IP address. If I remove the blocks connections pour in over 64312 and the router initiates a bunch of HTTP, HTTPS, IMAPS, and SMTP connections. The routers does not NAT any user traffic except for DNS port 53. So it shouldn’t have any of this traffic. It’s blocked via the output chain when it shouldn’t be there at all.
Both routers run a satellite connection for a rural ISP, that critter has got to go.
I tried using reset to force a netinstall on one of the yesterday. When reset is held in the unit will not BOOT, it had to be power cycled for it to become active again. This did erase the config. Once setup again the unwanted traffic was still active.
I am in a dialog with support and they are not reading what I typed in regard to the router and it’s symptoms. They are simply not reading or interpreting English correctly in this case. It’s frustrating then I tell him there are no configuration changes and he tells me to look on my network for the device making the traffic. This is after telling them that the traffic able to be blocked in the output chain of the router. I can talk till I’m blue in the face he is either ignoring what I’m typing or language is the problem.
I’m going to NETINSTALL and wipe them both out in the next couple of days, I can’t communicate with them ( MIKROTIK SUPPORT Ticket#2018111422008078) well enough to their attention in spite of giving them everything and more.
I would like to have more confidence that they can handle issue like this more aptly, I mean they did get hacked repeatedly just recently right? You would think they would pay better attention to issues like this when reported and support files are provided..
We have received your complaint and replied to your message.
Your router is not hacked. Your router does not have firewall protection. Not only 64312 port is open but also many others.
Seems that you have tried to protect your router, however, firewall rule that you added is configured on forward chain, not for incoming traffic.
I will not post your firewall rules or list other ports that are opened for anyone to access here. Please follow the steps that my colleague has provided to you as an answer to your support ticket.
NOTE: Traffic showed on Torch is traffic “before” firewall. Torch shows all the traffic received on this interface. If someone tries to send traffic to a closed port, then it will still show up in Torch.
is probably most valuable statement I have heard since all those vulnerabilities outrage. Please, could you put that on wiki?Or maybe even better - update the packet flow image so it is clear, where the torch and packet sniffer are applied.
Mikrotik support is correct. If I had followed their instructions fully I would caught the configuration change that I overlooked. They were spot on, it was my mistake.
