[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Jeremy Scott

jscott at rolenstarsupply.com jscott at rolenstarsupply.com
Thu Jul 1 22:54:48 GMT 2004


Network Detect 2:  Proxy scan
 

Jun  20  00:00:00  tcp    216.232.9.229(1422)        xxx.xxx.xxx.231(3127),       denied

Jun  20  00:00:06  tcp    220.99.138.166(4867)       xxx.xxx.xxx.35(3127),        denied

Jun  20  00:00:08  tcp    220.99.138.166(4738)       xxx.xxx.xxx.37(3127),        denied

Jun  20  00:00:08  icmp   217.88.124.253             xxx.xxx.xxx.221              denied

Jun  20  00:00:14  tcp    220.99.138.166(3208)       xxx.xxx.xxx.35(3128),        denied

Jun  20  00:00:16  tcp    216.232.9.229(1690)        xxx.xxx.xxx.231(1080),       denied

 

1.  Source of Trace:
 

This was taken from the external router log produced on my company network.  Our intrusion detection is within the external router; therefore, no other logs are available to correlate the data.  The internal IP addresses have been obfuscated for security reasons.  

 

2.  Detect was generated by:
 

Self observation of the external router logs pulled on a daily basis.  Looking at the logs for signs of malicious behavior by hand can be tedious but there can also be a wealth of knowledge in what is happening just outside your border.  Here is a compiled example of the scan:

 

Access Attempts logged By MY_ROUTER

Mon  Day Time      Type   Source Address (Port)      Destination Address (Port)

---  -- 

Jun  20  00:00:06  tcp    220.99.138.166(4867)       xxx.xxx.xxx.35(3127),        denied 

Jun  20  00:00:06  tcp    220.99.138.166(4867)       xxx.xxx.xxx.35(3127),        denied

Jun  20  00:00:06  tcp    220.99.138.166(4867)       xxx.xxx.xxx.35(3127),        denied

Jun  20  00:00:22  tcp    220.99.138.166(3486)       xxx.xxx.xxx.35(1080),        denied

Jun  20  00:00:40  tcp    220.99.138.166(4068)       xxx.xxx.xxx.36(3128),        denied

Jun  20  00:01:01  tcp    220.99.138.166(4738)       xxx.xxx.xxx.37(3127),        denied

Jun  20  00:01:28  tcp    220.99.138.166(3825)       xxx.xxx.xxx.40(3128),        denied

Jun  20  00:01:36  tcp    220.99.138.166(4105)       xxx.xxx.xxx.40(1080),        denied

Jun  20  00:01:44  tcp    220.99.138.166(4382)       xxx.xxx.xxx.41(3127),        denied

Jun  20  00:01:52  tcp    220.99.138.166(4869)       xxx.xxx.xxx.41(3128),        denied

Jun  20  00:01:58  tcp    220.99.138.166(3825)       xxx.xxx.xxx.40(3128),        denied

Jun  20  00:02:04  tcp    220.99.138.166(4105)       xxx.xxx.xxx.40(1080),        denied

Jun  20  00:02:24  tcp    220.99.138.166(3209)       xxx.xxx.xxx.41(1080),        denied

Jun  20  00:02:40  tcp    220.99.138.166(3507)       xxx.xxx.xxx.42(3127),        denied

Jun  20  00:02:53  tcp    220.99.138.166(4053)       xxx.xxx.xxx.42(1080),        denied

Jun  20  00:03:02  tcp    220.99.138.166(4326)       xxx.xxx.xxx.43(3127),        denied

Jun  20  00:03:04  tcp    220.99.138.166(3698)       xxx.xxx.xxx.44(3128),        denied

Jun  20  00:03:11  tcp    220.99.138.166(4727)       xxx.xxx.xxx.43(3128),        denied

Jun  20  00:03:16  tcp    220.99.138.166(3427)       xxx.xxx.xxx.44(3127),        denied

Jun  20  00:03:28  tcp    220.99.138.166(3698)       xxx.xxx.xxx.44(3128),        denied

Jun  20  00:03:33  tcp    220.99.138.166(3970)       xxx.xxx.xxx.44(1080),        denied

Jun  20  00:03:52  tcp    220.99.138.166(4247)       xxx.xxx.xxx.45(3127),        denied

Jun  20  00:04:00  tcp    220.99.138.166(4629)       xxx.xxx.xxx.45(3128),        denied

Jun  20  00:04:17  tcp    220.99.138.166(3345)       xxx.xxx.xxx.46(3127),        denied

Jun  20  00:04:30  tcp    220.99.138.166(3902)       xxx.xxx.xxx.46(1080),        denied

Jun  20  00:04:37  tcp    220.99.138.166(4176)       xxx.xxx.xxx.47(3127),        denied

Jun  20  00:04:48  tcp    220.99.138.166(4969)       xxx.xxx.xxx.47(1080),        denied

Jun  20  00:05:04  tcp    220.99.138.166(3554)       xxx.xxx.xxx.48(3128),        denied

 

3.  Probability the source address was spoofed:
 

Since there were no other logs to correlate the data to, I can't tell if the packets have any signs of crafting.  However, because of the ports that are being scanned the source address is probably real.

 

Source Address - The source address is 220.99.138.166.  If you do a whois on the IP address, you will be returned with the following information from APNIC.

 

 % [whois.apnic.net node-1]% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.htmlinetnum:      220.96.0.0 - 220.99.255.255netname:      OCN-JPNIC-JPdescr:        OCN Provided By NTT-Communications which is ISPdescr:        in Chiyoda-ku, Tokyo, Japancountry:      JPadmin-c:      JNIC1-APtech-c:       JNIC1-APremarks:      ************************************************remarks:      Allocated to JPNIC member. Authoritativeremarks:      information regarding assignments and allocationremarks:      made from within this block can also be queriedremarks:      at whois.nic.ad.jp. To obtain an English outputremarks:      query whois -h whois.nic.ad.jp x.x.x.x/eremarks:      Email address for spam or abuse complaints : abuse at ocn.ad.jpremarks:      ************************************************mnt-by:       MAINT-JPNICmnt-lower:    MAINT-JPNICchanged:      hm-changed at apnic.net 20020904changed:      ip-apnic at nic.ad.jp 20040413status:       ALLOCATED PORTABLEsource:       APNICrole:         Japan Network Information Centeraddress:      Kokusai-Kougyou-Kanda Bldg 6F, 2-3-4 Uchi-Kandaaddress:      Chiyoda-ku, Tokyo 101-0047, Japancountry:      JPphone:        +81-3-5297-2311fax-no:       +81-3-5297-2312e-mail:       hostmaster at nic.ad.jpadmin-c:      SS13-APtech-c:       SY7-APnic-hdl:      JNIC1-APmnt-by:       MAINT-JPNICchanged:      apnic-ftp at nic.ad.jp 19990629changed:      ip-staff at nic.ad.jp 20030806source:       APNICinetnum:      220.99.128.0 - 220.99.255.255netname:      PLALAdescr:        Plala Networks Inc.country:      JPadmin-c:      MN2905JPtech-c:       HS3694JPremarks:      This information has been partially mirrored by APNIC fromremarks:      JPNIC. To obtain more specific information, please use theremarks:      JPNIC whois server at whois.nic.ad.jp. (This defaults toremarks:      Japanese output, use the /e switch for English output)changed:      apnic-ftp at nic.ad.jp 20030203remarks:      This information has been partially mirrored by APNIC fromremarks:      JPNIC. To obtain more specific information, please use theremarks:      JPNIC whois server at whois.nic.ad.jp. (This defaults toremarks:      Japanese output, use the /e switch for English output)changed:      apnic-ftp at nic.ad.jp 20040609source:       JPNIC 

In that it is a valid IP address according to APNIC and the ports that are being probed may return some type of response to allow the hacker to gain access to the system leads me to believe that the IP address is not spoofed.

 

4.  Description of attack:
 

The attack is obviously a scan for Socks and squid proxies in attempt to locate a compromised system or one that is running the service to exploit possible vulnerabilities within the service.

 

A CVE that covers the squid proxy vulnerability can be found at the following URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0068 

 

A CAN, which is under review at this time, that covers the socks proxy vulnerability can be found at the following URL:  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0315 

 

Along with the proxies, the attacker appears to be probing for port 3127.  This port is left open as a back door by the myDoom virus[1] which in future could be an avenue for a denial of service attack in the future, according to CERT at http://www.cert.org/incident_notes/IN-2004-01.html. 

 

5.  Attack mechanism:
 

The attacker is probing the network in search of responding ports.  Since there are no other logs to correlate with, I can only assume that the TCP packets that are being sent are to elicit some response to find a listening or compromised host.  For example, the attacker sends an unsolicited TCP packet with the ACK flag set.  The normal response would be for the host to respond back with RST.  If that is indeed the case, the attacker now knows that:  1) the host is alive and listening, and 2) there is no filtering in place.

 

