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 with 0xfff0
  • the expected key_id field starts with 0xeb76 and has 0xeb46 at offset 120 within this field.

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 caused memmove to generate a buffer overflow and so an attacker controlled rewrite of the function pointer getcrypt
• 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