Thursday, December 10, 2015

tcpreplay - Taking a look at packet replaying.

While teaching the SANS 503 (Intrusion Detection In-Depth) Community class last week in Ottawa,  a student asked if the packets are actually replayed to the destination hosts. I stated yes but I thought I should also do a blog post on the topic.

In this example, I'm replaying SSH traffic which was captured earlier in the day and is now being replayed.

The objective of this post is just to show that yes the traffic would go to the destination.

Let's first configure the IP address of the eth0 interface and give it a default route. There is really no  need for the default route as the source and destination are on the same subnet. I just put it there as it is something I typically do. .

Let's verify the interface configuration


While we are attempting to connect to the host at 192.168.0.3, we will also run tcpdump in the background. This allows us write the traffic to a file and then we can replay later.

Now let's try to connect via SSH to the host at 192.168.0.3. Note the date and time.

These connections have all failed.

Now let's replay this traffic.



Let's see how many packets were captured via tcpdump.

Looks like we got 76 packets. If we compare this with the number of packets replayed via tcpreplay, we will see that the 76 matches the number of packets attempted and the 76 which were successful.
Here we have the packets which were sent via tcpreplay


Here we have what iptables saw



Let's compare the two images to see if we can detect this as replayed traffic.

Source Port 35935: The same in the original pcap and in the iptables log.
Destination Ports 22: The same in the original pcap and in the iptables log.
Sequence numbers: Remain the same across both
the pcap and the iptables.log
Acknowledge numbers:
Remain the same across both the pcap and the iptables.log
Flags: The flags are the same



Point to note is that while the traffic is replayed to the host, the application layer did not pick this traffic up and attempt create a SSH session.

So from the above, hopefully if anyone else had a similar questions about replaying of the traffic this post may help to clear it up.

Additional Readings:
http://tcpreplay.synfin.net/wiki/usage
http://tcpreplay.synfin.net/wiki/manual
http://tcpreplay.synfin.net/tcpreplay.html





Wednesday, December 9, 2015

Covert Channels - Part 2 - exfiltrating data through TCP Sequence Number field

A while back I did this blog post on transferring data via the IP ID field.
Recently, I had to do some work on this topic again, so I thought I should now publish the second part which I should have completed a lonnnnnng time ago.

In this post we will look at transferring the "/etc/shadow" file using "covert_tcp" via TCP sequence number field.

Our setup?
Everything is on one system but do note that covert_tcp has a client and server component.
Server configuration



Client configuration and execution


Above we see the client has been loaded and data being transmitted one byte at a time.

Below we see the server receiving data one byte at a time.

















A "ls -al" of the files shows their similarity.





While the data was exfiltrated, I also had "tcpdump" running in the background

Below shows the packets captured.

So what does the capture traffic look like?

How to detect and or mitigate against this type of traffic?

Let's  see what stands out.
1. Large number of SYN packets
If this is a legitimate connection attempt, then we need to see corresponding  SYN-ACK and a final ACK. The fact that there is a large number of SYNs with no complete 3-way handshake should make this standout as suspicious.

2. Large number of corresponding RST-ACKs
Attempts to connect to a port which is not listening should result in a RST-ACK. Therefore the question here should be why the persistence to continue connecting to a port which is not listening. The large number of RST-ACKs as seen in the packet capture should be reason to suspect something malicious.

3. All packets have the same IP length.
This is also strange. I look at this and immediately start to think of a crafted packet or something malicious.

4. The port number is reused.
Every new client connection should have a new source port. The fact that these are all the same suggests that there is something suspicious going on here and an investigation should be performed to determine the nature of this traffic.


So we highlighted a few points above. But is there anything else which can be used to detect this type of activity?! Statistical analysis, anomaly detection, behavioural analysis are all methods that can possibly be used to detect this type of activity. However, the 4 items above are clear signs of something malicious.

References:
http://securitynik.blogspot.ca/2014/04/covert-channels-communicating-over-tcp.html
http://www-scf.usc.edu/~csci530l/downloads/covert_tcp.c
http://firstmonday.org/ojs/index.php/fm/article/view/528/449
Packet Capture - myShadow.pcap



Tuesday, December 8, 2015

Some tshark examples a mix of basic and somewhat advance


Viewing all IP packets
tshark -n -r filename.pcap  -Y "ip"

Viewing all TCP packets

tshark -n -r filename.pcap  -Y "tcp"

Viewing protocol hierarchy
tshark -n -r filename.pcap  -z io,phs -q

View all IP endpoints

tshark -n -r filename.pcap  -z endpoints,ip -q

View all TCP endpoints

tshark -n -r filename.pcap  -z endpoints,tcp -q