If the attacker receives no response then he can assume: 1) some type of filtering is in place, or 2) that the host is not alive.

 

If the attacker receives the response that is being solicited then he can attempt to exploit the vulnerabilities with a buffer overflow using specially crafted packets.  In the case of the back door left by the myDoom virus, the attacker could possible take control of that system to launch a denial of service attack.

 

6.  Correlations:
 

I found a posting at http://lists.sans.org/pipermail/unisog/2004-March/006955.php that states that they had seen some scans, particularly on the weekends, just a couple of months back.  I was unable to see any other postings to correlate my findings.

 

7.  Evidence of active targeting:
 

It appears to be targeted in the sense that it is targeting three specific ports as possible back doors to compromised systems.  Also, the attacker is scanning the full range of addresses on this particular subnet.  The scans are not rapid in succession but fairly consistent.

 

8.  Severity:
 

severity = (criticality + lethality) - (system countermeasures + network countermeasures)

Each value is ranked on a scale from 1 (lowest) to 5 (highest).

 

Criticality: 2

 

I believe that criticality is low based on the fact that we do not run socks or squid proxies on our network.  It is possible that the myDoom virus could be introduced but active virus scanning with updated definitions is in use.

 

Lethality: 3

 

I do not think that this scan in itself is very lethal but the nature of business on my network a compromise could be very lethal.  A continued monitoring of this type of scan and any other associated IP addresses should be considered.

 

