My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Spoofed SNMP Messages: Mercy Killings of Vulnerable Networks or Troll?

Published: 2014-09-15. Last Updated: 2014-09-16 02:50:39 UTC
by Johannes Ullrich (Version: 4)
15 comment(s)

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.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

15 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

I started seeing these at 2014-09-14 21:35 UTC. I see one probe about every 20 minutes in numerical order to a class C, starting with .1. I don't have any packet captures, though, just firewall logs.

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
We started seeing these at 16:36 (CDT) yesterday. Pattern is same as JimC: one hit on a single IP every 20 minutes, working thru our class C in sequence. no packet-caps.
It appears someone is trying to brick devices, not conduct a reflection attack. We are also seeing our entire IP range hit. For each class C range the IP address being targeted increments by 1 every 20 minutes. They are attempting to set ipDefaultTTL to 1 and ipForwarding to 2 (not forwarding), using a community string of "private".
Yes I also noticed this activity from 8.8.8.8 against our perimeter over the weekend. Our IPS blocked all attempts as we don't allow ingress SNMP. I was wondering what was going on with Google's DNS @ 8.8.8.8 so this post has been informative for me. Thanks.
Hi

We see this traffic too.

Best, Daniel
A /16 here. Judging from our logs, the attacker is incrementing the third octet of the address before the fourth. Attacks are coming in approximately one every 4 seconds which is approximately 17 minutes before the fourth octet is incremented.

Attacks appear to have started @ 2014-09-14T21:28:07+00:00
Confirm, but got only flows. Unfortunately this farming will produce results... (dst ips omitted)

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
Just noticed something in the flows, it scanned our network but instead of scannig a full /24 host by host it scans a /32 in blocks of /24 in the same minute, check (a way of avoiding some auto measures...)

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
Only saw one request in the past week from 8.8.8.8 to port 161. Approx 10:00AM AEST today. Not seeing the repeat requests like the others though.
[quote=comment#31971]Just noticed something in the flows, it scanned our network but instead of scannig a full /24 host by host it scans a /32 in blocks of /24 in the same minute, check (a way of avoiding some auto measures...)

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.

Diary Archives