VULNERABILITIES MEETING
November 13, 1998
2244 ENG II (Security Lab 2)
2:00-3:00

In attendance:
Matt Bishop, Ricardo Anguino, Tuomas Aura, Brian Cameron, Todd Heberlein, Keith Herold, Scott Miller, David O’Brien, Nick Puketza


Todd Heberlein gives his demonstration on how to detect vertical sweeps and horizontal scans with commentary on why automated response may not be reliable.

Signatures – signs to detect attacks, such as number of connections started at one time
     Count the number of connections to:
                unique ports – lots of connections indicate a vertical sweep
                unique machines – lots of connections indicate a horizontal scan

Automated response
    Must be able to restrict signatures so that you don’t get false alarms (see handout notes)
    Must be able to detect variations of an attack

David O’Brien brought up the “Hack Back” Pentagon/web server problem.  In response to the threat of tying up the Pentagon web server, the Pentagon supposedly created a Java applet to disable the browsers of attackers.
    Violation of the General Computer Misuse Law?

Handout Notes:


> From: Todd Heberlein <todd@NetSQ.com>
> To: dfaatz@MITRE.ORG; IAIPT@bs1.prc.com
> Cc: alwilson@bbn.com
> Subject: Re: Bi-Weekly, 12 Nov
> Date: Thursday, November 12, 1998 9:34 AM

Another message from the "Lessons Learned" files (LL-Files)

> Folks,
>
> Attached are a few slides with thoughts from the Strategy workshop at NDU for today's (Thursday, 11/12) IA bi-weekly).
>
>   ...Don

On Don's second slide is the question "Are we under attack?"  This takes on even greater importance as we move to [automated] response.

Last Tuesday our network monitor running at UCD picked up a "vertical network sweep", a host trying to connect to many ports on the same machine.

On one hand, it had a very classic singature: hundreds of unique ports tried on a single machine, one attempt per port.  Furthermore, in this case the sweep was hitting consecutive ports (4548, 4549, ...).

However, on further inspection, it turned out to be a user retrieving 1852 files by FTP.  Each file transfer established a new connection at consecutively higher port numbers.  So what appeared to be a sweep was a legitimate, if unusual, activity!

Fortunately, I had the information to allow me to drill down.  (samples of logs are shown below).

I suspect during times of crisis (e.g., beginning of hostilities), there will be a lot of unusual activity.  We should be careful with our responses.

Todd


Sample report mailed to me (fired off from a SNMP database collecting reports).  wheel (168.150.253.1) initiated 112 connections requests to 2 unique hosts on 112 unique ports.  It was tagged as a "vertical" sweep because of the large number of unique ports.

"sweep" "vertical" #=8
168.150.253.1
"count=112,nh=2,np=112"
src=wheel.dcn.davis.ca.us
Tue Nov 10 10:17:41 1998


The report above is a reduction of a larger record; however, I can retrieve the full report, which I did to examine the actual ports used.  [note the clock skew]  The scan from 168.150.253.1 (wheel) appears to be against 169.237.42.164 (asylum).  The sample of ports shown (with most recently requested one first) shows the patterns of consecutively ports accessed.

ADDR-EVENT:
Client:
 Analysis:
Confidence:
Start time:
Report time:
Events:
Addresses:
Ports:

Addresses:

 Ports:


 
 
 
 		 168.150.253.1
vertical-sweep
high
Tue Nov 10 10:18:44 1998
Tue Nov 10 10:19:45 1998
112
2
112

169.237.42.164   111
128.120.8.1         1
2713      1
2712      1
2711      1
2710      1
2709      1

I then zoomed in on several of the individual connections (I removed some information to have it fit in 80 columns).  Each one appeared to be coming from the same source port, 20.  Port 20 is often (although less often than in the past) used for FTP data transfers, so I looked for FTP sessions between the two hosts involved.

5443002    168.150.253.1  -->   169.237.42.164  (   20 ->  4548)
5443010    168.150.253.1  -->   169.237.42.164  (   20 ->  4549


Below is one of two FTP audit records from asylum (169.237.42.164) to wheel (168.150.253.1).  Both FTP sessions included massive numbers of file retrieves of the form ii.nnnn from a directory called News.

5599834   169.237.42.164  -->    168.150.253.1  (2840 -> 21) from: 10:38:04 (11/10/1998)  to: 10:48:14 (11/10/1998) client flags: SAF     server_flags: SAF
         ---- FTP -----------------------------------------
          USER  3   name-changed
          PASS  2   Xxxxxxxx
           CWD  2   News
          RETR  1   ii.1000
          RETR  1   ii.1001
          RETR  1   ii.1002
          RETR  1   ii.1003 ...

Lessons:
(1) large numbers of connections to unique ports may not be a scan.
(2) What appeared to be a scan by wheel against asylum was actually initiated by asylum.

Todd