View IP conversations
tshark -n -r filename.pcap  -z conv,ip -q

View TCP conversations

tshark -n -r filename.pcap  -z conv,tcp -q

Show tabular view with field headers

tshark -n -r filename.pcap  -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tcp.flags -E header=y

Verify that the first two bytes of the IP header is 0x4500
tshark -n -r filename.pcap -x "ip[0:2] == 45:00"

Source IP is 192.168.0.2

tshark -n -r filename.pcap -x "ip[12:4] == c0:a8:00:02"

destination IP is 192.168.0.1

tshark -n -r filename.pcap -x "ip[16:4] == c0:a8:00:01"

Show IPv4 Destinations/Statistics and Ports

tshark -n -r filename.pcap  -z dests,tree -q

Follow TCP stream
tshark -n -r filename.pcap  -z follow,tcp,ascii,0 -q

a few not so basic windump examples

Verify IP verion is 4windump -nvv -r filename.pcap -X "ip[0] & 0xF0 = 0x40"

Verify IP header has no options. That is the IP header is 20 bytes
windump -nvv -r filename.pcap -X "ip[0] & 0x0F = 0x5"

Verify that IP protocl is ICMP

windump -nvv -r filename.pcap -X "ip[9] = 0x01"

Verify that IP protocol is UDP
windump -nvv -r filename.pcap -X "ip[9] = 0x11"

Verify that IP protocol is TCP
windump -nvv -r filename.pcap -X "ip[9] = 0x06"

Determine time to live is less than 128
windump -nvv -r filename.pcap -X "ip[8] < 128"

Tracking IP packets with More Fragments flag set
windump -nvv -r filename.pcap -X ip[6] = 0x20

Verifying that source IP is 10.0.0.6
windump -nvv -r filename.pcap -X "ip[12] = 0x0a && ip[13] = 0x00 && ip[14] = 0x00 && ip[15] = 0x06"

Verifying that destination IP is 151.164.1.8
windump -nvv -r filename.pcap -X "ip[16] = 0x97 && ip[17] = 0xa4 && ip[18] = 0x01 && ip[19] = 0x08"

All traffic from tcp source port = 23
windump -nn -r filename.pcap -X "tcp[0:2] = 23"

All traffic from tcp dst port 1254
windump -nn -r filename.pcap -X "tcp[2:2] = 1254"

All packets with SYN flag set
windump -nn -r filename.pcap -X "tcp[13] = 0x02"

All packets with SYN/ACK flags set
windump -nn -r filename.pcap -X "tcp[13] = 0x12

All packets with FIN flag set
windump -nn -r filename.pcap "tcp[13] & 0x01 = 0x01"

Looks for TCP packets with header length greater than 20 bytes
windump -nn -r filename.pcap "tcp[12] & 0xF0 > 0x50"

Look for packets with the PUSH flag set
windump -nn -r filename.pcap "tcp[13] & 0x08 = 0x08"

References
http://www.tcpdump.org/tcpdump_man.html


Windump basics by examples

Just a quick put together of some basic tcpdump commands.

In this post I will be targeting a .pcap file. However, these commands can be used for live capture

See all packets in the capture file
windump -n -r filename.pcap

Show only the first 2 packets
windump -n -r flename.pcap -c 2

Tracking host by source MAC address
windump -n -r filename.pcap -e "ether src 00:a0:cc:3b:bf:fa"

Tracking host by destination MAC address
windump -n -r filename.pcap -e "ether dst 00:a0:cc:3b:bf:fa"

Tracking host by IP, whether that IP is source or destination
windump -n -r filename.pcap "host 192.168.0.1"

Track host by source IP
windump -n -r filename.pcap "src host 192.168.0.1"

Track host by destination IP
windump -n -r filename.pcap "dst host 192.168.0.1"

Track port even if it is the source or destination
windump -n -r filename.pcap "port 1254"

Tracking a source port
windump -n -r filename.pcap "src port 1254"

Track a destination port
windump -n -r filename.pcap "dst port 1254"

Tracking a UDP specific UDP port
windump -n -r filename.pcap "udp port 1254"

Tracking a specific source UDP port
windump -n -r filename.pcap "udp src port 1254"

Tracking a specific destination udp port
windump -n -r filename.pcap "udp dst port 1254"

Capturing all ARP
windump -n -r filename.pcap "arp"

Capturing all IP packets
windump -n -r filename.pcap "ip"

Capturing all UDP packets
windump -n -r filename.pcap "udp"

Capturing all ICMP packets
windump -n -r filename.pcap "icmp"

Capturing all ICMP packets
windump -n -r filename.pcap "tcp"



References

http://www.tcpdump.org/tcpdump_man.html