MikroTik

MicroTik RouterOS 3.13 SNMP write (Set request) PoC
PocCod is published in Internet.

don't make me laugh =)

http://www.milw0rm.com/exploits/6366

I have not tested this. From the comment at the bottom it looks like it changes your '/system identity'. Not sure.

I assume that you must know the snmp community string. If you enabled snmp and left it public or something in the dictionary then shame on you. Also beware that spoofing the source ip address on a snmp packet is a no brainer, so your firewall must disallow snmp based on something other than source ip address.

This appears to be 99% similar (and from the same author) as the successful MicroTik RouterOS <=3.2 SNMPd snmp-set DoS exploit of february of this year. The 3.2 bug did work great.

I did not get it to work on 3.13 or 2.9.51 though.

I did not have any effect. I captured it's work against a 3.13 router and the packet says write is not supported.



I hope it's indeed a dud and would welcome others to do further testing or documenting. If it's real, I'd be really upset that mikrotik isn't prepared for something 99% similar to the stupid bug in february.

successfully tested on 3.13 powerpc (rb333).

another... remote vulnerability

I have written in past a firewall-listing that collects information for incoming connections like ssh, winbox, neighboors, bw test. I couldn't believe that snmp could be tricky. I will rewrite this listing and I will post it. Is it appropriate to be on wiki ?

Wiki would be good. Keep in mind that this program successfully spoofs IPs, so your rule should not rely on source IPs.

Don't worry. This exploit is not malicious or harmful, just proof of concept code. This is feauture, not a bug in the clear way=)
BTW you can specify hardguessing snmp community and filter requests with L7 filter: I have recorded demonstration screencast of routeros 3.13 on rb333 vulnerability.

First thing to do here is set reasonable community strings. Use of "public" or a dictionary word as a community string is akin to leaving your door unlocked when you go on vacation. That's the "best" advice.

The next thing is to control access to UDP/161 at the border. Just two rules will stop that: At each host that is running SNMP for monitoring, you have to control it based on a good community string AND source IP. In each of your routers inside your network, you have to build similar rules to control access to the snmp port in order to protect yourself from devices inside your network.

Don't worry. This exploit is not malicious or harmful, just proof of concept code. This is feauture, not a bug in the clear way=)

This is really the kicker, huh?

BTW you can specify hardguessing snmp community and filter requests with L7 filter:

Code: Select all

/ip firewall layer7-protocol 
add comment="snmp-set request filter by shados" name="snmp-set" regexp="^\\x30.\\x02\\x01\\.\\x04.+\\xA3.*" 

This is true, but adds a lot of overhead that is not really needed. L7 firewall is a heavy hitter in terms of CPU on a busy router. It's use must be carefully monitored. Depending on the network design, my earlier post is sufficient for most applications.

I have recorded demonstration screencast of routeros 3.13 on rb333 vulnerability.

Care to share? Post a link.

Don't worry. This exploit is not malicious or harmful, just proof of concept code. This is feauture, not a bug in the clear way=)
BTW you can specify hardguessing snmp community and filter requests with L7 filter:

Code: Select all

/ip firewall layer7-protocol 
add comment="snmp-set request filter by shados" name="snmp-set" regexp="^\\x30.\\x02\\x01\\.\\x04.+\\xA3.*" 

I have recorded demonstration screencast of routeros 3.13 on rb333 vulnerability.

I'm not satisfied that that filter will stop variations of this exploit. Everyone has the source code for it, so they could alter it in any way that is effective.

Butch's idea to stop snmp as it comes in to your network will reduce 99% of the risk.

I'm not satisfied that that filter will stop variations of this exploit. Everyone has the source code for it, so they could alter it in any way that is effective.

Butch's idea to stop snmp as it comes in to your network will reduce 99% of the risk.

I must repeat - exploit is not harmful!
And my L7-filter stops all possible queries snmp-set. You will understand it if you take a closer look at the format of the snmp v1 packet.
About my video - it will be posted when tiktube will start working.
BTW 3.7 x86 (RB230) tested sucsessefully.