System countermeasures: 2

 

The systems on this network are patched and updated regularly or as they become available.  The systems administrators do a fair job of ensuring that the systems are secure and up to date.

 

Network countermeasures: 3

 

I am happy to say that this scan was denied at the border router.  The network currently uses a defense-in-depth approach.  Inside the border router, using extensive ACLs, is monitored by a network IDS.  A firewall is then in place that all traffic to the internal network is routed through.  The internal network is monitored by multiple network IDS on various segments along with Cisco IDS modules in the switches.  Correlation with various agencies allows us to put preventative measures up at the border ahead of time.

 

9.  Defensive Recommendations:
 

The border router should be configured to block incoming requests for services that are not in use or vulnerable to remote access.  If the scan is coming from a specific host, then that IP address can be blocked at the router.  Firewalls, should also be set to block any unused services.  Since the scan also includes the port commonly associated with the myDoom virus, a full system scan with updated definitions should be done on all systems to ensure that none of the systems have been compromised. 

 

10.  Multiple choice test question:
 

What range of ports does the myDoom virus open up and listen on?

 

a.      4200-4000

b.      3127-3198

c.      1024-1029

d.      135-139

 

Answer: b.

A system that has been compromised by the myDoom virus opens ports 3127-3198, according to CERT http://www.cert.org/incident_notes/IN-2004-01.html.



--------------------------------------------------------------------------------

[1] LinkLogger



More information about the Intrusions mailing list