Tag Archive: exploit


A few days ago, Polonus posted about the relationships between unknown html and xmlrpc.php malware. Recently, Essexboy, Polonus, and I had the opportunity to help out a website owner that was infected by his own site. Check out the avast! topic.

At first, the website appeared ok. However, with a search referral, I was shown a 302 (redirect) in the header.

HTTP/1.1 302 Moved Temporarily
Date: Thu, 28 Feb 2013 19:29:17 GMT
Server: Apache
Location: hXtp://fpert.qpoe.com/
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Connection: close
Content-Type: text/html

Also see: urlQuery Report & Sucuri Results

So then, I wondered, what was the root cause behind the redirect? At first, I thought it was an .htaccess redirect, but later, Polonus discovered that it was an xmlrpc.php redirect.

Always keep your WordPress up-to-date,
~!Donovan

Content In Brief

An exploit kit, namely The KaiXin Exploit Kit, was discovered roughly 4 months ago by the malware analyst community. I also posted a decent report of this malware back in August. Since then, KaiXin has made another go for it, introducing Version 1.1, which was blogged today by Eric Romang.

I immediately set out to compare file sizes and detection number on VirusTotal. What I found out was rather shocking. Check out the results of 2 different variants, both shellcode exploits [Note: names are randomly generated, but the size of the files are so similar as to assume they are different variants]:

KaiXin Version 1.0 (cLpl7.html)
[NEW] KaiXin Version 1.1 (JSZlR.html)

KaiXin Version 1.0 (gADSr.html)
[NEW] KaiXin Version 1.1 (WysBRr.html)

The detection rate is lower than before. Why is that?

Keep searching,
~!Donovan

PHP: Local File Inclusion Exploit

LFI allows you to include files through a web server; however, specific injections of parameters in the URL string can lead to other files being called, if not used properly. A basic LFI file looks like the following:

   <?php
   $file = $_GET['file'];
   if(isset($file))
   {
       include("pages/$file");
   }
   else
   {
       include("index.php");
   }
   ?>

A legit referral would look like this: example.com/index.php?file=services.php. It searches the current directory and does not induce upper directory levels. This is the safe approach and should be a standard that you use.

There is also the malcreant approach: example.com/index.php?file=../../../etc/passwd. What this does is show all the passwords (in hash form) that are found on a nix-running system. The malcreant would then be able to crack these passwords and get file access.

However, PHP includes an amazing function called str_replace(), which takes three arguments: The value to replace, what to replace it with, and what string we’re dealing with. Naturally, we can remove all the ‘up directory’ symbols as follows:

   <?php
   $file = str_replace('../', '', $_GET['file']);
   if(isset($file))
   {
       include("pages/$file");
   }
   else
   {
       include("index.php");
   }
   ?>

There is also the option to exclude the request altogether:

if (strpos($file,'../') !== false) {
    echo 'Invalid Request.';
}

The PHP parser only detects the given utf-8 value, so how about if we use hexadecimal as follows?

example.com/index.php?file=..%2F..%2F..%2F/etc/passwd

The following would avoid our current security plans because hexadecimal is not parsed when it meets the PHP script, but is parsed by the client’s browser.

The best way to avoid this exploit is to not use LFI unless you absolutely have to and it cannot be done any other way,
~!Donovan

Updated 51la Malware ~ No Antivirus Detects

Reported on the avast! forums, a site recently got hacked and was redirecting users. Based on the Sucuri and VirusTotal results Pondus gave, I decided to dig a little deeper. I found the following in the HTML return for the hacked site:

Which can be beautified as follows:

Well look at that! Some HTML if the user has scripts disabled. And look at that! An .asp file for an image tag. Suspicious, no?

There is also a script tag for those who do run scripts. I sent the URL to JSunpack.

The unreadable code strikes again.. I have parsed it into readable content:

The following checks for specifics, then generates a cookie based on the returns. Shortly after, the document is fed an invisible image with a go.asp?… At least one antivirus should’ve considered this suspicious..

Ok, but does it work? I sent the URL to urlQuery to confirm just that. Notice on the image preview it says “Connecting to web1.51.la”, which means that the exploit is live and active.

Below are the VirusTotal results, not detected by any antivirus..

Script Getter (As seen in Figure 2) | Script Original (As seen in Figure 3) | Script Beautified (As seen in Figure 4)

 

Could use the following syntax: Base([a/random-letter][4-random-numbers])Mix([2-random-letters])

~!Donovan

Earlier this week, we explored a new way of phishing via URI.

You can display a full, let me state that again, a full working website using data URIs. In this article, I will show you the steps to change a URL to a URI and how (if) exploit kits can take advantage of this feature.

Lets take this simple page that I made. It utilizes an external file, specifically a 3rd party javascript, to determine the value of the loop. Now, we want our URI to not contain any external URLs, so we need to get the source of the javascript file first.

Remember our syntax for data URI:

data:text/<javascript/html>;base64,<data> where <data> is our base64 encoded string.

In this case, we have a javascript file, so naturally we will use data:text/javascript. Lets use our Base64 Converter to obfuscate the content of code.js.

var ran = Math.floor(Math.random()*(10-1+1))+1; becomes

dmFyIHJhbiA9IE1hdGguZmxvb3IoTWF0aC5yYW5kb20oKSooMTAtMSsxKSkrMTsNCg==

We then enclose the data as follows:

<script src=”data:text/javascript;base64,ourcode“></script>

Which is simplified to this:

PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC9qYXZhc2NyaXB0O2Jhc2U2NCxkbUZ5SUhKaGJpQTlJRTFoZE
dndVpteHZiM0lvVFdGMGFDNXlZVzVrYjIwb0tTb29NVEF0TVNzeEtTa3JNVHNOQ2c9PSI+PC9zY3JpcHQ+

Now all we have to do is put <script> tags around our main javascript and base64 obfuscate it! You should get something like this:

PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPg0KZnVuY3Rpb24geChzKSB7DQogICAgZG9jdW1lbnQuYm9keS5p
bm5lckhUTUwgPSBkb2N1bWVudC5ib2R5LmlubmVySFRNTCArICI8YnIgLz4iICsgcw0KfQ0KeCgiVGhpcyBpcyBhIHNpbX
BsZSBwYWdlIikNCngoIldlIHdpbGwgY2hhbmdlIHRoaXMgdG8gVVJJIikNCngoIkJ1dCBpdCB1c2VzIGFuIGV4dGVybmFsIG
xpbmsiKQ0KeCgiU28gd2UgbmVlZCB0byBjb252ZXJ0IHRoYXQgZmlyc3QiKQ0KZm9yKHZhciBsb29wID0gMDsgbG9vcCA8
IChyYW4rMSk7IGxvb3ArKykgew0KICAgIHgobG9vcCkNCn0NCjwvc2NyaXB0Pg==

Testing it out, I get this error:

TypeError: document.body is null
Due to the nature of the DOM, we need to first write our document before we can add code to it in javascript. We will use a simple HTML5 declaration.
<html><body></body> (no </html>) becomes
PGh0bWw+PGJvZHk+PC9ib2R5Pg==

We insert this before the other two snippets.

We then get this:

data:text/html;base64,PGh0bWw+PGJvZHk+PC9ib2R5Pg==PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC
9qYXZhc2NyaXB0O2Jhc2U2NCxkbUZ5SUhKaGJpQTlJRTFoZEdndVpteHZiM0lvVFdGMGFDNXlZVzV
rYjIwb0tTb29NVEF0TVNzeEtTa3JNVHNOQ2c9PSI+PC9zY3JpcHQ+PHNjcmlwdCB0eXBlPSJ0ZXh0L
2phdmFzY3JpcHQiPg0KZnVuY3Rpb24geChzKSB7DQogICAgZG9jdW1lbnQuYm9keS5pbm5lckhUTUw
gPSBkb2N1bWVudC5ib2R5LmlubmVySFRNTCArICI8YnIgLz4iICsgcw0KfQ0KeCgiVGhpcyBpcyBhIHN
pbXBsZSBwYWdlIikNCngoIldlIHdpbGwgY2hhbmdlIHRoaXMgdG8gVVJJIikNCngoIkJ1dCBpdCB1c2Vz
IGFuIGV4dGVybmFsIGxpbmsiKQ0KeCgiU28gd2UgbmVlZCB0byBjb252ZXJ0IHRoYXQgZmlyc3QiKQ
0KZm9yKHZhciBsb29wID0gMDsgbG9vcCA8IChyYW4rMSk7IGxvb3ArKykgew0KICAgIHgobG9vcCk
NCn0NCjwvc2NyaXB0Pg==

So, now we are focusing on shrinking our code. We can use the dreaded document.write instead of document.body.innerHTML, thus <body> tags are not required. Our shrunk code looks like this. Our obfuscated URI looks like this:

data:text/html;base64,PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC9qYXZhc2NyaXB0O2Jhc2U2NCxkb
UZ5SUhKaGJpQTlJRTFoZEdndVpteHZiM0lvVFdGMGFDNXlZVzVrYjIwb0tTb29NVEF0TVNzeEtTa3
JNVHNOQ2c9PSI+PC9zY3JpcHQ+DQpzb21ldGV4dCYjODIwMzsmIzgyMDM7JiM4MjAzOw0KPHNjc
mlwdD4NCmZ1bmN0aW9uIHgocykgew0KICAgIGRvY3VtZW50LndyaXRlbG4ocykNCn0NCngoIlRo
aXMgaXMgYSBzaW1wbGUgcGFnZSIpDQp4KCJXZSB3aWxsIGNoYW5nZSB0aGlzIHRvIFVSSSIpDQp4
KCJCdXQgaXQgdXNlcyBhbiBleHRlcm5hbCBsaW5rIikNCngoIlNvIHdlIG5lZWQgdG8gY29udmVydCB
0aGF0IGZpcnN0IikNCmZvcih2YXIgbG9vcCA9IDA7IGxvb3AgPCAocmFuKzEpOyBsb29wKyspIHsN
CiAgICB4KGxvb3ApDQp9DQo8L3NjcmlwdD4=

Give it a try!

With URIs, if the string is very long, looks suspicious, or is rendered improperly (URIs are handled differently than URLs, I have first-hand experience :P), the browser will not load the page properly, or won’t even load the page at all! This makes converting URLs to URIs by hand harder.

So, in simple words, no. I do not think that authors/contributors of exploit kits would spend explicit time converting their already-working kits to URI. However, I feel that new exploit kits might take advantage of this feature so the exploit kit never meets the internet, thus cannot be analyzed in-depth.

Stay safe,
~!Donovan