RE: Ken Connelly 08002b00dcdc=Digital Equipment Corp

For Ken

Why don't you send an email to [email protected]
who is a member of

http://www.systek.no/

goto

http://www.netsys.com/openldap-software/2000/08/msg00154.html

you will see [email protected] email listed at the top

That Mac translates to Digital Equipment Corp , was compaw then HP
so the monitor software seems to be feeding info from your systems.

http://research.microsoft.com/~gbell/Digital/DECMuseum.htm
http://www.fact-index.com/d/di/digital_equipment_corporation.html

ping from 127.0.0.1 is used to check the network card is working.
Seems like a clever little util you got there.

>From: [email protected]
>Reply-To: [email protected]
>To: [email protected]
>Subject: Intrusions Digest, Vol 5, Issue 55
>Date: Mon, 30 Aug 2004 14:04:40 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: established connection and ids signatures (lola marais)
>    2. RE: Strange echo requests from 127.0.0.1 apparently	toroot
>       nameservers (Terje Trane)
>    3. RE: Strange echo requests from 127.0.0.1	apparentlyto	root
>       nameservers (Terje Trane)
>    4. RE: Strange echo requests from 127.0.0.1 apparently	toroot
>       nameservers (Terje Trane)
>    5. RE: Strange echo requests from 127.0.0.1 apparently	toroot
>       nameservers (Terje Trane)
>    6. RE: Sasser Worm Varient , Steve Carey (lee forrest)
>    7. LOGS: GIAC GCIA Version 3.4 Practical Detect Roch	Decoste
>       (Roch Something)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 30 Aug 2004 14:10:39 +0200
>From: "lola marais" <[email protected]>
>Subject: Re: [Intrusions] established connection and ids signatures
>To: [email protected]
>Message-ID: <[email protected]>
>Content-Type: text/plain; format=flowed
>
>
> >This used to be accomplished with the -z switch. You might want to take
> >a look at deactivating the stream4 preprocessor in snort.conf, too.
>
>thanks andrew,
>
>i disabled the following parameters and it worked. the snort process no
>longer looks at the state of the session when the binary files are
>re-passed.
>
># preprocessor stream4: disable_evasion_alerts
># preprocessor stream4_reassemble
>
>_________________________________________________________________
>Access your MSN favourites from anywhere - download MSN Toolbar today!
>http://toolbar.msn.co.za?DI=1054&XAPID=2083
>
>
>
>------------------------------
>
>Message: 2
>Date: Mon, 30 Aug 2004 09:45:30 +0200
>From: "Terje Trane" <[email protected]>
>Subject: RE: [Intrusions] Strange echo requests from 127.0.0.1
>	apparently	toroot nameservers
>To: "'Intrusions List \(GCIA Practicals\)'"
>	<[email protected]>
>Message-ID: <[email protected]>
>
>Ken Connelly wrote:
> > It's much more important to know what you don't know than
> > what you do know!
>
>Quite possible. And even more that I really know what I think I know (so I
>draw the correct conclusions). Please do a reality check on this:
>
>I see ICMP traffic, several packets per second, using Ethereal on a PC.
>-> something is going on in the PC or on the subnet. It is not a normal 
>ping
>'cos it is of much higher frequency. Are there eny natural causes for this
>or is it a DoS maybe?
>
>The IP destinations are a mix of internal DNS servers, root and toplevel 
>DNS
>server and occationally an other (like yahoo).
>-> A DoS on the DNS system?
>
>The IP source is stated as 127.0.0.1.
>-> Seems to be originating in the PC
>
>The MAC-address of the source is not the same as the NIC in the PC.
>-> Is it not from the PC but from the subnet?
>
>Running tcpdump on another machine connected on the same hub shows nothing
>-> It is not leaving the PC (I must check that the nic the tcpdump was run
>on was in promiscous mode.)
>
>The MAC-address of the destination is not known on any PC, server or
>switch/router in our network. It has a vendor code that is from DEC, and 
>the
>ISP's equipment is Cisco.
>-> It is spoofed? Does 08:00:2b:00:dc:dc and 08:00:2b:00:01:02 have any
>particular meaning?
>
>Is it just a bug in some of the monitoring software that is 
>installed/tested
>(some uninstalled)  on the machine? (HP-printer utilities, TopTools, 
>various
>scanners)
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Mon, 30 Aug 2004 09:47:29 +0200
>From: "Terje Trane" <[email protected]>
>Subject: RE: [Intrusions] Strange echo requests from 127.0.0.1
>	apparentlyto	root nameservers
>To: "'Intrusions List \(GCIA Practicals\)'"
>	<[email protected]>
>Message-ID: <[email protected]>
>
> > Roland wrote:
> > There is a shareware utility developed by Foundstone, Inc.
> > http://www.foundstone.com called fport.exe which is able link
> > the port
> > and pid in one command line program.
>
>Thanks, but I already have this. It shows open ans listening TCP and UDP
>ports, but not ICMP.
>
> > In addition there is another utility called handle developed by
> > Sysinternals @
> > http://www.sysinternals.com/ntw2k/freeware/handle.shtml.
> > This utility links process IDs to ports and program names,
>
>Thanks, I downloaded this and immediatly made it a part of my toolbox. I'm
>not shure how this will help. I'am not near the machine we are researching
>now, but I tested on my laptop. I started a ping and ran handle. Searching
>for ping.exe in the result I find:
>
>ping.exe pid: 2304 SYSTEK-NETBIOS\trane
>     c: File          C:\Documents and Settings\trane
>   778: File
>C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0
>.2600.2180_x-ww_a84f1ff9
>
>Nothing here tells me that this process was sending ICMP packets anywhere.
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 30 Aug 2004 09:49:32 +0200
>From: "Terje Trane" <[email protected]>
>Subject: RE: [Intrusions] Strange echo requests from 127.0.0.1
>	apparently	toroot nameservers
>To: "'Intrusions List \(GCIA Practicals\)'"
>	<[email protected]>
>Message-ID: <[email protected]>
>
>Ken Connelly wrote:
> > It's much more important to know what you don't know than
> > what you do know!
>
>Quite possible. And even more that I really know what I think I know (so I
>draw the correct conclusions). Please do a reality check on this:
>
>I see ICMP traffic, several packets per second, using Ethereal on a PC.
>-> something is going on in the PC or on the subnet. It is not a normal 
>ping
>'cos it is of much higher frequency. Are there eny natural causes for this
>or is it a DoS maybe?
>
>The IP destinations are a mix of internal DNS servers, root and toplevel 
>DNS
>server and occationally an other (like yahoo).
>-> A DoS on the DNS system?
>
>The IP source is stated as 127.0.0.1.
>-> Seems to be originating in the PC
>
>The MAC-address of the source is not the same as the NIC in the PC.
>-> Is it not from the PC but from the subnet?
>
>Running tcpdump on another machine connected on the same hub shows nothing
>-> It is not leaving the PC (I must check that the nic the tcpdump was run
>on was in promiscous mode.)
>
>The MAC-address of the destination is not known on any PC, server or
>switch/router in our network. It has a vendor code that is from DEC, and 
>the
>ISP's equipment is Cisco.
>-> It is spoofed? Does 08:00:2b:00:dc:dc and 08:00:2b:00:01:02 have any
>particular meaning?
>
>Is it just a bug in some of the monitoring software that is 
>installed/tested
>(some uninstalled)  on the machine? (HP-printer utilities, TopTools, 
>various
>scanners)
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Mon, 30 Aug 2004 09:53:02 +0200
>From: "Terje Trane" <[email protected]>
>Subject: RE: [Intrusions] Strange echo requests from 127.0.0.1
>	apparently	toroot nameservers
>To: "'Intrusions List \(GCIA Practicals\)'"
>	<[email protected]>
>Message-ID: <[email protected]>
>
>Ken Connelly wrote:
> > 08:00:2b belongs to DEC, if that helps you pinpoint the
> > traffic.   -ken
>
>Yes I know. Interresting since we have no DEC equipment in our offices,
>(this is a small office with only a dozen nodes so I am pretty shure I have
>control)
>
>
>
>
>------------------------------
>
>Message: 6
>Date: Mon, 30 Aug 2004 14:16:52 +0100
>From: "lee forrest" <[email protected]>
>Subject: [Intrusions] RE: Sasser Worm Varient , Steve Carey
>To: [email protected]
>Message-ID: <[email protected]>
>Content-Type: text/plain; format=flowed
>
>I would Much Appreciate that packet overflow list you have on port 4445 ,
>UPnotify is Alias Uplanet
>Mark Fox , email@uplanet service , linked to Mobile Phone hacking  I could
>be way off here but it sure sounds like Java code on mobile phones used to
>hack computers.
>
>
>( I could be wrong ) , need more data
>
>_________________________________________________________________
>It's fast, it's easy and it's free. Get MSN Messenger today!
>http://www.msn.co.uk/messenger
>
>
>
>------------------------------
>
>Message: 7
>Date: Mon, 30 Aug 2004 09:44:10 -0400 (EDT)
>From: Roch Something <[email protected]>
>Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect
>	Roch	Decoste
>To: [email protected]
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=us-ascii
>
>Hey,
>
>This is my posted detect required for GCIA certification, feel free to 
>review and comment.
>
>Thanks,
>Roch
>
>*****************************************************************************************************
>
>
>                 DETECT #1:  DNS Named Version Attempt
>                 _____________________________________
>                 -------------------------------------
>
>
>1) Source of Trace
>------------------
>The binary log file used for this trace was 2005.05.16 which originated 
>from the INCIDENTS.ORG website at http://isc.sans.org/logs/raw/2002.05.16.  
>As indicated by the readme file located in the same directory as the 
>capture file 'this log file is the result of a Snort instance running in 
>binary logging mode, all content has been sanitized'. Because of this 
>sanitization, the only network infrastructure details available from this 
>raw dump are the MAC addresses & manufactures of the devices located on 
>either side of the IDS node.
>
>The MAC addresses can be obtained by extracting the link level header 
>information of each packet (using tcpdump -e).  A quick online search will 
>indicate to which manufacture the MAC address was assigned to.  The 
>following commands will extract from the tcpdump output all unique source 
>MAC and unique destination MAC addresses recorded by the IDS node:
>
>tcpdump -ner 2002.5.16 | awk  '{print $2}' | sort -u
>tcpdump -ner 2002.5.16 | awk  '{print $3}' | sort -u
>
>The results of both queries generated MAC addresses 00:00:0C:04:B2:33 and 
>00:03:E3:D9:26:C0.  This indicates that the IDS sensor can only see traffic 
>being passed between two machines (possibly a firewall & a gateway). The 
>following manufacture's MAC address assignments were found at 
>http://standards.ieee.org/regauth/oui/index.shtml.
>
>00:00:0C:04:B2:33   CISCO SYSTEMS, INC.
>                     170 WEST TASMAN DRIVE
>                     SAN JOSE CA 95134-1706
>
>00:03:E3:D9:26:C0   Cisco Systems, Inc.
>                     170 West Tasman Dr.
>                     San Jose CA 95134
>                     United States
>
>
>
>
>2) Detect Generation Method
>---------------------------
>The SNORT alerts were generated by Snort Ver. 2.1.2(build 25) using a 
>default configuration with ruleset Ver. 2.1.0.  This detect will 
>concentrate on the 'DNS Named Version Attempt' alerts generated by SNORT 
>for this binary log file.
>
>
>a) Snort alert logs for to the 'DNS Named Version Attempt'
>----------------------------------------------------------
>
>[**] [1:1616:4] DNS named version attempt [**]
>[Classification: Attempted Information Leak] [Priority: 2]
>06/16-07:46:17.214488 203.197.102.29:3566 -> 46.5.237.85:53
>UDP TTL:44 TOS:0x0 ID:6052 IpLen:20 DgmLen:58
>Len: 30
>[Xref => http://www.whitehats.com/info/IDS278][Xref => 
>http://cgi.nessus.org/plugins/dump.php3?id=10028]
>
>[**] [1:1616:4] DNS named version attempt [**]
>[Classification: Attempted Information Leak] [Priority: 2]
>06/16-07:50:08.514488 203.197.102.29:3682 -> 46.5.187.139:53
>UDP TTL:44 TOS:0x0 ID:9964 IpLen:20 DgmLen:58
>Len: 30
>[Xref => http://www.whitehats.com/info/IDS278][Xref => 
>http://cgi.nessus.org/plugins/dump.php3?id=10028]
>
>The above alerts indicate requests from IP 203.197.102.29 were sent to two 
>IPs within the 46.5.0.0 network in an attempt to determine their Bind DNS 
>version.  These requests were both made June 16th [year not indicated], at 
>07:46:17.214488 hrs and 07:50:08.514488 respectively.  Snort classified 
>these requests as an 'attempted information leak' priority two alert.
>
>
>b) Snort rule responsible for this alert
>----------------------------------------
>
>alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS named version 
>attempt"; content:"|07|version"; nocase; offset:12; content:"|04|bind"; 
>nocase; offset: 12; reference:nessus,10028; reference:arachnids,278; 
>classtype:attempted-recon; sid:1616; rev:4;)
>
>The following is a break down and explanation of the above noted rule:
>
>alert          - Alert & log the information.
>udp            - Only trigger on UDP traffic.
>$External_Net  - Originating from any external address (defined
>                  by $External_net variable).
>any            - Originating from any port.
>->             - Traffic direction.
>$Home_Net      - Destined to any internal address (defined by
>                  $Home_Net variable).
>53             - Destined to port (DNS).
>
>msg:"DNS named ver..."   - Title of the alert.
>content:"|07|version"... - Only trigger if words 'version' &
>                            'bind'(case insensitive) are found
>                            starting from byte 12 in the payload.
>reference:nessus,10028... - External attack reference Ids.
>classtype:attempted-recon - Snort's alert classification.
>sid:1616                  - Snort's signature ID.
>rev:4                     - Rule revision number.
>
>
>c) TCPDUMP syntax used to extract responsible packets
>-----------------------------------------------------
>
>tcpdump -nXvr 2002.5.16 'src host 203.197.102.29 and dst port 53'
>
>The following is an explanation of the flags used to read & interpret the 
>binary log file:
>n  - Don't convert addresses (host addresses, port numbers,
>      etc) to names.
>X  - Print results in hex and ascii format.
>v  - Be more verbose in output.  Include TTL, identification,
>      total length, options & do header checksum verification.
>r  - Read packets from specified file.
>
>
>The following is an explanation of the filter syntax used to isolate the 
>desired packets:
>
>SRC HOST 203.197.102.29
>Indicates that only packets with a source IP address 203.197.102.29 are to 
>be dumped.
>
>AND DST PORT 53
>In addition to the above filter, only dump packets with a destination port 
>of 53 (DNS).
>
>
>d) Corresponding TCPdump data
>-----------------------------
>
>07:46:17.214488 203.197.102.29.3566 > 46.5.237.85.53: [bad udp cksum f7fa!] 
>  4660 [b2&3=0x80] TXT CHAOS? version.bind. (30)
>(ttl  44, id 6052, length: 58, bad cksum 2eda!)
>0x0000:  4500 003a 17a4 0000 2c11 2eda cbc5 661d   E..:....,.....f.
>0x0010:  2e05 ed55 0dee 0035 0026 74f0 1234 0080    ...U...5.&t..4..
>0x0020:  0001 0000 0000 0000 0776 6572 7369 6f6e    .........version
>0x0030:  0462 696e 6400 0010 0003                           .bind.....
>
>07:50:08.514488 203.197.102.29.3682 > 46.5.187.139.53: [bad udp cksum 
>f9f9!]  4660 [b2&3=0x80] TXT CHAOS? version.bind. (30)
>(ttl  44, id 9964, length: 58, bad cksum 525a!)
>0x0000:  4500 003a 26ec 0000 2c11 525a cbc5 661d   E..:&...,.RZ..f.
>0x0010:  2e05 bb8b 0e62 0035 0026 a744 1234 0080   .....b.5.&.D.4..
>0x0020:  0001 0000 0000 0000 0776 6572 7369 6f6e    .........version
>0x0030:  0462 696e 6400 0010 0003                           .bind.....
>
>
>
>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.
>
>
>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
>
>
>
>5) Attack mechanism
>--------------------
>A single UDP packet was sent to port 53 of the target machines.  If a 
>response was generated by the target machines the attacker would have 
>learnt two valuable pieces of information:
>
>a) Whether or not the target is running a DNS server.
>b) If the target is running a BIND DNS server, the attacker will receive a 
>reply containing its version and type information (if this option was not 
>explicitly disabled by the target machine's administrator).
>
>A background check on the attacker's IP address, 203.197.102.29, revealed 
>that he/she was utilizing dial-up access provided by VSNL Technologies, a 
>company based out of  Maharashtra, India.  Depending on the payment methods 
>and locations from where the Internet connection was established it may be 
>next to impossible to locate & identify an attacker utilizing this method 
>of internet access.
>
>
>6) Correlations
>---------------
>http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
>http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
>http://cert.uni-stuttgart.de/archive/intrusions/2003/02/msg00191.html
>
>
>
>7) Evidence of active targeting
>-------------------------------
>Addresses 46.5.237.85 and 46.5.187.139 were actively targeted.  The 
>attacker's IP address (203.197.102.29) was only reported twice in the Snort 
>binary dump that day, and both entries were for 'DNS Named Version' 
>attempts. The attacker was not scanning a range of IPs for DNS servers, but 
>rather actively targeting two IPs for additional information. This kind of 
>behaviour would indicate that:
>
>a) The attacker may have in his/her possession a tool/utility to compromise 
>certain BIND DNS servers.
>
>b) The attacker is already aware of this network's basic layout, and knows 
>that IP addresses 46.5.237.85 and 46.5.187.139 are DNS servers.
>
>c) The attacker is verifying what version & type of DNS server is running 
>on these machines in hopes that they are  vulnerable versions of BIND.
>
>
>
>8) Severity
>-----------
>
>SEVERITY  =  (Criticality + Lethality)  -  (System Countermeasures + 
>Network Countermeasures)
>
>*** Criticality = 5 ***
>DNS servers are often at the heart of large networks.  Without domain name 
>services, users and applications alike are unable to utilize domain name 
>resolution to access other servers (web, ftp smtp, etc).  This can in 
>effect bring the entire network to a halt.
>
>*** Lethality = 1 ***
>At this point no attack has taken place.  The request was only part of a 
>reconnaissance attempt.
>
>*** System Counter = 1 ***
>With only the IDS logs available for this analysis it is impossible to 
>determine any of system configurations or countermeasures. Thus we must 
>default to a worst case scenario.
>
>*** Network Counter = 3 ***
>As stated previously, no network layouts are available for this analysis.  
>We will assume typical placement of the DNS server within a DMZ.  A 
>firewall and IDS should be part of a standard DMZ implementation thus 
>reducing an attacker's opportunities, while identifying any attempts made 
>to compromise the system.
>
>*** Total = (5 + 1) - (1 + 3) = 2 ***
>The immediate severity of this attack is low, however it should serve as a 
>warning to system administrators that an attacker is lurking and to ensure 
>their DNS server is well maintained.
>
>
>
>9) Defensive Recommendations
>----------------------------
>Should the information provided to the attacker correspond to a BIND 
>version for which a compromise is readily available an attack could soon 
>follow.  Disabling the BIND software from returning the version number, or 
>modifying the returned value to be the latest BIND release will temporarily 
>slow down an attack, but should certainly not be considered an adequate 
>countermeasure.
>
>In addition to a network firewall and IDS system implemented in a properly 
>configured DMZ where the DNS server should reside, an application layer 
>firewall could be configured on the DNS server in order to mitigate 
>specific attacks made to the named service.
>
>Proper system maintenance and timely software updates are the key, 
>understandably this solution is not always a viable one in large 
>corporations or government agencies were patches and software updates must 
>be thoroughly tested before being brought in an operational environment to 
>ensure they do not affect any other systems on the network.
>
>
>
>10) Multiple Choice Test Question
>---------------------------------
>07:46:17.214488 203.197.102.29.3566 > 46.5.237.85.53: [bad udp cksum f7fa!] 
>  4660 [b2&3=0x80] TXT CHAOS? version.bind. (30) (ttl  44, id 6052, length: 
>58)
>
>In the wild, what would happen to the above packet?
>
>A) It would have reached its destination on the next hop.
>B) It would have been dropped by the next router it encountered.
>C) The destination machine would have discarded it as it made
>    its way up the stack. (** correct answer **)
>D) It would have been successfully processed by the destination
>    machine.
>
>
>
>11) References
>--------------
>http://standards.ieee.org/regauth/oui/index.shtml.
>http://www.whitehats.com/info/IDS278
>http://www.sans.org/top20/#u1
>http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
>http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
>http://www.snort.org/docs/writing_rules/chap2.html
>http://cert.uni-stuttgart.de/archive/intrusions/2003/02/msg00191.html
>
>
>
>------------------------------
>
>_______________________________________________
>Intrusions mailing list
>[email protected]
>http://www.dshield.org/mailman/listinfo/intrusions
>
>
>End of Intrusions Digest, Vol 5, Issue 55
>*****************************************

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions