Latest Entries »

Have you ever seen something like this before?

var1=[Integer];
var2=var1;
if(var1==var2) { document.location=”[Insert URL Here]“; }

I have, and today I finally decided to dig a little deeper. In this article we will cover URLs that are used with this redirecting method, other malicious JavaScript files that have adapted to this method, and test this method with various techniques against the AV industry.

Here is the complete list of the URLs I found that are used as the document.location:

hXtp://ukr.net
hXtp://topsearch10.com/search.php?aid=62756&q=home+jobs
hXtp://popka-super.ru
hXtp://realstarsearch.com/search.php?q=runescape+automine
hXtp://zaebiz.info
hXtp://global-advers.com/soft.php?aid=0153&d=2&product=XPA
hXtp://www.mp3sugar.com/?aff=2081
hXtp://evamendesochka.com/go.php?sid=9
hXtp://catalog--sites.info/sea
hXtp://yahhooo.info/search.php?q=ritalin&tpl=forbot
hXtp://tnij.com/iewt
hXtp://clickcashmoney.com/in.htm?wm=101360
hXtp://www.rarewatches.net
hXtp://web4w3.com/jblob.html
hXtp://мой_сайт.ру
hXtp://www.xakep.ru
hXtp://go.1ps.ru/pr/p.php?223280
hXtp://www.searchfor-avail.com/search.php?aff=18424&q=audrey+bitoni
hXtp://www.vipspace.net/?ref=kuzma2002ru
hXtp://officialmedicines.com/item.php?id=162&aid=2268
hXtp://zonaconsult.ru/index.php?option=com_content&view=article&id=94
hXtp://porta100.narod.ru
hXtp://куда редиректить.ru
hXtp://www.0xy.ru
hXtp://имя домена.ru
hXtp://www.autoshkatulka.ru/index.php
hXtp://www.vsemayki.ru/?ref=11049
hXtp://www.ruclicks.com/in/ys0ik6uu
hXtp://www.links-service.info/search.php?q=Abortion+pill
hXtp://tvoi-dosug.com/in.htm?wm=1001116
hXtp://hotkeysearch.com/go.php?sid=2
hXtp://geforceexlusive.ru:8080/forum/links/column.php

I also found something else rather interesting. There is an “o.js” that uses this method in a more advanced way. Have a look at these two Wepawet results here and here. Notice how they use additional variables whilst using the same concept.

So, let’s make our own redirecting JavaScript! The Wepawet examples are from 2009, so this should have good detection, right?  We will conduct various test to ensure that our results are not flawed. Have a quick look at the list:

  1. The Default Approach
  2. Different Variable Names
  3. Additional Variables
  4. Number Obfuscation
  5. String Obfuscation

Before we move on, for those who would like to do this with me, make sure you have your favorite editor open. I myself use Sublime Text. You can download the samples we will be using from my domain here.

 

The Default Approach – VirusTotal (5/46)

Conditional Redirect Test 1

Well now.. I didn’t expect that myself. Maybe 8-14/46 but 5/46? More so they show the same threat name? I’m speechless considering this was the first test..

 

Different Variable Names – VirusTotal (5/46)

Conditional Redirect Test 2

Ok, so everybody can still detect it. That’s a good thing. How about when we add additional variables?

 

Additional Variables – VirusTotal (0/46)

Conditional Redirect Test 3

And just like that, nobody detects. Seriously, WTF? This kind of simple variable trick passes? In my opinion, more should’ve detected it then the first time, considering it explicitly passes “document” into another variable to be called with with window.

 

Number Obfuscation – VirusTotal (0/46)

Conditional Redirect Test 4

None detect this simple obfuscation method? No, just no… The document.location was left in place and obfuscation was added. I expected more to detect this..

 

String Obfuscation – VirusTotal (0/46)

Conditional Redirect Test 5

Err… how does this miss? ._.

 

We can conclude that the AV industry uses a simple method for checking this kind of exploit. It would look something like this:

When a variable (Var A) is defined,
And another variable (Var B) is set to Var A,
With a conditional between each (Var A and Var B),
And an expression utilizing document.location,
That contains a string (not a variable) with a passed URL,
Then alert and mark as malicious.

Follow the discussion on the avast! forums,

~!Donovan

Advertisements

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

Searching For Exploit Kits

A unique trick to searching Exploit Kits on Google is to use the following query: “* exploit kit.zip”.

This searches for all websites with the content of (any characters) exploit kit.zip, not case sensitive. This search provides the best results. For a more specific, yet less knowledgeable result, replace the star (*) with the name of the exploit kit you wish to download. For example: “Crimeware exploit kit.zip”.

Keep hunting,
~!Donovan

Yesterday, Polonus addressed the issue on the avast! forums. Let’s check out the inform.htm.

First, review the VirusTotal results.

The malicious code is as follows:

inform.htm

As you can see, no obfuscation. They aren’t trying to hide anything. Maybe they are trying to reduce general AV detection. And the script looks simple enough, with a redirect to this podarunoki(dot)ru site…

Now we will look two at two urlQuery references: here and here.

Both of these sites, including the one given in the picture above, lead to .ru domains with :8080.

You can check for new malicious inform.htm sites on CleanMX,
~!Donovan

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