I was looking for a good example to highlight two very useful and often overlooked features of Wireshark: the flexibility of tshark and the tool suite's HTTPS/SSL decryption capability. The following example covers both, and goes a bit further to describe one way of investigating an attack to assess the likelihood of compromise. While contrived, make no mistake about it, this is reflective of a real-world attack seen recently, later linked to sophisticated adversaries.
We are in the business of risk management. As such, our response to suspicious activity should be guided by the components that risk is the product of. While terminology may vary, the breakdown I use is:
- Impact
- Vulnerability
- Threat
An understanding of risk components in the context of a computer security incident is often evolutionary. Response changes according to the risk, which is constantly adjusted as the responders learn more about the potential impact to the organization, the vulnerability of assets targeted (or, conversely, success of the attack), and the actors behind the attack. Typically, the initial component addressed is vulnerability - was the attack successful. In the case of HTTPS attacks observed passively through network activity, answering this question can be very difficult. Indeed, without access to webserver logs, all investigations of intrusions that intersect HTTPS in any way are made much more difficult since no data above OSI layer 4 is visible.
Tipoff
In our example, we are informed by a network activity monitor that web traffic increased significantly to a particular server on our network - over 50% increase in 2 days.
This exposed server is in a DMZ, but provides proxied access to sensitive information (impact) and has had problems in the past (clue into potential vulnerability). At the same time, we are told by a partner that they had just experienced a compromise of a server by a sophisticated adversary intent on stealing intellectual property (targeted attacks for the purposes of stealing specific data - as high a threat level as you will find). While normally an increase in web activity could be the result of any number of things and would go ignored in a large company, the level of risk here, based loosely on the information available, seems that it could be very high. Even in the case of no compromise, the risk level is probably high enough to warrant investigation and follow-up to mitigate against the threat in the future.
Investigation
While contacting the administrator is always a good idea at this point, it's not always possible. That, and administrators tend to "help" by "fixing" the server in question and trampling valuable evidence. We'll proceed as far as we can without leveraging this option.
Responding to the incident in a timely manner, on a well-instrumented network, we are fortunate to have full packet captures over the period in question. Let's use tshark to take a look at the requests.
$ tshark.exe -r suspect.pcap |head 1 0.000000 172.16.1.75 -> 10.1.1.55 TCP 56167 > http [SYN] Seq=0 Win=64512 Len=0 MSS=1360 2 0.359511 172.16.1.75 -> 10.1.1.55 TCP 56167 > http [ACK] Seq=1 Ack=1 Win=64512 Len=0 3 0.367123 172.16.1.75 -> 10.1.1.55 HTTP GET /index.html HTTP/1.1 4 0.755489 172.16.1.75 -> 10.1.1.55 TCP 56167 > http [FIN, ACK] Seq=231 Ack=182 Win=64331 Len=0 5 0.757968 172.16.1.75 -> 10.1.1.55 TCP 56180 > http-alt [SYN] Seq=0 Win=64512 Len=0 MSS=1360 6 0.760386 172.16.1.75 -> 10.1.1.55 TCP 56167 > http [ACK] Seq=232 Ack=183 Win=64331 Len=0 7 0.796530 172.16.1.75 -> 10.1.1.57 TCP 56183 > http [SYN] Seq=0 Win=64512 Len=0 MSS=1360 8 1.147451 172.16.1.75 -> 10.1.1.57 TCP 56183 > http [ACK] Seq=1 Ack=1 Win=64512 Len=0 9 1.153909 172.16.1.75 -> 10.1.1.57 HTTP GET /favicon.ico 10 1.502208 172.16.1.75 -> 10.1.1.57 TCP [TCP Dup ACK 9#1] 56183 > http [ACK] Seq=231 Ack=1 Win=64512 Len=0 SLE=182 SRE=183
Tshark gives us access to the full suite of capabilities of Wireshark, using the same field reference nomenclature. Above, we see the default output. Notice how much it looks like Wireshark! Filtering works the same as it would in Wireshark, as a matter of fact. Let's take a look at the server in question:
$ tshark.exe -r suspect.pcap "ip.addr == 10.1.1.55" |head 1 0.000000 192.168.1.75 -> 10.1.1.55 TCP 56167 > http [SYN] Seq=0 Win=64512 Len=0 MSS=1360 2 0.359511 192.168.1.75 -> 10.1.1.55 TCP 56167 > http [ACK] Seq=1 Ack=1 Win=64512 Len=0 3 0.367123 192.168.1.75 -> 10.1.1.55 HTTP GET /index.html HTTP/1.1 [...]
So what's going on here? Perusing through the data, we see requests for multiple sites, and HTTPS requests (rut roh). Here's where tshark's field selection can come in handy. Using the same nomenclature as Wireshark, we can filter on anything Wireshark has access to, and also select any fields Wireshark has access to! Below, we'll look for all HTTP requests, and select the "hostname" field using the "-T fields" option.
$ tshark.exe -r suspect.pcap -T fields -e http.host "ip.addr == 10.1.1.55 && http" server1.domain.com server1.domain.com server2.domain.com [...] $ tshark.exe -r suspect.pcap -T fields -e http.host "ip.addr == 10.1.1.55 && http" |sort -u server1.domain.com server2.domain.com
So, let's map this to the problem at hand. What sort of trends are we seeing? With a bit of bash fu, we can get some date counts.
$ tshark.exe -t ad -r suspect.pcap "ip.addr == 10.1.1.55 && http && http.host == server1.domain.com" \
|awk '{print $2}' |sort |uniq -c
30 2009-04-01
50 2009-04-02
[...]
Don't forget we saw that SSL activity too! I think you're probably getting the hang of tshark by now. Plotting this out, we see how dramatically SSL activity increased in one day, to cause the 7-day average to increase 50%.
If this is an attack, it's very wisely executed. While our traffic profile changed, we have no idea what happened in those HTTPS connections. If it was an attack, what kind was it? Was the attack successful? We can't answer these questions until we see what's going on inside those sessions. We've seen tshark's power, and by now you can imagine how to go about tearing apart those HTTP connections. Let's say there was nothing suspicious in there. What remains in assessing the situation is removing the SSL veil that accounts for the bulk of this activity.
Digging into the crypto
At this point, there is no avoiding getting in contact with the administrator. Wouldn't you know, the web service wasn't configured properly (surprise, surprise) and logging is disabled. Your only hope of explaining the activity is by decrypting the packets you've captured with the private key. NEVER FEAR! Current versions of wireshark, and therefore tshark, support session decryption if you can provide the private key. The only trick is a little bit of configuration - and, of course, getting the key in the first place.
We'll start with Wireshark. Looking at the data from the pcaps, we see the encryption makes the contents opaque.
Fortunately, all we have to do is add a configuration parameter to Wireshark's preferences for the SSL protocol. The format is <ip>,<decrypt protocol>,<key file>.
Now, Wireshark decrypts the session and we can see into the packet.
It really is that easy. Now, of course, you want to analyze this data statistically, and make broad statements about the attack. As a command-line tool, as we've already seen, tshark is scriptable and far more suited to our needs here. Once again, decryption is simply a matter of tool configuration, which means leveraging tshark's '-o' parameter to specify a preference setting, which will be the exact same text as provided in the SSL configuration of the GUI. IMO, this is even easier than the GUI tool, and provides the flexibility analysts need to assess what happened statistically via alternate scripting tools.
Previously, we had this (truncated to align with Figures 3 and 5):
$ tshark.exe -x -r suspect.pcap "ip.addr == 10.1.1.55 && tcp.port == 443"
[...]
8876 734.241004 TLSv1 Application Data
0000 00 00 5e 00 01 0b 00 18 74 2c 79 80 08 00 45 40 ..^.....t,y...E@
0010 01 12 64 6e 40 00 6f 06 dc 7b ca 27 4b 4b a6 17 ..dn@.o..{.'KK..
0020 0e 32 87 c4 01 bb 5b 2c e4 37 27 a9 9f 24 50 18 .2....[,.7'..$P.
0030 fb d5 f9 f8 00 00 17 03 01 00 e5 e0 5d 60 87 c7 ............]`..
[...etc...]
Now, we have this (same packet, truncated):
$ tshark.exe -x -r suspect.pcap "ip.addr == 10.1.1.55 and tcp.port == 443" \
-o ssl.keys_list\:10.1.1.55,443,http,somekey.key
[...]
8876 734.241004 HTTP POST /manager/html HTTP/1.1
Frame (288 bytes):
0000 00 00 5e 00 01 0b 00 18 74 2c 79 80 08 00 45 40 ..^.....t,y...E@
0010 01 12 64 6e 40 00 6f 06 dc 7b ca 27 4b 4b a6 17 ..dn@.o..{.'KK..
0020 0e 32 87 c4 01 bb 5b 2c e4 37 27 a9 9f 24 50 18 .2....[,.7'..$P.
[...]
0110 78 36 9d 26 43 85 d0 02 78 7b 48 2d 09 10 9e 61 x6.&C...x{H-...a
Decrypted SSL data (213 bytes):
0000 50 4f 53 54 20 2f 6d 61 6e 61 67 65 72 2f 68 74 POST /manager/ht
0010 6d 6c 20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 ml HTTP/1.1..Acc
0020 65 70 74 3a 20 2a 2f 2a 0d 0a 41 63 63 65 70 74 ept: */*..Accept
0030 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 2d 75 73 -Language: en-us
0040 0d 0a 41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e ..Accept-Encodin
0050 67 3a 20 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 g: gzip, deflate
0060 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f ..User-Agent: Mo
0070 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 zilla/4.0 (compa
0080 74 69 62 6c 65 3b 20 4d 53 49 45 20 35 2e 30 31 tible; MSIE 5.01
0090 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 35 2e 30 ; Windows NT 5.0
[...]
Well lookie thar! Of course, now we can do all (well, most of) the other field filtering tricks to select output once again, just as we did in the previous sections. The primary goal of this entry having been met, I'll leave that, and how to assess attacker success, as an exercise for the reader.
If you liked this entry, keep an eye out for a follow-on to John Sawyer's Network Forensics on a Shoestring Budget, where he will also be discussing tshark's use!
Michael is a senior member of an incident response team for a large defense contractor. He has lectured for various audiences from IEEE to DC3, and teaches an introductory class on cryptography. His current work consists of security intelligence analysis and development of new tools and techniques for incident response. Michael holds a BS in computer engineering and has earned GCIA (#592) and GCFA (#711) gold certifications alongside various others.
.png "Six_Steps_for_Successful_Mobile_Validation_(7).png")
