Update on the UDP strange packets
Mike Poor, stepping in for Pedro Bueno until he is back online
Update on the UDP strange packets
I would like to thank over 50 people that sent packets, logs and theories into the ISC and to me personally. We still do not know "what" or "why", but we do know a number of things:
- About 30 sources are being used in these packets, all from the 83.102.166.0/24 netblock
- Firewalls and IDS'es seem to be misrepresenting port numbers in a parser error (either showing src and dst ports as being 65535 or 16191)
- Destinations are all DNS servers, and seem to be the authoritative name server for the zone
- Some destinations are not actually DNS servers, but they are listed as Authoritative servers for that zone
- Destinations are all over the world, from educational institutions, government, commercial, and non profit (.org)
The payload of the packet seems to be a crafted recursive query for root ("."). Master packet guru George Bakos reconstructed the packet using Netdude (netdude.sourceforge.net) fixed the checksum, and ran it through tethereal. This is what tethereal comes up with:
Tom Liston , of Labrea | GDI Scanner | Color Orange | or Bouncing Malware fame, did some statistical analysis on the source addresses that he was receiving and notices that only about 30 of the possible 254 addresses from the /24 network were being used, with a non even distribution of randomness. Here is the statistical output:
The main thing to find now is to look for these packets leaving someone's network. This would show if this is some broken client or malicious code.
Grand Mistress of Packetdom Judy Novak from Sourcefire noticed that in bytes 6 & 7 offset from zero of the IP header, we see 0x 00 40 (hence the 512 frag offset). If some lame coder hardcoded these numbers, and perhaps did not do a host to network byte order swap (which would have made the bytes 0x 40 00 which would correspond to the Dont Fragment DF flag being set).
If you see this traffic leaving your network, or if you see any responses fromyour hosts to this traffic, please send us packets.
A special thanks to all who have contributed with time, packets, and continued analysis,
Mike Poor
From Yesterday's diary on this subject:
Strange UDP packets everywhere
A poster to the ISC sent us some strange UDP packets he had been seeing on his network. The first strange thing that comes to view is that all the fragments included in the traces are the last fragment of a fragment train, and all of them placed 25 bytes of data at offset 512 (which coincides with the maximum payload for DNS replies over UDP (eDNS not withstanding).
Here is some sample traffic that was posted to Dshield back in October, that perfectly matches what the current poster is seeing:
Another odd thing is that all similar traffic we have seen is coming out of this same netblock 83.102.166.0/24 which belongs to corbina.net out of Russia.
Has anyone seen similar traffic? You can capture this traffic with the following tcpdump filter:
tcpdump {options to your liking} 'src net 83.102.166 and (ip[6] & 0x02 = 0 and ip[6:2] & 0x1fff !=0)'
If you see packets, please send them to the ISC.
(P.S. We have also heard a rumor that there might be some packets that are not
quite like the others! If you're interested in hunting them, add "and ip[2:2] != 45" into that tcpdump command above! Thanks!)
Update on the UDP strange packets
I would like to thank over 50 people that sent packets, logs and theories into the ISC and to me personally. We still do not know "what" or "why", but we do know a number of things:
- About 30 sources are being used in these packets, all from the 83.102.166.0/24 netblock
- Firewalls and IDS'es seem to be misrepresenting port numbers in a parser error (either showing src and dst ports as being 65535 or 16191)
- Destinations are all DNS servers, and seem to be the authoritative name server for the zone
- Some destinations are not actually DNS servers, but they are listed as Authoritative servers for that zone
- Destinations are all over the world, from educational institutions, government, commercial, and non profit (.org)
The payload of the packet seems to be a crafted recursive query for root ("."). Master packet guru George Bakos reconstructed the packet using Netdude (netdude.sourceforge.net) fixed the checksum, and ran it through tethereal. This is what tethereal comes up with:
Internet Protocol, Src Addr: 83.102.166.46 (83.102.166.46), Dst Addr: x.x.x.75
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 45
Identification: 0x1e65 (7781)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 55
Protocol: UDP (0x11)
Header checksum: 0xf835 (correct)
Source: 83.102.166.46 (83.102.166.46)
Destination: x.x.x.75 (x.x.x.75)
User Datagram Protocol, Src Port: 4591 (4591), Dst Port: 53 (53)
Source port: 4591 (4591)
Destination port: 53 (53)
Length: 25
Checksum: 0x0a7a (correct)
Domain Name System (query)
Transaction ID: 0x71f7
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
<Root>: type NS, class inet
Name: <Root>
Type: Authoritative name server
Class: inet
0000 02 02 02 02 02 02 01 01 01 01 01 01 08 00 45 00 ..............E.
0010 00 2d 1e 65 00 00 37 11 f8 35 53 66 a6 2e XX XX .-.e..7..5Sf...E
0020 XX 4b 11 ef 00 35 00 19 0a 7a 71 f7 01 00 00 01 .K...5...zq.....
0030 00 00 00 00 00 00 00 00 02 00 01 00 ............
Tom Liston , of Labrea | GDI Scanner | Color Orange | or Bouncing Malware fame, did some statistical analysis on the source addresses that he was receiving and notices that only about 30 of the possible 254 addresses from the /24 network were being used, with a non even distribution of randomness. Here is the statistical output:
Count IP %
39 22 2.11%
40 42 2.16%
41 4 2.22%
43 58 2.33%
46 47 2.49%
47 17 2.54%
48 55 2.60%
49 1 2.65%
49 26 2.65%
49 53 2.65%
53 48 2.87%
54 43 2.92%
55 49 2.98%
58 7 3.14%
58 76 3.14%
59 41 3.19%
59 59 3.19%
61 45 3.30%
62 217 3.35%
64 54 3.46%
64 15 3.46%
64 12 3.46%
66 23 3.57%
70 33 3.79%
70 52 3.79%
71 44 3.84%
73 131 3.95%
109 21 5.90%
111 24 6.01%
116 46 6.28%
The main thing to find now is to look for these packets leaving someone's network. This would show if this is some broken client or malicious code.
Grand Mistress of Packetdom Judy Novak from Sourcefire noticed that in bytes 6 & 7 offset from zero of the IP header, we see 0x 00 40 (hence the 512 frag offset). If some lame coder hardcoded these numbers, and perhaps did not do a host to network byte order swap (which would have made the bytes 0x 40 00 which would correspond to the Dont Fragment DF flag being set).
If you see this traffic leaving your network, or if you see any responses fromyour hosts to this traffic, please send us packets.
A special thanks to all who have contributed with time, packets, and continued analysis,
Mike Poor
From Yesterday's diary on this subject:
Strange UDP packets everywhere
A poster to the ISC sent us some strange UDP packets he had been seeing on his network. The first strange thing that comes to view is that all the fragments included in the traces are the last fragment of a fragment train, and all of them placed 25 bytes of data at offset 512 (which coincides with the maximum payload for DNS replies over UDP (eDNS not withstanding).
Here is some sample traffic that was posted to Dshield back in October, that perfectly matches what the current poster is seeing:
10:13:19.754558 83.102.166.48 > aa.bb.cc.71: (frag 25411:25@512) (ttl 55, len 45)
0x0000 4500 002d 6343 0040 3711 d0ca 5366 a630 E..-cC.@7...Sf.0
0x0010 xxxx xx47 11ef 0035 0019 282d 71f7 0100 ...G...5..(-q...
0x0020 0001 0000 0000 0000 0000 0200 016f .............o
10:13:20.674641 83.102.166.7 > aa.bb.cc.71: (frag 38795:25@512) (ttl 55, len 45)
0x0000 4500 002d 978b 0040 3711 9cab 5366 a607 E..-...@7...Sf..
0x0010 xxxx xx47 11ef 0035 0019 2856 71f7 0100 ...G...5..(Vq...
0x0020 0001 0000 0000 0000 0000 0200 0106 ..............
10:13:27.211002 83.102.166.33 > aa.bb.cc.71: (frag 9664:25@512) (ttl 55, len 45)
0x0000 4500 002d 25c0 0040 3711 0e5d 5366 a621 E..-%..@7..]Sf.!
0x0010 xxxx xx47 11ef 0035 0019 283c 71f7 0100 ...G...5..(<q...
0x0020 0001 0000 0000 0000 0000 0200 0148 .............H
Another odd thing is that all similar traffic we have seen is coming out of this same netblock 83.102.166.0/24 which belongs to corbina.net out of Russia.
Has anyone seen similar traffic? You can capture this traffic with the following tcpdump filter:
tcpdump {options to your liking} 'src net 83.102.166 and (ip[6] & 0x02 = 0 and ip[6:2] & 0x1fff !=0)'
If you see packets, please send them to the ISC.
(P.S. We have also heard a rumor that there might be some packets that are not
quite like the others! If you're interested in hunting them, add "and ip[2:2] != 45" into that tcpdump command above! Thanks!)
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments