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/wisptal ... up_comment

No, never seen that in any of my routers...

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.

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.

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.

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.

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:
` `
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:
` `
These are the only settings that the bot touches.

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?

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 viewtopic.php?f=21&t=151603&p=747833#p747833

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

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?

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.

Plus one here. Same timeline, same NAT setting.

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

I always disable SSH through IP services...

Same here, 6.42.1

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

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

In general management ports like SSH and Winbox should not be open to internet by default.

+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.

Disconcerting, I look forward to an official response

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

- are you seriously using "admin" ?

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

Seems quite widespread. It intercepts DNS requests and redirects any HTTP requests to https://www.youtube.com/watch?v=MK_VfUE ... e=youtu.be. If you look at the comments you can see lots of affected users wondering what the hell is going on. While this might appear benign, any credentials and cookies sent over HTTP since infection should be considered compromised.

We were also affected by this yesterday. Luckily it seems only one CCR1009 was hit.
We block all winbox/API/Telnet/SSH directly at our gateways. These rules were still in place when this attack happened. So blocking management stuff appears to not be a solution here. Version is 6.42.10 (So not completely up to date unfortunately, but it seems users on higher levels were hit anyway).

As others have seen, logs do not show multiple login attempts or brute force signs. So this looks like a complete exploit that bypasses authentication in some way.

We have also set up logging rules at the gateway to see if anything else appears to be affected after we removed the "infected" rules. (Log anything hitting that IP address)

We are still getting triggers from clients that were affected by the original CCR1009, even though we removed the rules. These are clients with UBNT radios and UBNT routers. So perhaps there is a UBNT level attack here as well?

Normis
if you read the facebook topic I created you can see its not an firewall issue because even though one of people I talk to on facebook said he had secured firewall and was able get past it so we need to figure out if this is some kind of exploit for mikrotik and other linux based firmware. Even the latest version of OS got nailed also.

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

What Facebook topic? Sorry, I don't use facebook. Please post the requested information like I wrote above, and email support.

We do have about 10 routers exposing their SSH service directly to the internet without any restrictions. They are running version 6.42.9, 6.44.5 and 6.44.2. None of those routers has been hit. But we do not have any other services running, everything is disabled except SSH. Leads me to the conclusion that there is either an exploit for any other service (winbox, api?) or the admins got hacked and credentials were stolen from their machines..

Actually, he confirmed he had his firewall rules open to all 10/8 and other rfc1918 ranges of customers (input allow any). Not smart, and I’m sure the source of the path in.

Normis
if you read the facebook topic I created you can see its not an firewall issue because even though one of people I talk to on facebook said he had secured firewall and was able get past it so we need to figure out if this is some kind of exploit for mikrotik and other linux based firmware. Even the latest version of OS got nailed also.

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

This topic so far: "I heard somebody got hacked"; "Me too"; "I have no firewall and use admin user".

So please:

- Use latest version (at least "long-term")
- If you upgraded from a vulnerable older version, make a new user and new password, delete the old user
- Do not use "admin" user, ever
- Send support your supout.rif file if you are running latest RouterOS release with firewall and non-admin

Public ip here on 6.42.12 NOT affected.
SSH enable on non default port
winbox enabled on default port
icmp allowed
access restricted to single ip, port knock and lan
admin user not present

- Do not use "admin" user, ever

That is just "security by obscurity". When it is vulnerable for admin, it is probably vulnerable for any user.
And when it is the old exploit or a variant thereof (looks like it, given the immediately successful login), they can retrieve your "secret username" as well.
When the exploit does not yet do that, you can wait for a next version that does (especially when the advice to use another user is widely followed).

For now it is important only to know of people who had already upgraded to the latest version where the stored plaintext passwords were removed, were also affected.
And for those who were affected even though they think they had a firewall, it is important to see the input chain of their firewall config.

I'm inclined to agree with normis here. The Linux kernel firewall operates before any user service like SSH or Winbox even sees a packet, so it's extremely doubtful that the exploit can bypass a properly configured firewall. Don't forget your customers / clients can also be infected with malware - only blocking inbound from internet is not enough, you should use a separate secure IP range or ideally management VLAN for administrative access.

I would guess that this recent wave of compromised routers is from firewalls that have been broken for a long time, credentials that are harvested from older versions of RouterOS or otherwise weak / re-used passwords and are now being exploited.

I'd like to add that it has become difficult to update our customers' routers. Most are hAPs and do not have enough free space to upgrade.

