Not your regular bot driven UDP flood

After weeks of battling Joomla/JCE sites that insist on running evil code and spewing denial of service traffic, we had a machine today sending UDP floods. This, it turns out, is not a hacked machine sending spews of botnet traffic – although it seems to be — UDP sent without port numbers, tons of it — maybe it’s some kind of raw packet driver running as LOCAL_SYSTEM – but it turns out not to be:

11:21:15.948103 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948105 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp

It’s SNMP – simple network management protocol – sending a particularly large response to a tiny query string.  The complete dump starts with a tiny request for a large SNMP mib.  For 79 bytes sent, the attacker gets 64kb or so delivered to his target:

11:21:15.917383 ethertype IPv4 (0x0800), length 79: 82.157.102.178.80 > 10.0.40.133.161:  GetBulk(22)  N=0 M=2250 .1.3.6.1
11:21:15.948093 ethertype IPv4 (0x0800), length 1514: 10.0.40.133.161 > 82.157.102.178.80:  [len1468<asnlen51916] 11:21:15.948096 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948100 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948102 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948103 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948105 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948110 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948111 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948112 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948112 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948113 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948114 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948285 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948289 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948290 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948291 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948294 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948295 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948353 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948355 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948513 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948516 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948517 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948519 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948520 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948521 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp
11:21:15.948522 ethertype IPv4 (0x0800), length 1514: 10.0.40.133 > 82.157.102.178: udp

Notice that the fragments (which are the bulk of the response) are not labelled with the port number, so it’s pretty hard to identify what they are about.

This amplification is so much better than

dig @10.0.40.133 any isc.org

The particularly stupid part about this is that the SNMP request only arrived at the box because the upstream firewall rules changed (a hardware upgrade that stupidly involved unintentional configuration changes).

This entry was posted in Stuff and tagged , , , , . Bookmark the permalink.