[Intrusions] RE: DNS ID , SPAM , CITI BANK
lee forrest
leeforrest10000 at hotmail.com
Wed Sep 1 21:16:08 GMT 2004
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: intrusions-request at lists.sans.org
>Reply-To: intrusions at lists.sans.org
>To: intrusions at lists.sans.org
>Subject: Intrusions Digest, Vol 6, Issue 1
>Date: Wed, 1 Sep 2004 11:51:26 GMT
>
>Send Intrusions mailing list submissions to
> intrusions at lists.sans.org
>
>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
> intrusions-request at lists.sans.org
>
>You can reach the person managing the list at
> intrusions-owner at lists.sans.org
>
>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 <dana at dunrobin.dyn.dhs.org>
>Subject: Re: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect
> Roch Decoste
>To: "Intrusions List \(GCIA Practicals\)" <intrusions at lists.sans.org>
>Message-ID: <200408311326.i7VDQIkS003840 at dunrobin.dyn.dhs.org>
>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
>dana at dunrobin.dyn.dhs.org
>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 <chris.meidinger at badenit.de>
>Subject: RE: [Intrusions] RE: All in One Spam filter Antivirus ,
> Bayesian , DNS ,etc, Dot Net.
>To: "Intrusions List (GCIA Practicals)" <intrusions at lists.sans.org>
>Message-ID: <23ADBF4236843B469BE57F05F1358976038E415D at srvntexc2.swfr>
>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" <Myron_Davis at dec.state.ak.us>
>Subject: RE: [Intrusions] New Trojan on the block [CIA Trojan]
>To: "'Intrusions List (GCIA Practicals)'" <intrusions at lists.sans.org>
>Message-ID:
> <D0CD1BF9C88ED511B6E100508BBB43BD049149BE at 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:nick at virus-l.demon.co.uk]
>Sent: Sunday, August 29, 2004 3:08 PM
>To: intrusions at lists.sans.org
>Subject: Re: [Intrusions] New Trojan on the block [CIA Trojan]
>
><snip>
>
> Authentium (Command Antivirus) <virus at authentium.com>
> Computer Associates (US) <virus at ca.com>
> Computer Associates (Vet/EZ) <support at vet.com.au>
> DialogueScience (Dr. Web) <Antivir at dials.ru>
> Eset (NOD32) <sample at nod32.com>
> F-Secure Corp. <samples at f-secure.com>
> Frisk Software (F-PROT) <viruslab at f-prot.com>
> Grisoft (AVG) <virus at grisoft.cz>
> H+BEDV (AntiVir, Vexira engine) <virus at antivir.de>
> Kaspersky Labs <newvirus at kaspersky.com>
> Network Associates (McAfee) <virus_research at nai.com>
> (use a ZIP file with the password 'infected' without the quotes)
> Norman (NVC) <analysis at norman.no>
> Panda Software <labs at pandasoftware.com>
> Sophos Plc. <support at sophos.com>
> Symantec (Norton) <avsubmit at symantec.com>
> Trend Micro (PC-cillin) <virus_doctor at trendmicro.com>
> (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
>Intrusions at lists.sans.org
>http://www.dshield.org/mailman/listinfo/intrusions
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 31 Aug 2004 18:36:40 -0700
>From: Rusma Mulyadi <rmulyadi at arizona.edu>
>Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect
> Rusma Mulyadi
>To: intrusions at incidents.org
>Message-ID: <413527A8.4030609 at arizona.edu>
>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 Type’s 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| Don’t 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 at 30904+)
>(ttl 237, len 40, bad cksum b1ae!)
>0x0000 4500 0028 0000 6f17 ed06 b1ae 40f4 6ea4 E..(..o..... at .n.
>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 at 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 at 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 at 63128+) (ttl
>237, len 40, bad cksum bd88!)
>0x0000 4500 0028 0000 3ed3 ed06 bd88 4069 1a76 E..(..>..... at i.v
>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 at 63128+) (ttl
>237, len 40, bad cksum bd5a!)
>0x0000 4500 0028 0000 3ed3 ed06 bd5a 4069 1aa4 E..(..>....Z at 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 at 65112+) (ttl
>237, len 40, bad cksum 2cf6!)
>0x0000 4500 0028 0000 3fcb ed06 2cf6 401a aa5f E..(..?...,. at .._
>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 at 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 Don’t 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. Snort’s 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 – Don’t 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 E..... at .n.l..?.{
>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, p0f’s 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
>(Don’t 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
>it’s 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 anyone’s 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,
>network–level 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 today’s 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
>Intrusions at lists.sans.org
>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
More information about the Intrusions
mailing list