I'd like to add that it has become difficult to update our customers' routers. Most are hAPs and do not have enough free space to upgrade.

Well, maybe you should have thought about it a little more before giving most of your customers a $19.95 router!

Normis et al.,

Just to make it clear:

All of our clients' routers that got hit, they all got hit at virtually the exact same time, and all from the same source IP. They did admittedly all have an "admin" user, and they all obviously had SSH enabled, so that's admittedly a problem. However, they all had different passwords for "admin" user, and some routers that were compromised were running 6.45.6, so it shouldn't have been possible to harvest "admin" password from them while they were running that version.

If I understand what you're saying correctly, it sounds like you are guessing that maybe somebody harvested the "admin" passwords from these routers a long time ago (before they were upgraded to non-vulnerable version), and then didn't do anything with those passwords until a couple of days ago? So if we had changed either username or password between then and now, those routers would not have been affected. If that is what you are saying, the only problem with this theory is that in order for it to make sense, all of the routers that were compromised would also still have to have the same IP addresses that they had when the passwords were originally harvested, because this theory assumes that the attacker would know what specific password to use for a router at a specific IP address.

If it turns out that a sizable number of the routers all have dynamic IPs, and those IPs change frequently, and the router's IP address changed after the upgrade to recent non-vulnerable versions, then this theory cannot be correct. I would guess that this -- routers with dynamic IPs were compromised -- is true in our case, but I will check with others in my organization that dealt with most of the clean-up to see if they can confirm this for me.

As far as "do not use admin user" advice, the problem here is not so much the use of "admin" user, but the use of "admin" with the same password after having previously used a vulnerable version of RouterOS. If someone had deleted "admin" back when the router was running, say, 6.36, and then upgraded after that, it would not have mattered that the router had no account called "admin", because all passwords for all full-access group users would have been harvest-able while the router was running 6.36, not just the one for the account called "admin". Therefore it would have been enough to change *either* the username *or* the password, but only *after* upgrading.

-- Nathan

@NathanA, was SSH the only exposed service? No winbox or API etc?

Was there anyone here using SSH keys to log in instead of passwords? For anyone exploited, did the bot add any keys for any users?

Was there anyone here using SSH keys to log in instead of passwords? For anyone exploited, did the bot add any keys for any users?

`
Please read my earlier, detailed post. It itemizes exactly what got changed in the router, which *only* includes the addition of 2 new NAT rules at the very end of the rule chain, and 1 new firewall filter rule at the very end of the rule chain. No new user additions, no key importation, no password changes, no proxy enablement, etc. Very simple and straightforward.

@NathanA, was SSH the only exposed service? No winbox or API etc?

`
I can't say with 100% certainty in all cases yet (but I'll find out)...I didn't deal with all of these personally. I suspect there was a mix, and that some devices had one or more of these services enabled and some did not. What I can tell you is that we have been blocking WinBox in particular (TCP 8291) at our network edge for over a year now (perhaps longer) and that the connections to these routers all came from a single outside IP address, so even if someone INSIDE our network could've accessed WinBox on a router, this particular IP could not have done so. And even for devices that had more than just SSH accessible, the ONLY thing that was logged was a SINGLE and SUCCESSFUL SSH login from the SAME IP on ALL routers being discussed here. No failed login attempts, no hits from that IP to other services, etc. (at least not that showed up in the logs).

-- Nathan

so from what has been posted above
it seams like some kind of ssh authentication bypass.
it seams also that at least the user name must be known.

This topic so far: "I heard somebody got hacked"; "Me too"; "I have no firewall and use admin user".

So please:

- Use latest version (at least "long-term")
- If you upgraded from a vulnerable older version, make a new user and new password, delete the old user
- Do not use "admin" user, ever
- Send support your supout.rif file if you are running latest RouterOS release with firewall and non-admin

Upgraded to 6.45.5 from 6.45.4 (or .3)
I use non standard admin user.
SSH is on non standard port, and blocked by input chain firewall rule from WAN, unless it is an "established / related" connection. I do use SSH key for my non standard admin user
Input Firewall is very straight forward, forward chain follows the same as per below, user defined chained for ICMP
allow estab/rel,
allow new from LAN interface list,
allow L2TP vpn from WAN interface list,
drop invalid from WAN interface list,
drop all (no interface or anything specified)

You should have the suppout I sent to support, see call ref Ticket#2019090122001404

For what's it's worth, I have 900+ deployed in the field, all sending their logs to a central server. I just did a search for the past 30 days and couldn't find any reference to 109.251.192.80.

We also have all management services locked down to specific IPs. Either way I still would have seen a login denied message.

Is 109.251.192.80 the only IP that was used?

so from what has been posted above
it seams like some kind of ssh authentication bypass.
it seams also that at least the user name must be known.

`
Either SSH bypass somehow (though some sort of exploit in-band within SSH, or by first exploiting something outside of SSH, like through API etc.), or as Normis seems to be implying, they just collected all of your router admin passwords months/years ago, sat on them, and then exploited all of your routers all at the same time. This would, as I said, require that all routers either have static IPs or IPs that change very infrequently. I am still working to determine if what we saw fits that mold.
`

You should have the suppout I sent to support, see call ref Ticket#2019090122001404

`
I'm not entirely convinced your (CZFan) problem has anything to do with what is being discussed here. The config changes that were made by this bot to compromised routers were VERY small and VERY simple...3 "/ip firewall [filter/nat] add" commands and that's it.

-- Nathan

Here I will take this off of facebook since normis dont use facebook:

"Lyndon Bulmer Hi guys, new to the group and found you via researching this DNS redirect attack. I work for a Telco and we've noticed lots of devices that are using Linux as the OS, the bulk of our users are using Netgear DG834's which has a major weakness Any person who can access the router using a web browser, can enable "debug" mode using [IP_ADDR]/setup.cgi?todo=debug and then connect via Telnet directly to the router's embedded Linux system as 'root', which gives unfettered access to the router's operating system via its Busybox functionality.[4][5] Additionally, a 'hidden' URL [IP_ADDR]/setup.cgi?todo=ping_test also allows unfettered access (On a v5 model a username and password are requested). There is no user option provided to disable this. I would persume if the AP's that you guys are using have the same OS with the vulrability or are been fed via a netgear or equivalent."

"Mike Eber I can confirm the Tik that we had get compromised was running 6.43.8 with SSL API open. Another tik upstream had API all off and was not hit." (day ago)
"Mike Eber UPDATE: I have filters in place for API ports and I am seeing lots of traffic on those ports TCP 8728/8729. (19hours ago)"


If you ask me its an exploit on linux setup.

RouterOS doesn't use web interfaces on top of busybox, it has a custom proprietary protocol. Exploits affecting other devices like the DLINK or Netgear are not going to work on RouterOS.

RouterOS doesn't use web interfaces on top of busybox, it has a custom proprietary protocol. Exploits affecting other devices like the DLINK or Netgear are not going to work on RouterOS.

No, but people write those exploit kits that a script kiddie can use to quicky distribute his desired attack code to many different types of router.
Of course it will use a different method for different routers.

No, but people write those exploit kits that a script kiddie can use to quicky distribute his desired attack code to many different types of router.
Of course it will use a different method for different routers.

`
Of course, but the implication of the post that R1CH was responding to is that there is some inherent insecurity in the Linux kernel *COMMON TO ALL ROUTERS THAT HAVE A LINUX-BASED FIRMWARE*, which just quite simply is not true.

Also, Mike Eber's firewall rules and/or log entries catching and showing a multitude of API login attempts is not indicative of anything one way or another. Of *course* there are going to be brute-force password bots that attempt to login repeatedly via the API channel, just the same as on the SSH, Telnet, WinBox, web interface, etc. channels.

-- Nathan

Could this be a problem with the particular version of the SSH software ? Does Mikrotik need to update the version of SSH that they have in the router OS ?
What version of SSH is currently being used ?

ros should have custom code for implementing ssh.
I thing mikrotik has its own public honeypot devices with traffic monitoring, so i guess they already have whats needed to diagnose it.

I'm not entirely convinced your (CZFan) problem has anything to do with what is being discussed here. The config changes that were made by this bot to compromised routers were VERY small and VERY simple...3 "/ip firewall [filter/nat] add" commands and that's it.

-- Nathan

Probably right, think something probably went wrong during the upgrade process of mine, and just myddying the waters here, will delete posts

Yesterday I also saw this exact DNS hijack at a WISP I have done some consulting with in the past. They came in via Winbox from a Ukraine IP and redirected DNS to a Sweden IP. They came in using a specific users account so I assume it was with a harvested password. And yes their device was not adequately firewalled.

