Wiki
Clone wikiChallenge11 / Stage1
Stage 0
Using p0f, we obtain the suggestion that 10.0.0.1 is a FreeBSD 8.x or Linux 3.x operating system.
Using a vanilla install of snort (via snort -q -A console -c /etc/snort/snort.conf -r fc_0.pcap -l .
), we obtain the following output:
03/13-22:30:52.678312 [**] [126 :2 :1] (ftp_telnet) Telnet traffic encrypted [**] [Priority: 3] {TCP} 10.0.0.2:42818 -> 10.0.0.1:23
confirming that encrypted telnet traffic is possibly present in our PCAP file.
A Google on the keywords telnet FreeBSD encryption turns up FreeBSD Telnet Service Encryption Key ID Buffer Overflow. From which we obtain CVE 2011-4862 (CVE Details provides a wealth of vulnerability information on this potential exploit).
Looking over the Metasploit FreeBSD Telnet Service Encryption Key ID Buffer Overflow exploit, we note the following:
- an
enc_init
(i.e.0xfffa 2600 0101 1213 1415 1617 1819 fff0
) is first sent from 10.0.0.2 to 10.0.0.1 (i.e. packet 4) - packet 8 contains
0xff fa26 0201
- though, because this packet occurs before packet 7 (our buffer overflow packet), we can see that this particular Metasploit exploit has not been used in the attack recorded in our PCAP file
- packets 7 and 12 contain the following signature byte sequences:
- packet data starts with
0xfffa 2607
and ends with0xfff0
- the expected
key_id
field starts with0xeb76
and has0xeb46
at offset 120 within this field.
- packet data starts with
Because of this, we further believe that the exploit we see in our PCAP file is related to that reported in FreeBSD Telnet Service Encryption Key ID Buffer Overflow.
A good analysis overview of this exploit may be found in telnetd exploit by Compass Security (January 2012). Using this talk, along with material obtained from CVE details, a review of libtelnet/encrypt.c shows that:
- lines 724-726 are the proposed patch to this issue
- line 747 and the lack of any previous sanity check on the value of
len
causedmemmove
to generate a buffer overflow and so an attacker controlled rewrite of the function pointergetcrypt
- line 727 causes any shellcode, that the attacker may have placed under
getcrypt
, to run.
Using this information, we implement a template describing its structure in the SynalzeIt hex editor, to get the following result for our buffer overflow packet (i.e. packet number 7 - highlighted):
Notice how the modep
and getcrypt
long values (after taking endianess into account!) are only 20B apart, as detailed in FreeBSD Telnet Service Encryption Key ID Buffer Overflow. Also note how getcrypt
has the value 0x0804 A8A9
which, according to FreeBSD Telnet Service Encryption Key ID Buffer Overflow, is associated with FreeBSD 8.2.
Stage 0 Sequence Diagram
Updated