RE: DNS ID , SPAM , CITI BANK
"lee forrest" <[email protected]>
| Newsgroups | gmane.comp.security.intrusions |
|---|---|
| Message-ID | <[email protected]> |
Hi Dana DNS ID: Sounds like a chamelion http://www.biblioteca.co.cr/html/dnshacking.shtml SPAM: Chris your right I have to get a new day job. CITI BANK: A good friend of mine from Switzerland received a fax saying "This is Citi Bank , please send us your bank details and pin number to update out records", If anyone knows anything about this can they reply please , or if they need more information from my friend in Zurich then please just ask. Its FASinatiNG what people will try. >From: [email protected] >Reply-To: [email protected] >To: [email protected] >Subject: Intrusions Digest, Vol 6, Issue 1 >Date: Wed, 1 Sep 2004 11:51:26 GMT > >Send Intrusions mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.dshield.org/mailman/listinfo/intrusions >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Intrusions digest..." > > >Today's Topics: > > 1. Re: LOGS: GIAC GCIA Version 3.4 Practical Detect Roch Decoste > (Dana Webber) > 2. RE: RE: All in One Spam filter Antivirus , Bayesian , DNS > ,etc, Dot Net. (Meidinger Chris) > 3. RE: New Trojan on the block [CIA Trojan] (Davis, Myron) > 4. LOGS: GIAC GCIA Version 3.5 Practical Detect Rusma Mulyadi > (Rusma Mulyadi) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 31 Aug 2004 09:26:17 -0400 >From: Dana Webber <[email protected]> >Subject: Re: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect > Roch Decoste >To: "Intrusions List \(GCIA Practicals\)" <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain; charset="iso-8859-1" > >What was the attackers OS? > >On Monday 30 August 2004 09:44, you wrote: > > > msg:"DNS named ver..." - Title of the alert. > > 3) Probability the source address was spoofed > > --------------------------------------------- > > Very low. This is a reconnaissance type probe generated using a UDP > > packet. UDP packets can very easily be spoofed, however should the > > attacker have spoofed the source IP address any responses generated by >the > > victim would never be seen by the attacker. Unless, both the recipient >and > > the attacker are on the same collision domain. > >How do you know that the attacker is not trying to "set up" an innocent >person to >get them in trouble.? > > > 4) Description of the attack > > ---------------------------- > > The attack consisted of a single UDP packet which queried a DNS server >for > > its BIND version. The same request was sent to two distinct hosts > > approximately 4 minutes apart (refer to section 1B for a detailed view >of > > the two packets). An analysis of the packets did not reveal any > > abnormalities from the IP and UDP headers. The source IP id and port > > numbers are different in both cases and the absolute time at which the > > packets were sent also appear to be random. Up to this point there is >no > > evidence of scripting involved to conduct these reconnaissance attacks. > > > > The only discrepancy identified in the analysis of these two packets is > > that they both have the same DNSid of 4660. Both nslookup and dig > > utilities were thoroughly tested in a lab network in an effort to >recreate > > these packet anomalies, however none of these had the functionality to > > allow a user to specify a DNSid number. > > > > A very interesting tool was uncovered during the research phase of this > > detect. NETWOX, authored by Laurent Constantin, is a toolset providing > > over 150 amalgamated utilities to help resolve network problems. One of > > the tools enabled users to obtain a BIND DNS server's version number. >It > > allowed the user to specify values for a multitude of fields in the DNS > > query packet, however it did not provide the ability to specify a DNSid. > > > > When tested in a lab environment NETWOX behaved in the same fashion as >dig > > and nslookup. It did not leave any distinguishable fingerprints The >DNSid > > value (4660) has also been identified in many other binary log files >made > > available on the SANS website. I spent quite a bit of time researching > > this oddity, unfortunately the only information which could be found >where > > past GCIA detects posing the same question. The following links point >to > > GCIA detects produced by Kahleong Fong and Steve Gamble, both of which > > encountered the same question, 'why is the DNSid set to 4660 for >multiple > > BIND version queries?': > > http://www.dshield.org/pipermail/intrusions/2003-March/007104.php > > http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html > >What about hping2 ? > >-- >Dana Webber >[email protected] >http://dunrobin.dyn.dhs.org > >Getting a computer system to work is like banging your head against a brick >wall until the wall falls down. > > > >------------------------------ > >Message: 2 >Date: Tue, 31 Aug 2004 18:34:57 +0200 >From: Meidinger Chris <[email protected]> >Subject: RE: [Intrusions] RE: All in One Spam filter Antivirus , > Bayesian , DNS ,etc, Dot Net. >To: "Intrusions List (GCIA Practicals)" <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain > > > > >Hi > > >You can create a distribution list in Microsoft Outlook and allso > > >program your own spam filter using VBA for outlook , just write some > > >code for the MAPI , ( Mail applications Programming > > Interface ) , why > > >spend money on something when you can learn to write it yourself. > >What do you earn an hour? --> How many hours do you have to work to pay the >price of a single-seat AV license? > ><troll> >wouldn't it adhere more closely to esr's hacker howto to pitch in on an >open-source AV project and help the community than it does to reinvent the >wheel (and keeping it for yourself) by implementing extremly simple filters >in your outlook? Isn't your productive coding time worth more than >implementing a funktion that's been done by others many times? ></troll> > ><whine> >but that doesn't mean i don't wish i had the kind of time on my hands to >spend a few days implementing spam filters directly in outlook with vba - >probably very interesting. >particularly considering all the other things i would have done by then ... ></whine> > >Cheers, > >Chris > > >------------------------------ > >Message: 3 >Date: Tue, 31 Aug 2004 13:21:46 -0800 >From: "Davis, Myron" <[email protected]> >Subject: RE: [Intrusions] New Trojan on the block [CIA Trojan] >To: "'Intrusions List (GCIA Practicals)'" <[email protected]> >Message-ID: > <D0CD1BF9C88ED511B6E100508BBB43BD049149BE@jnu-exchange.dec.state.ak.us> > >Content-Type: text/plain > >I don't know where you generated the list, but please add clamav (the open >source virus definitions) to that list. > >http://www.clamav.net/sendvirus.html > >There are a lot of people using the windows (http://clamwin.net) and unix >ports of this GPL scanner. > >-Myron > >-----Original Message----- >From: Nick FitzGerald [mailto:[email protected]] >Sent: Sunday, August 29, 2004 3:08 PM >To: [email protected] >Subject: Re: [Intrusions] New Trojan on the block [CIA Trojan] > ><snip> > > Authentium (Command Antivirus) <[email protected]> > Computer Associates (US) <[email protected]> > Computer Associates (Vet/EZ) <[email protected]> > DialogueScience (Dr. Web) <[email protected]> > Eset (NOD32) <[email protected]> > F-Secure Corp. <[email protected]> > Frisk Software (F-PROT) <[email protected]> > Grisoft (AVG) <[email protected]> > H+BEDV (AntiVir, Vexira engine) <[email protected]> > Kaspersky Labs <[email protected]> > Network Associates (McAfee) <[email protected]> > (use a ZIP file with the password 'infected' without the quotes) > Norman (NVC) <[email protected]> > Panda Software <[email protected]> > Sophos Plc. <[email protected]> > Symantec (Norton) <[email protected]> > Trend Micro (PC-cillin) <[email protected]> > (Trend may only accept files from users of its products) > >Most of these addresses are monitored either by 24x365 malware support >and analysis teams, or have distributed processing around the globe >providing (close to) 24x365 coverage. Several have automated code >analysis systems that get the "first look" at submitted files, >classifying them for further attention or simply sending back canned >reports of the "we detect it in the DEF update that should ship at X or >you can download a pre-QA copy at Y". Depending on the nature of the >files you submit, you should get several quite prompt responses, at >some of which you'll have to ignore (e.g. a downloader detection is >pretty meaningless as the target of a downloader is usually considered >to be a non-code variable and ignored by any semi-intelligent detection >of that downloader, so the same downloader can be used multiple times >configured to snag stuff from different URLs and will always be >detected as the same downloader and variant). > > >-- >Nick FitzGerald >Computer Virus Consulting Ltd. >Ph/FAX: +64 3 3529854 > >_______________________________________________ >Intrusions mailing list >[email protected] >http://www.dshield.org/mailman/listinfo/intrusions > > >------------------------------ > >Message: 4 >Date: Tue, 31 Aug 2004 18:36:40 -0700 >From: Rusma Mulyadi <[email protected]> >Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect > Rusma Mulyadi >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=windows-1252; format=flowed > >This is my 1st detect for the GCIA Practical. >Feel free to comment. :) > >Thanks, >Rusma > > >Detect 1: Misc. Tiny Fragments > >Source of Trace: >---------------- >The source of this detect is obtained from >http://isc.sans.org/logs/Raw/2002.6.1 - 2002.6.18 and dated from >06/30/02 to 07/18/02. > >Several key points to keep in mind throughout this network detect:1 >* Only packets that violate the Snort rule set appear in these log files >* The logs have been sanitized: >a. The IP addresses of the protected network space have been munged >b. The checksums have also been modified >c. Certain keywords have been modified >d. All ICMP, DNS, SMTP and web traffic has been removed > >These log raw log files are then combined into a single file called >2002.6.all using pcapmerge2, downloaded as part of tcpreplay package3. ># pcapmerge o 2002.6.all 2002.6.* >-o <file>: used to specify the name of the combined output file. > >The next section discusses the network layout of this detect based on >the tcpdump4 command and its sample output below. > ># tcpdump ennqr <filename> > >-e prints the link-level header, containing physical/MAC addresses >-nn disables the host name and port translations >-q quick output with less protocol information >-r reads in the merged raw log file > >17:31:16.304488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 60: 211.152.3.40.80 > >46.5.15.174.80: tcp 0 > >The fields of the above tcpdump output format delimited by >spaces/blanks that will be analyzed further in this section are: >Field# Description >2 Source MAC Address >3 Destination MAC Address >5 Source IP Address and Port >7 Destination IP Address and Port > >To obtain the unique source MAC addresses, the second field of the >sample output above is uniquely sorted. The resulted source MAC >addresses are printed together with their number of occurrences in the >entire log: > ># tcpdump -ennqr 2002.6.all | awk '{print $2}' | sort | uniq -c >32479 0:0:c:4:b2:33 >6406 0:3:e3:d9:26:c0 > >The third field of the output file identifies the destination MAC >addresses and is printed below: > ># tcpdump -ennqr 2002.6.all | awk '{print $3}' | sort | uniq -c >6406 0:0:c:4:b2:33 >32479 0:3:e3:d9:26:c0 > >In addition to the fact that the counts of both MAC addresses as the >source and destination addresses are exactly reversed, both MAC >addresses are also registered to Cisco Systems according to the >information shown below from the IEEE OUI Registration database5. >Therefore, these logs are generated by an intrusion detection system >(sniffer) that sits between two Cisco devices. > >00-00-0C (hex) CISCO SYSTEMS, INC. >00000C (base 16) CISCO SYSTEMS, INC. >170 WEST TASMAN DRIVE >SAN JOSE CA 95134-1706 > >00-03-E3 (hex) Cisco Systems, Inc. >0003E3 (base 16) Cisco Systems, Inc. >170 West Tasman Dr. >San Jose CA 95134 >UNITED STATES > > >To further understand the location of these devices within the network: > >1. The distinct source IP addresses (field #5) coming from 0:0:c:4:b2:33 > ># tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print >$5}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort | >uniq -c | sort -rn >32434 46.5.180.250 >45 46.5.180.133 > >2. The distinct destination IP addresses (field #7) coming from >0:0:c:4:b2:33 ># tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print >$7}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort | >uniq c | sort -rn >16700 64.154.80.51 >6339 66.128.224.70 >686 64.154.80.50 >522 208.45.133.13 ><snip> >1 12.216.161.118 >1 12.150.245.163 >1 12.111.145.134 > >At this point, it seems that 0:0:c:4:b2:33 is a Cisco device that sits >in front of a Class C internal network (46.5.180.0/24) at this point. > >3. The distinct source IP addresses (field #5) coming from 0:3:e3:d9:26:c0 > ># tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk >'{print $5}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort >| uniq -c | sort rn >683 255.255.255.255 >297 66.220.44.31 >180 203.122.47.137 >169 62.153.209.202 ><snip> >1 12.150.54.250 >1 12.107.51.109 >1 12.105.86.5 > >Based on the variety of IP addresses sourced from 0:3:e3:d9:26:c0, we >can conclude that it is most likely a border router that is located >between the Internet and the network in this particular trace. > >4. The distinct destination IP addresses (field #7) coming from >0:3:e3:d9:26:c0 > ># tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk >'{print $7}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort >| uniq -c | sort -rn | more >1714 46.5.180.250 >908 46.5.180.133 >381 46.5.80.149 >36 46.5.218.182 >28 46.5.130.100 >26 46.5.180.135 ><snip> >1 46.5.0.16 >1 46.5.0.139 >1 46.5.0.130 >1 46.5.0.10 > > >From this last output, we discover that the internal network is much >bigger than a Class C network. Instead, it looks more like a Class B >network (46.5.0.0/16). > >The network layout of this trace can then be summarized as: > >Intrusion Detection Systems >| >| >Internet --- Cisco Device 1 -----+------ Cisco Device 2 --- Internal >0:3:e3:d9:26:c0 0:0:c:4:b2:33 46.5.0.0/16 > > >5. The distinct destination ports coming from 0:0:c:4:b2:33 > >### Total unique destination ports coming from 0:0:c:4:b2:33 ># tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print >$7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn | wc -l >248 > >### List of unique destination ports coming from 0:0:c:4:b2:33 ># tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print >$7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn >29487 80: >851 6347: >552 1863: >410 6348: >95 5555: ><snip> >1 10508: >1 10450: >1 10222: >1 100: > >The existence of 248 unique destination ports of the outgoing traffic in >the entire log file indicates a loose egress filtering. However, it >seems that there are filters for the well-known Microsoft Windows ports >(135, 137-139, and 445) because none of them are found in these 248 >destination ports. The top 4 outgoing traffic corresponds to http (port >80), gnutella (port 6347 and 6348), MSN messenger (1863) and Napster >(port 5555).6 This is assuming that these ports are used by their normal >applications. > >6. The distinct destination ports coming from 0:3:e3:d9:26:c0 > >### Total unique destination ports coming from 0:3:e3:d9:26:c0 ># tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk >'{print $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn >| wc -l >717 > >### List of unique destination ports coming from 0:3:e3:d9:26:c0 ># tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk >'{print $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn >1704 80: >705 21: >683 515: >591 53: >416 6346: ><snip> >4 137: ><snip> >1 61002: >1 6000: >1 41992: >1 40195: >1 3514: > >The existence of 717 unique destination ports in the incoming traffic >that includes a Windows NetBIOS port 137 in the entire log file also >indicates a loose ingress filtering. Although it seems that the egress >filtering includes a block for well-known Windows ports, it does not >appear to be the case with regard to the ingress filtering. The top 3 >incoming traffic corresponds to http (port 80), ftp (port 21), printer >(port 515), domain name (port 53), and gnutella (port 6346).6 Again, >this is assuming that these ports are used by their normal applications. > >The limited ingress and egress filtering applied on this network is an >indication of a very loose network security policy implementation and it >fits the profile of typical .edu network. > > >Detect was generated by: >------------------------- > >This detect is generated using Snort Version 2.2.0 with all the rules >enabled. The latest rules are The snort.conf is modified to include as >the home network. The following command is used: ># snort -r 2002.6.all -c ../snort/etc/snort.conf -A full >-l alert612ALL/ -dey -k none > >-r <filename> read and process a tcpdump file >-c <cfgfile> use rules specified in the configuration file >-A <mode> alert mode (fast, full, console or none) >-l <log dir> specify the log directory >-d print the application layer information >-e display the 2nd layer header info >-y include year in timestamp of alert and log files >-k <mode> checksum mode (all, noip, notcp, noudp, noicmp, none) > > >SnortSnarf v021111.17 is then used to facilitate the alert analysis >process. > ># ./snortsnarf d alert612view/ alert612ALL/alert >-d <dir> specify the output directory >This detect will focus on the Misc Tiny Fragments signature alerts as >summarized in Figure 1 below. > >Figure 1 Misc Tiny Fragments Alerts Summary > >An alert on this signature is generated when a fragment packet (with >More Fragment M flag set) with a payload size (dsize) of less than 25 >bytes is received from the external network. Below is the corresponding >Snort rule8. >alert ip $EXTERaNAL_NET any -> $HOME_NET any (msg:"MISC Tiny Fragments"; >dsize:< 25; fragbits:M; classtype:bad-unknown; sid:522; rev:2;) >The 5 alerts of interest are: >[**] [1:522:2] MISC Tiny Fragments [**] >[Classification: Potentially Bad Traffic] [Priority: 2] >07/10/02-01:06:04.854488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C >64.26.170.95 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 DgmLen:40 MF >Frag Offset: 0x1FCB Frag Size: 0x0014 >[**] [1:522:2] MISC Tiny Fragments [**] >[Classification: Potentially Bad Traffic] [Priority: 2] >07/10/02-20:41:23.524488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C >80.136.103.85 -> 46.5.80.149 TCP TTL:241 TOS:0x0 ID:0 IpLen:20 DgmLen:40 MF >Frag Offset: 0x1E17 Frag Size: 0x0014 >[**] [1:522:2] MISC Tiny Fragments [**] >[Classification: Potentially Bad Traffic] [Priority: 2] >07/10/02-22:48:25.114488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C >64.105.26.118 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 DgmLen:40 MF >Frag Offset: 0x1ED3 Frag Size: 0x0014 >[**] [1:522:2] MISC Tiny Fragments [**] >[Classification: Potentially Bad Traffic] [Priority: 2] >07/11/02-16:38:45.424488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C >64.105.26.164 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 DgmLen:40 MF >Frag Offset: 0x1ED3 Frag Size: 0x0014 >[**] [1:522:2] MISC Tiny Fragments [**] >[Classification: Potentially Bad Traffic] [Priority: 2] >07/15/02-21:26:14.184488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C >217.83.201.131 -> 46.5.80.149 TCP TTL:242 TOS:0x0 ID:0 IpLen:20 >DgmLen:40 MF Frag Offset: 0x1EB2 Frag Size: 0x0014 > >Using the last alert above as a sample, a Snort alert format contains: >[**] [1:522:2] MISC Tiny Fragments [**] > >--> [**] [Generator ID: Signature ID: Revision Number] Signature Message >[**] > > >[Classification: Potentially Bad Traffic] [Priority: 2] > >--> [Classification: Classification Types Short Name] [Priority: >Priority level] > > >07/15/02-21:26:14.184488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 >len:0x3C > >--> Timestamp Source MAC Address -> Destination MAC Address >--> type: encapsulation protocol (0x800 = IP) >--> len: length of the frame (0x3C = 60) > > >217.83.201.131 -> 46.5.80.149 TCP TTL:242 TOS:0x0 ID:0 IpLen:20 >DgmLen:40 MF Frag Offset: 0x1EB2 Frag Size: 0x0014 > >--> Source IP Address -> Destination IP Address >--> Protocol ID >--> TTL: time to live >--> TOS: type of service >--> ID: IP / Fragment ID >--> DgmLen: total length of datagram >--> IP Flag: IP flags (reserved bit| Dont Fragment | More Fragment) >--> Frag Offset: fragment offset >--> Frag Size: fragment size > >To confirm these Snort generated alerts, the log file is passed through >tcpdump with bpf filters to include packets with: >1. More Fragment flag set (ip[6] & 0x20 != 0) >2. total payload less than 25 bytes (ip[3]-((ip[0] & 0x0f)*4) < 25). > ># tcpdump -Xxvnns 1514 -r 2002.6.all '(ip[6] & 0x20 != 0) and (ip[6] & >0x80 ==0) and (ip[3]-((ip[0] & 0x0f)*4) < 25)' > >Packet 1: ip[6] == 0x6f --> fragbits:DM >17:50:45.374488 64.244.110.164 > 46.5.212.116: tcp (frag 0:20@30904+) >(ttl 237, len 40, bad cksum b1ae!) >0x0000 4500 0028 0000 6f17 ed06 b1ae 40f4 6ea4 E..([email protected]. >0x0010 2e05 d474 8105 0050 0400 ff56 0400 ff56 ...t...P...V...V >0x0020 5004 0000 7ad3 0000 0000 0000 0000 P...z......... > >Packet 2: ip[6] == 0x3e --> fragbits:M >21:26:14.184488 217.83.201.131 > 46.5.80.149: tcp (frag 0:20@62864+) >(ttl 242, len 40, bad cksum 70b1!) >0x0000 4500 0028 0000 3eb2 f206 70b1 d953 c983 E..(..>...p..S.. >0x0010 2e05 5095 8389 18ca 0e11 7516 0e11 7516 ..P.......u...u. >0x0020 5004 0000 f3d1 0000 0000 0000 0000 P............. > >Packet 3: ip[6] == 0x3e --> fragbits:M >20:41:23.524488 80.136.103.85 > 46.5.80.149: tcp (frag 0:20@61624+) (ttl >241, len 40, bad cksum 5d46!) >0x0000 4500 0028 0000 3e17 f106 5d46 5088 6755 E..(..>...]FP.gU >0x0010 2e05 5095 8206 18ca 0935 7f24 0935 7f24 ..P......5.$.5.$ >0x0020 5004 0000 d5ea 0000 0000 0000 0000 P............. > >Packet 4: ip[6] == 0x3e --> fragbits:M >22:48:25.114488 64.105.26.118 > 46.5.80.149: tcp (frag 0:20@63128+) (ttl >237, len 40, bad cksum bd88!) >0x0000 4500 0028 0000 3ed3 ed06 bd88 4069 1a76 E..(..>[email protected] >0x0010 2e05 5095 8039 18ca 9d55 7d9e 9d55 7d9e ..P..9...U}..U}. >0x0020 5004 0000 0f81 0000 0000 0000 0000 P............. > >Packet 5: ip[6] == 0x3e --> fragbits:M >16:38:45.424488 64.105.26.164 > 46.5.80.149: tcp (frag 0:20@63128+) (ttl >237, len 40, bad cksum bd5a!) >0x0000 4500 0028 0000 3ed3 ed06 bd5a 4069 1aa4 E..(..>....Z@i.. >0x0010 2e05 5095 82ff 18ca a129 6dae a129 6dae ..P......)m..)m. >0x0020 5004 0000 24c5 0000 0000 0000 0000 P...$......... > >Packet 6: ip[6] == 0x3f --> fragbits:M >01:06:04.854488 64.26.170.95 > 46.5.80.149: tcp (frag 0:20@65112+) (ttl >237, len 40, bad cksum 2cf6!) >0x0000 4500 0028 0000 3fcb ed06 2cf6 401a aa5f E..(..?...,.@.._ >0x0010 2e05 5095 8047 18ca 4107 12d2 4107 12d2 ..P..G..A...A... >0x0020 5004 0000 0e0e 0000 0000 0000 0000 P............. > >Packet 7: ip[6] == 0x64 --> fragbits:DM >08:00:17.944488 61.205.39.211 > 46.5.80.149: tcp (frag 0:20@9368+) (ttl >236, len 40, bad cksum 8e07!) >0x0000 4500 0028 0000 6493 ec06 8e07 3dcd 27d3 E..(..d.....=.'. >0x0010 2e05 5095 81d1 18ca 1c07 fa00 1c07 fa00 ..P............. >0x0020 5004 0000 0d00 0000 0000 0000 0000 P............. > >The tcpdump command results in two additional packets, i.e. Packet 1 and >7. This is because these two packets also have the Dont Fragment flag >set in addition to the More Fragment flag. The corresponding snort rule >fires when only the More Fragment is set. The bpf filter is then >modified to fit this restriction (ip[6] & 0x60 == 0x20). Below is the >modified tcpdump command and only packet 2 5 are returned this time. ># tcpdump -Xxvnns 1514 -r 2002.6.all '(ip[6] & 0x60 == 0x20) and >(ip[3]-((ip[0] & 0x0f)*4) < 25)' > > >Probability the source address was spoofed: >--------------------------------------------- > >As will be further described in the next two sections, I believe that >the packets in this trace are corrupted RST packets from real Gnutella >traffic. Therefore, the possibility that the source addresses are >spoofed is very small. >The TTL (time to live) values also appear to be consistent with the >source IP classes, i.e. the one sourced from the same Class A (64.x.x.x) >seems to have similar TTL values. Searching these 5 source addresses in >Geektools9 returns three different Internet Service Provider companies, >i.e.: Magma Communication/ Canada, Covad/ US, Deutsche Telekom AG. >Also, performing */nslookup/* on these machines shows that they are alive. >Name: pD953C983.dip.t-dialin.net >Address: 217.83.201.131 >Name: h-64-105-26-164.lsanca54.dynamic.covad.net >Address: 64.105.26.164 >Name: h-64-105-26-118.lsanca54.dynamic.covad.net >Address: 64.105.26.118 >Name: p50886755.dip0.t-ipconnect.de >Address: 80.136.103.85 >Name: ottawa-hs-64-26-170-95.d-ip.magma.ca >Address: 64.26.170.95 > >Thus, these 5 source addresses are mostly likely regular Gnutella servents. >In addition, RST packets are usually sent either in responses to >connection requests to non-existence services, to abort existing >connections, or to OS fingerprint systems in the target network. In this >particular detect, I tend to believe that the corrupted RST packets are >generated to abort existing Gnutella connections, and therefore, the >source addresses are not spoofed. > > >Description of attack: >----------------------- > >Tiny fragments are often to bypass the intrusion detection systems and >firewalls that fail to perform proper fragments reassembly. The common >fragmentation attacks include fragmentation overlap, fragmentation >overwrite, and fragmentation time-outs.10 Although most of the current >intrusion detection systems (e.g. Snorts frag2 preprocessor) and >firewalls are capable of maintaining states and perform fragmentation >reassembly, these devices are still susceptible to denial of service >attacks while not configured properly. In addition, some systems may >crash or severely disrupted when receiving a lot of malformed fragmented >packets.11 >In this particular tiny fragments detect, there are two possible >explanations: >1. These packets are part of a larger tiny fragment attacks described >above. The facts that the frag id and the data length are always 0 and >20 might indicate that these are crafted packets. However, there is not >enough information available to support this conclusion, especially with >only 1 fragment of the entire fragments train is available in the packet >trace. >2. These are corrupted packets and based on further description in the >next section, they are corrupted RST packets sent by a Gnutella servent >to end a connection. I incline towards this second scenario. > > >Attack mechanism: >-------------------- > >There are several interesting similarities among the packets in this >detect: >1. The 4th and 5th bytes offset of IP header IP/fragment ID = 0 >2. The More Fragment flag found in the 3 high-order bits of the 6th >bytes offset of IP header is always set. The 6th bytes offset of IP >headers (ip[6]) of this detect are either 0x3e or 0x3f. Using the IP >header template: >Hex => Decimal => IP Flags | Fragment Offset (portion) >xDM >0x3e => 62 => 001 | 11110 >0x3f => 63 => 001 | 11111 > >IP Flags: >x reserved, set to 0; D Dont Fragment; M More Fragment >3. The 9th byte offset of the IP header Protocol = 0x06 (i.e. TCP) >4. The 2nd and 3rd bytes offset of the payload (since the MF flag is set >in the IP header) = 0x18ca or decimal 6346 >5. The values of the 4th to 7th bytes offset of the payload is always >the same as those of the 8th to 11th bytes offset >6. The 12th and 13th bytes offset of the payload = 0x5004 >If I ignore the fact that these packets are fragments and consider the >payload as TCP header instead of fragment payload, point 4 6 above can >be translated into: >4. Destination port = 6346 (Gnutella) >5. Sequence number = ACK number >6. TCP header length = 20 bytes; TCP RST flag is set >Hex => Offset | Reserved | Flags >| | UAPRSF >0x5004 => 0101 | 0000 00 | 000100 > >TCP Flags: >U Urgent; A Ack; P Push; R Reset; S Syn; F - Fin > >To support my suspicion that these packets are corrupted Gnutella RST >packets, I use tcpdump to filter all traffic sourced from / destined to >46.5.80.149 in the raw log file. (Notice that all of these alerts >destined to the same ip address, i.e. 46.5.80.149) ># tcpdump -nnr 2002.6.all 'dst host 46.5.80.149' | wc >399 3536 35076 ># tcpdump -nnr 2002.6.all 'src host 46.5.80.149' | wc >0 0 0 > >While none of the logged traffics sourced from 46.5.80.149, there are >399 packets destined to it. Among these 399 packets: 12 >* 380 destined to TCP port 6346 - registered to Gnutella. >* 18 fragmented packets without destination ports >* 1 destined to TCP 3514 registered to MUST Peer to Peer > ># tcpdump -nnr 2002.6.all 'dst host 46.5.80.149' | awk '{print $4}' >| awk -F \. {'print $5'} | sort | uniq -c |more >18 >1 3514: >380 6346: > >In addition, it appears that there are no packets sourced from the five >different source IP addresses in this detect other than the ones >triggering these Misc Tiny Fragment alerts. > ># tcpdump -nnr 2002.6.all 'host 64.26.170.95 or host 64.105.26.118 >or host 64.105.26.164 or 217.83.201.131 or 80.136.103.85' |wc >5 35 340 >At this point, I can conclude that 46.5.80.149 is a Gnutella servent. >Below is a sample of the packets: >18:21:45.164488 148.63.247.123.3536 > 46.5.80.149.6346: P >2391248906:2391249078(172) win 8192 (DF) >0x0000 4500 00d4 9dcf 4000 6e06 6c04 943f f77b [email protected]..?.{ >0x0010 2e05 5095 0dd0 18ca 8e87 900a 0000 0000 ..P............. >0x0020 5e08 2000 48d3 0000 474e 5554 454c 4c41 ^...H...GNUTELLA >0x0030 2043 4f4e 4e45 4354 2f30 2e36 0d0a 5573 .CONNECT/0.6..Us >0x0040 6572 2d41 6765 6e74 3a20 4265 6172 5368 er-Agent:.BearSh >0x0050 6172 6520 322e 362e 330d 0a4d 6163 6869 are.2.6.3..Machi >0x0060 6e65 3a20 312c 3133 2c31 3930 2c31 2c34 ne:.1,13,190,1,4 >0x0070 3938 0d0a 506f 6e67 2d43 6163 6869 6e67 98..Pong-Caching >0x0080 3a20 302e 310d 0a48 6f70 732d 466c 6f77 :.0.1..Hops-Flow >0x0090 3a20 312e 300d 0a4c 6973 7465 6e2d 4950 :.1.0..Listen-IP >0x00a0 3a20 3134 382e 3633 2e32 3437 2e31 3233 :.148.63.247.123 >0x00b0 3a36 3334 360d 0a52 656d 6f74 652d 4950 :6346..Remote-IP >0x00c0 3a20 3137 302e 3132 392e 3230 342e 3139 :.170.129.204.19 >0x00d0 0d0a 0d0a .... > >Gnutella is a peer-to-peer protocol for distributed search and digital >distribution / file sharing. Each participant is called a servent and >acts as both a client and a server.13 A description on the protocol can >be found on the link below: >http://rfc-gnutella.sourceforge.net/developer/index.html > >From my online research, I was not able to obtain much information >regarding TCP RST packets to end Gnutella connections. I then decide to >capture some live Gnutella (port 6346) traffic on our campus network to >learn more on its behavior. From the captured traffic, I try to find RST >packets with the same sequence (tcp[4:4]) and ACK numbers (tcp[8:4]). >### capture live Gnutella (port 6346) traffic ># tcpdump -i bond0 -xnns 1514 port 6346 > >### filter RST packets with sequence # = ACK # ># tcpdump -r gnu -xnns 1514 tcp[13] = 0x04 and tcp[4:4] = tcp[8:4] and >dst port 6346' >I do find quite a lot of these packets. Below are some samples >(checksums and source IPs are removed): >16:40:22.417450 x.x.x.x.4834 > 68.162.158.172.6346: R 4231098138:42 >31098138(0) win 0 >4500 0028 a541 0000 7f06 xxxx xxxx xxxx >44a2 9eac 12e2 18ca fc31 6f1a fc31 6f1a >5004 0000 f492 0000 0000 0000 0000 >16:40:22.459180 x.x.x.x.4839 > 69.177.14.249.6346: R 4232152131:423 >2152131(0) win 0 >4500 0028 a545 0000 7f06 xxxx xxxx xxxx >45b1 0ef9 12e7 18ca fc41 8443 fc41 8443 >5004 0000 58c0 0000 0000 0000 0000 >16:40:22.622202 x.x.x.x.4837 > 24.51.185.190.6346: R 4231561837:423 >1561837(0) win 0 >4500 0028 a551 0000 7f06 xxxx xxxx xxxx >1833 b9be 12e5 18ca fc38 826d fc38 826d >5004 0000 df38 0000 0000 0000 0000 > >Although RST packets are usually sent either as responses to connection >requests to closed ports or as ways to abort existing connections based >the RFC 79314, I notice that Gnutella servents often send both FIN >(normal way to terminate connections) and RST packets when closing a >connection unless the remote servents respond immediately with FIN ACK >packets. This duplication is particularly true when a busy message >(There are too many active upload, and no space in the queues) is >received from a remote servent. It seems that this is intended by design >to avoid a lot of TCP half-close connections and to tear down the >connections right away. >Since not all of these live captured RST packets have the same sequence >and ACK numbers, I perform OS fingerprinting (using nmap) on two of >these machines and they are identified as Windows systems as showed below. >Remote operating system guess: Windows Millennium Edition (Me), Win >2000, or Win XP >Remote OS guesses: Windows NT 5 Beta2 or Beta3, Windows Millennium >Edition (Me), Win 2000, or WinXP, MS Windows2000 Professional RC1/W2K >Advance Server Beta3 > >In addition, p0fs RST+ signatures15 describes that while the ACK value >should be zeroed, it is not strictly against the RFC, and some systems >either leak memory there or set it to the value of SEQ. The latter >variant, with non-zero ACK, is particularly common on Windows. > >Thus, if the packets are really corrupted RST Gnutella packets, I can be >pretty confident that the source IPs are Windows machines. > >The next question is how do these RST packets turn into fragments? >Comparing a sample of the real RST packets and the ones in this detect, >there is an obvious different is on the 4th 7th bytes offset of the IP >header. It seems that the values of the first two bytes (4th and 5th >0x0000) are somehow swapped with those of the last two (6th and 7th >0x3fcb) in this detect. Since the 4th & 5th bytes offset of IP header >are the IP/Fragment ID and the 6th & 7th bytes offset are IP Flags and >Fragment Offset, swapping them around can definitely turn a non-fragment >packet into a fragment. > >Real Gnutella RST packet >4500 0028 a551 0000 7f06 xxxx xxxx xxxx >1833 b9be 12e5 18ca fc38 826d fc38 826d >5004 0000 df38 0000 0000 0000 0000 > >Last packet in this detect (Packet 6) >4500 0028 0000 3fcb ed06 2cf6 401a aa5f >2e05 5095 8047 18ca 4107 12d2 4107 12d2 >5004 0000 0e0e 0000 0000 0000 0000 > >To support this swapping theory, I notice that my earlier tcpdump filter >on tiny fragment packets (less than 25 bytes payload and MF flag set) >returned two additional packets that have both MF (More Fragment) and DF >(Dont Fragment) flags set. These two flags identify 2 opposing traits >of a packet and should not exist together in a packet when the RFC is >followed. Thus, I am pretty sure that these two packets are also >corrupted by the same technique. > > >Correlations: >---------------- >There are several postings regarding MISC Tiny Fragments detect on the >intrusions list: >* Richard Haynal analyzed a different traffic trace in >www.incidents.org/logs/Raw/2002.9.22 and also concluded that the packets >in his detect are corrupted. The original posting is available at: >http://www.dshield.org/pipermail/intrusions/2003-April/007375.php >* Lesa Ludwig analyzed another traffic trace in >http://www.incidents.org/logs/Raw/2002.10.11. Several categories of >fragmentation attacks are presented as part of the analysis. The >original posting is available at: >http://www.dshield.org/pipermail/intrusions/2003-January/006463.php >Considering that the tiny fragments in this detect are corrupted >packets, there are no related CVE entries. >Although I am reluctant to believe that this detect is part of a tiny >fragmentation attack, below are several articles on the fragmentation >attacks: >* IDS Evasion Techniques and Tactics, by Kevin Timm, May 7, 2002, >http://www.securityfocus.com/infocus/1577 >* Protection Against a Variant of the Tiny Fragment Attack, June 2001, >http://rfc.net/rfc3128.html >* An Analysis of Fragmentation Attacks, by Jason Anderson, March 15, >2001, http://www.inet-sec.org/docs/DoS/fragma.html >* Cisco PIX and CBAC Fragmentation Attack, September 11, 1998, >http://www.cisco.com/warp/public/770/nifrag.shtml >* Security Considerations for IP Fragment Filtering, October 1995, >http://rfc.net/rfc1858.html >Only one of the five source IP addresses in this detect has an entry in >myNetWatchman incident database16, i.e. 217.83.201.131 (Incident ID: >112675479). However, this particular event is relatively new and related >to Microsoft SMB/CIFS/Sasser/Agobot/Generic Bot, which is not relevant >to this detect. No incident entry is found on dshield.org for these five >source IPs. > > >Evidence of active targeting: >----------------------------- >Should this detect be classified as a real attack, I can be relatively >positive that there is an active targeting because all alerts in this >detect are directed to the destination IP. However, this detect is not a >real attack, but some corrupted packets. Thus, there is no evidence of >active targeting in this particular detect. > > >Severity: -1 >--------------- >severity = (criticality + lethality) - (system countermeasures + network >countermeasures) >= (2+1) (2+2) = 3 4 = -1 > >Criticality: 2 >Although there is no information regarding the criticality of this >target system, the fact that traffic destined to it is mostly >peer-to-peer related (as discussed earlier) lead me to conclude that >its an end-user workstation. Also, since this particular network fits >the profile of an .edu network, an end-user workstation with Gnutella >client program can be anyones computer (student/faculty/staff). >Although the criticality level may vary depending on the owner of the >systems, I assign the criticality value of 2 here. > >Lethality: 1 >There is no real attack in this particular detect. I believe that these >tiny fragments are corrupted Gnutella RST packets. Thus, the level of >damage caused is very low. >System countermeasures: 2 >There is no information regarding the system-level defenses on the >target machine and I can only assume based on the fact that it is >running a Gnutella client program. Since the security awareness level of >average end users in an .edu environment is usually relatively low, I >assign the system countermeasures a value of 2. > >Network countermeasures: 2 >Based on the information in the first section of this detect, I conclude >that the existing network countermeasures seem to include loose egress & >ingress filterings and an intrusion detection system. Although it seems >that there are blocks for well-known Windows ports as part of the egress >filtering, the same blocks do not appear to be applied in the ingress >filtering. I therefore assign the network countermeasures a value of 2. > > >Defensive recommendation: >-------------------------- >Although this detect does not include real fragmentation attacks, >networklevel defenses can still be put in place to prevent them and to >further improve the current state of network security: >* Implement stateful firewall that is capable of maintaining >inter-fragment state and dropping illegal and tiny fragments. If the >size of the initial fragment is not large enough to fit all necessary >header information, it should be dropped.17 Any non-initial fragments >should also be discarded unless the corresponding initial fragment has >passed the firewall.18 The amount of memory assigned to maintain the >fragmentation state should also be limited to reduce the possibility of >denial of service attacks against the firewall itself. >* Most of todays IDSs are capable of performing fragmentation >reassembly, including Snort. Assuming Snort is used in this network, the >frag2 preprocessor need to be enabled. >* Applying more rigid ingress filtering by gradually moving from permit >all, deny specifics to permit specifics, deny all. This might not be >a easy option especially if this is an actual .edu network. >As for the host-level defenses: >* Fragmentation attacks may also cause certain un-patched systems to >crash. Thus, it is required to keep each host up-to-date on its security >patches. >* Assuming that the traffic categorization from the log file is a decent >representation of the actual traffic on the network, peer-to-peer >traffic is one of the most popular traffic coming into and leaving the >network. As peer-to-peer programs usually come with spyware/ adware, the >dangerous of these add-on programs should be brought up to end users >attention. This is especially > > >Multiple choice test question: >------------------------------- > >tcp[13] = 0x04 and tcp[4:4] = tcp[8:4] and dst port 6346' >What kind of traffic does the above bpf filter look for? > >A) TCP traffic with SYN and ACK flags set, the same source and >destination ports, destination port = 6346 >B) TCP traffic with RST flag set, the same source and destination ports, >destination port = 6346 >C) TCP traffic with SYN and ACK flags set, the same SEQ and ACK numbers, >destination port = 6346 >D) TCP traffic with RST flag set, the same SEQ and ACK numbers, >destination port = 6346 > >Answer: D > > >1 http://isc.sans.org/logs/Raw/README >2 http://tcpreplay.sourceforge.net/pcapmerge.html >3 http://www.sourceforge.net/projects/tcpreplay/ >4 http://tcpdump.org/tcpdump_man.html >5 http://standards.ieee.org/regauth/oui/oui.txt >6 http://www.neohapsis.com/neolabs/neo-ports/neo-ports.html >7 http://www.snort.org/dl/contrib/data_analysis/snortsnarf/ >8 http://www.snort.org/snort-db/?sid=522 >9 http://www.geektools.com/whois.php >10 http://www.securityfocus.com/infocus/1577 >11http://www.securiteam.com/windowsntfocus/Patch_Available_for_the__IP_Fragment_Reassembly__Vulnerability.html > >12 http://www.iana.org/assignments/port-numbers >13 >http://rfc-gnutella.sourceforge.net/developer/share/intro.html#Background >14 http://www.faqs.org/rfcs/rfc793.html >15 http://www.stearns.org/p0f/p0fr.fp >16 http://www.mynetwatchman.com/ListIncidentsbyIP.asp >17 http://www.inet-sec.org/docs/DoS/fragma.html >18 http://www.cisco.com/warp/public/770/nifrag.shtml > > > > >------------------------------ > >_______________________________________________ >Intrusions mailing list >[email protected] >http://www.dshield.org/mailman/listinfo/intrusions > > >End of Intrusions Digest, Vol 6, Issue 1 >**************************************** _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Intrusions mailing list [email protected] http://www.dshield.org/mailman/listinfo/intrusions