video with demonstration of my exploit:
http://rapidshare.com/files/143620612/s ... t.zip.html

rapidshare sucks : )

http://h1x.com/mt/snmp_write.html

I converted your video to a flash video 10x smaller size, you dont mind. View using above URL.

PS - What we still don't know is if anything else is writable. Changing system identity isn't a big deal but it sure is if you could use this to do anything else.

Thanks, Sam. I was not able to view the rapidshare link.

rapidshare sucks : )
PS - What we still don't know is if anything else is writable. Changing system identity isn't a big deal but it sure is if you could use this to do anything else.

rapidshare is best than disfunctional tiktube =)
I'll try to find somthing more than "/system identity". Just wait a while.

As far as i can see, it works on all MT 3.X, but not on 2.X.
Comment said:
Vulnerable versions: 2.9.51 (2.9.x branch), 3.13 (3.x branch)
But it didn't work on 2.9.X i have been tested...
The program spoofs the source ip by using raw sockets.

rapidshare sucks : )
PS - What we still don't know is if anything else is writable. Changing system identity isn't a big deal but it sure is if you could use this to do anything else.

rapidshare is best than disfunctional tiktube =)
I'll try to find somthing more than "/system identity". Just wait a while.

tiktube won't be able to host such large screencasts anyway. the video size (dimensions) is limited. maybe we will make screencast size support in new tiktube

maybe we will make screencast size support in new tiktube

It is great idea! I will wait for that. I have a lot of training videos for RouterOS, which I would like to share.
normis, what's about the license for the author of the exploit?

how will we know if that 800x600px video is not actually an uncompressed MPEG2, but some small sized screencast?

about the "bug". the only bug here is that snmp-write is enabled by default, and is not documented. you don't need this fancy program, just this command would suffice:
so SNMP-write IS SUPPORTED, but not yet added to manual (as you know, v3 manual is not ready)

how will we know if that 800x600px video is not actually an uncompressed MPEG2, but some small sized screencast?

about the "bug". the only bug here is that snmp-write is enabled by default, and is not documented. you don't need this fancy program, just this command would suffice:

Code: Select all

snmpset -c public -v 1 10.0.0.35 SNMPv2-MIB::sysName.0 s kaka

so SNMP-write IS SUPPORTED, but not yet added to manual (as you know, v3 manual is not ready)

OK, because we both know that you are right. And code was created only to draw attention to the "problem" =) Thanks for support.

I hope it's indeed a dud and would welcome others to do further testing or documenting. If it's real, I'd be really upset that mikrotik isn't prepared for something 99% similar to the stupid bug in february.

to clarify again - there is no exploit or vulnerability. you can simply change the identity with a valid SNMP-write command. plus see my other post

so SNMP-write IS SUPPORTED, but not yet added to manual (as you know, v3 manual is not ready)

Normis,
What other MIBs are writable? This can be a critical vulnerability if it's not documented anywhere. Is that the only place we can SNMP-write?

This DOES affect (potentially) more than just the sytem name/identity. Suppose I have a script (which I DO), but the script supposes the system identity is a certain thing. If this gets changed, my script no longer works. That could be very bad, especially if the script is a backup script and my tower is destroyed by lightening. Then I have no backup.

There are many examples I could list, but you can come up with your own set of examples.

I hope it's indeed a dud and would welcome others to do further testing or documenting. If it's real, I'd be really upset that mikrotik isn't prepared for something 99% similar to the stupid bug in february.

to clarify again - there is no exploit or vulnerability. you can simply change the identity with a valid SNMP-write command. plus see my other post

If a stranger can alter something on my MT with snmp, it is both an exploit and vulnerability.

better make sure that snmp isn't reachable to your router.

also, MT, please make a checkbox in snmp config to disable snmp writes!

already done, next version has snmp-write configuration, lack of which WAS the bug!

an exploit is something that was not intended by the makers of the software, and can be used to do bad things to your device.

by your definition, winbox and telnet are also exploits, because by default they are open, and there is a known default password.

SNMP write supported options,
http://wiki.mikrotik.com/wiki/SNMP_Write

already done, next version has snmp-write configuration, lack of which WAS the bug!

an exploit is something that was not intended by the makers of the software, and can be used to do bad things to your device.

by your definition, winbox and telnet are also exploits, because by default they are open, and there is a known default password.

Also all interfaces should be disabled by default in "ip->neighbors" or to be active only for local networks, not for routed.

Its possibly someone to connect to the listening port of "ip->neighbors" and spam the neighbor list by sending data for fake mac-addresses/routers. Except from spamming the list, you are also able to make cpu reach 100% with these connections. What will happen if mikrotik believes that has 1.000.000 neighbors? Believe or not, it is just a code with a loop that creates random mac's...

Did you know that there it is possible to crash(and auto-reboot...) a mikrotik router via bwtest(if it has auth disabled) using nmap on port 2000? If auth is enable, you may fill the log file with fake messages

I should suggest to have any listening port disabled, except ssh and (encrypted by default) winbox. Also any listening port(neighbors, bwtest, snmp r/w, radius, web, ftp, etc.) should be managed in "ip->services" or just listed in order to be disabled.

Microsoft Windows used to be vulnerable because of this mistake, lots of ports in listening mode. A little bit more and Antivirus for Mikrotik will be released :P

did you know that default installation of routerOS is considered to be unsafe, because there isno password, many processes are listening on every interface etc. thats why you have to configure your router and set up firewall, acl, disable everything you do not need, want to be exposed.

Did you know that there it is possible to crash(and auto-reboot...) a mikrotik router via bwtest(if it has auth disabled) using nmap on port 2000? If auth is enable, you may fill the log file with fake messages

How do you able to crash the router, which version of the RouterOS and on which hardware ?

did you know that default installation of routerOS is considered to be unsafe, because there is no password, many processes are listening on every interface etc. thats why you have to configure your router and set up firewall, acl, disable everything you do not need, want to be exposed.

Yes thats true, but administrator must be informed (with a message box at first login) that
"system should be configured properly"
"system has tricky processes running and the processes mplah mplah mplah are the most tricky"

If you want my advice, almost nothing should be active, except ssh and winbox and administrator will enable anything he wants one by one. You may also ask after installation for what services will be enabled. You may setup admin's password at installation.

Many Linux distributions work that way.

Did you know that there it is possible to crash(and auto-reboot...) a mikrotik router via bwtest(if it has auth disabled) using nmap on port 2000? If auth is enable, you may fill the log file with fake messages

How do you able to crash the router, which version of the RouterOS and on which hardware ?

All the vulnerabilities that I have wrote before, are active in any version for any hardware, I think that it is iperf's bug not mikrotik's. You will find all the vulnerabilities listed and descripted soon in another site. For the moment I am too busy.

I suggest reading the manual before using an advanced system as a router. we give the users the flexibility to choose configuration depending on their needs.

Did you know that there it is possible to crash(and auto-reboot...) a mikrotik router via bwtest(if it has auth disabled) using nmap on port 2000? If auth is enable, you may fill the log file with fake messages

How do you able to crash the router, which version of the RouterOS and on which hardware ?

Run
nmap -sV -p 2000 Mikrotik_ROUTER_IP
and wait about 1min..

didn't work for us. nothing crashed

Run
nmap -sV -p 2000 Mikrotik_ROUTER_IP
and wait about 1min..

Which version of nmap do you use? Which version of routeros do you use? router architecture (ppc, mipsel, mipsbe, x86)?
Did not works with nmap 4.68, 4.75 and routeros 3.18 on mipel.

I was unable to get it to reboot, too. nmap 4.53, tried on RB433 and RB133 latest RouterOS version.

I have test it with ver.
2.9.27
2.9.45
2.9.50
2.9.51 (?)
3.13 (didn't work)

so what's the issue here? new version fixes the problem. no more problem. period