To test some of the theories in this thread, I netinstalled 6.45.6 on a spare board, with default config and then exposed SSH to the internet after setting a strong admin password. So far while there are plenty of brute force attempts, there is no sign of an exploit that can bypass authentication. I'll rotate the exposed ports if nothing interesting happens after a while.

Seeing what video is shown in the redirect, it probably was a single-shot attack by some activist, that you will not see continuing all the time.
(maybe there will be a couple more shots, depending how much money they want to spend at their "exploit as a service" provider)

But of course, when there really is a vulnerability, it could also come back with other payloads.

More interesting would be to find an unimportant router that was attacked, remove the added rules and change the password (but not the username), and see if it is attacked again.

To test some of the theories in this thread, I netinstalled 6.45.6 on a spare board, with default config and then exposed SSH to the internet after setting a strong admin password. So far while there are plenty of brute force attempts, there is no sign of an exploit that can bypass authentication. I'll rotate the exposed ports if nothing interesting happens after a while.

`

Seeing what video is shown in the redirect, it probably was a single-shot attack by some activist, that you will not see continuing all the time.

`
This is my suspicion, too. Like I said, the few routers of ours that were successfully attacked were all attacked within minutes or seconds of each other, and there have been no repeated attempts since then.

-- Nathan

<t>Hello,<br/>
<br/>
from my other forum entry somebody recommended to check this forum, too.<br/>
<br/>
My issue is pretty much the same, but for now, I am unable to create another user. When I created one, logged out from Winbox, right after I was unable to log in.<br/>
<br/>
I tried the default admin, I logged in with it, and saw my new user was deleted ...<br/>
<br/>
How on Earth could this possible?</t>

- Laszlo

How on Earth could this possible?</t>

- Laszlo

Are you REALLY asking that? Did you read the topic and other topics about MikroTik hacks first?
For now, netinstall your router to the current stable release and RESET it to factory default config.

Are you REALLY asking that? Did you read the topic and other topics about MikroTik hacks first?
For now, netinstall your router to the current stable release and RESET it to factory default config.

Thank you for that, I will do.

I am just wondering the attack vector, to understand how they penetrated it? I read many of the forums, but there are just some ideas on that, not a real analytics. Do you have idea? Thanks

Seeing what video is shown in the redirect, it probably was a single-shot attack by some activist, that you will not see continuing all the time.
(maybe there will be a couple more shots, depending how much money they want to spend at their "exploit as a service" provider)

But of course, when there really is a vulnerability, it could also come back with other payloads.

More interesting would be to find an unimportant router that was attacked, remove the added rules and change the password (but not the username), and see if it is attacked again.

I have done it, just waiting for to know, wether they can penetrate thru the changed password, or not.

I am just wondering the attack vector, to understand how they penetrated it?

You fouled up the firewall. And now we can only hope you won't do it again after reinstalling and resetting to defaults.
Do not touch firewall settings until you know how it works and what are the consequences of your changes!
(the new software makes it less likely to go wrong, with older RouterOS it would already be bad to add a PPPoE client without knowing how, but now that does not work out so badly anymore)

In a way, the affected owners should be thankful for the wake-up call and that the payload was so benign!
Any updates / new events on the topic?

The answer to the thread question posed in the title...... is
NO, same old same old. What we do seem to have is new users making the same old mistakes or integrating their new mistakes with past mistakes.
Operator error, do not pass Go, do not collect $200.
Look in the mirror, duplicate the phenomena of one hand clapping
Use netinstall with the latest firmware
Be happy with the default firewall and dont make changes until you know WTF you are doing.
Follow the basic advice on how to secure your router as provided by MT.

External access to Router is verbotten, if necessary consider VPN as the go to method and port-knocking if really lazy.
External access to LAN subnets may not be avoidable and if so consider only Servers that are https connected and password protected as a starting point, and if there are other ways of ensuring only authorized users even better. I am not a whiz bang scripter but there is probably ways to script detection and denying of unsuccessful login attempts.
(best if you can limit external WANIP to lan subnets by firewall access list in NAT rule - which effectively hides port from being visible from scans, without access list restriction such ports show as visible but closed on scans)

Internal access to Router is extremely limited. Only to admins is a prime directive. You may need to allow users to access port 53 for DNS services.

For business users close your ears to the next advice, its for home use with real users LOL.
You may need to allow a user/pc access to UPNP service if so bold (but VLAN that IP to its own VLAN and only allow access to internet for that vlan subnet).