marco
blog
Menu:
Craigslist malware
July 2, 2010
I've just being targeted by an interesting malware attack on Craigslist. The attack works as follows. I am a legitimate user of Craigslist and I have just posted an announcement to sell an item. A few hours later, I receive an email asking:
u still offer?
I reply back back that the item is still available and again after a few hours I get the following email:
Thank you for getting back to me.
I just want to make sure i am going to buy the same which i am looking for.
I can't afford another mistake as i did in the past.
Please check the video and confirm that it's the same u have.
http://fav-vid.com/playvideo.php?video=jgahnYYNPe0
If its the same one I will be there today to buy it
Thanks
Mmmh, fairly generic message (no reference to the actual item I'm
selling) and a "vid" link... Smells phishy. Just to be sure, I follow
the link and after a few redirects I wind up on
http://favvids.net/playvideo.php?video=jgahnYYNPe0&feature=youtube_gdata&name=my_stuff
The picture above shows a screenshot of this site.
Notice the fake notification bar on the top that resembles the one used
by Internet Explorer. Of course, it turns out that we need a "player",
the FLVDirect Player, to
actually watch the video. Sounds familiar...
If I try to download the player, I am redirected to another site,
www.flvpro.com, which finally sends the binary.
The binary has fairly high detection on
VirusTotal (12/41 at this time).
Another curiosity: if one arrives on the site referenced in the email
with JavaScript disabled and attempts to download the player, he gets
redirected to www.thislinkhasbeendisabled.com, which laconically
announces:
This link has been disabled
It was surely a throw-away address, but as a reference, the original sender on Craigslist was allenekf6dok3z@aim.com.
Stay away from this guy and these sites...
Twitter accept bug
May 12, 2010
If the Twitter accept bug of a couple of days ago really was caused by in-band signaling (and there seems to be few, if any, other reasonable explanations for it), then one has to wonder if we will ever learn from past history.
In-band signaling (mixing control and data on the same communication channel) is famous for being hard to get right and to have caused quite a few security fails in a lot of different domains. Just to list a few well-known cases:
- telephone systems had blue-boxing;
- the C library had format string attacks, essentially because the format argument of
printfand the likes mixes data and control; - Matt Blaze and others found that in-band signaling allows one to evade the presumably secure wiretapping systems used by US law enforcement agencies.
I'll close with the mandatory reference to Bell's corollary:
Those who cannot remember the past are condemned to repeat it
-- George Santayana
Possibly with a handicap
-- Bell
Detection and Analysis of Drive-by-Download Attacks and Malicious JavaScript Code
April 28, 2010
Tomorrow, I'm going to present our paper Detection and Analysis of Drive-by-Download Attacks and Malicious JavaScript Code at the WWW conference. The paper describes some of the techniques that we use to detect and analyze web pages that perform drive-by-download attacks, such as the ones that we analyze via Wepawet.
Here is the abstract:
JavaScript is a browser scripting language that allows developers to create sophisticated client-side interfaces for web applications. However, JavaScript code is also used to carry out attacks against the user's browser and its extensions. These attacks usually result in the download of additional malware that takes complete control of the victim's platform, and are, therefore, called "drive-by downloads." Unfortunately, the dynamic nature of the JavaScript language and its tight integration with the browser make it difficult to detect and block malicious JavaScript code.
This paper presents a novel approach to the detection and analysis of malicious JavaScript code. Our approach combines anomaly detection with emulation to automatically identify malicious JavaScript code and to support its analysis. We developed a system that uses a number of features and machine-learning techniques to establish the characteristics of normal JavaScript code. Then, during detection, the system is able to identify anomalous JavaScript code by emulating its behavior and comparing it to the established profiles. In addition to identifying malicious code, the system is able to support the analysis of obfuscated code and to generate detection signatures for signature-based systems. The system has been made publicly available and has been used by thousands of analysts.
See you in Raleigh!
Malicious PDF trick: multiple filters
February 22, 2010
Another simple trick that is often used by malicious PDF files consists of embedding the malicious JavaScript code in a PDF stream hidden below several stream filters.
Here is an example:
4 0 obj
<<
/Length 2839
/Filter [ /ASCIIHexDecode
/LZWDecode
/ASCII85Decode
/RunLengthDecode
/FlateDecode ]
>>stream
80124E6422E89C7A3517958CC302316CDE
...
08220861102A8595D813C3187E07C40400>
endstream
endobj
The stream's contents are decoded applying the specified 5 filters in
order (ASCIIHexDecode, LZWDecode, ASCII85Decode,
RunLengthDecode, and FlateDecode).
See this Wepawet report to find out what happens after the decoding is done. These malicious PDFs seem to also have decent detection on VirusTotal (6/41, at the time of writing).
Malicious PDF trick: getPageNthWord
February 18, 2010
PDF exploits are becoming more and more sophisticated. In particular, they often rely on creative techniques to avoid detection and slow analysis. For a couple of examples, see Julia Wolf's and Daniel Wesemann's nice analysis of malicious documents that use the getAnnots and info tricks, where the actual malicious content is stored as annotations or as part of the document metadata (e.g., the author name).
Here is another trick that showed up recently. I'll call it the getPageNthWord trick, from the key API function it uses.
The PDF contains a JavaScript section with the following code (simplified a little):
var s = '';
new Function(decode(2, 35))();
function decode(page, xor){
var l = this.getPageNumWords(2);
for(var i = 0; i < l; i++){
word = this.getPageNthWord(page, i);
var c = word.substr(word.length- 2, 2);
var p = unescape("%"+ c).charCodeAt(0);
s += String.fromCharCode(p ^ xor);
}
return s;
}
This code creates an anonymous function, sets its body to the return
value of the decode function, and then executes it.
The interesting part is in the decode function. This function gets the
number of words contained in the third page of the document via the
getPageNumWords function (recall that pages are 0-based in the PDF
API). It then loops through all the words in that page (via the
getPageNthWord function) and manipulates them. Let's see how the third
page looks like:
11 0 obj
<<
/Length 23892
>>
stream
2 J
0.57 w
BT /F2 1.00 Tf ET
0.196 G
BT 31.19 806.15 Td ( kh29 kh2a kh55
...
kh4e kh46 kh0a kh03 kh58 kh2e kh29) Tj ET
...
endstream
endobj
The page is stored as a stream. Its contents comprise a number of
directives and the actual textual content. For example, BT indicates
the beginning of the text and, conversely, ET marks the end of the
text; 31.19 806.15 Td specifies the position of the text on the page;
and Tj is the display text operator. The actual textual content is
the string starting with kh29.
We can now go back to our decode routine. It is clear that it extracts the last
2 characters from each word (e.g., “29” from “kh29”),
interprets them as hex numbers (e.g, 0x29), xors them with 35 (e.g., 0x29 ^ 35
= 10), and finally obtains the corresponding character (e.g., “\n”).
The result of this deobfuscation is the actual exploit code, which targets 4 different vulnerabilities. However, the exploit code has one last trick, which it uses to hide the URL from where the malware is to be downloaded:
var src_table = "abcd...&=%";
var dest_table= "eAFS...=iZR-";
function get_url(){
var str = this.info.author;
var ret = encode_str(str, dest_table, src_table);
return ret;
};
Notice the info.author property. The get_url function essentially
performs a simple substitution decryption of the author metadata. Let's
see what is contained there:
17 0 obj
<<
/Author
(-Jj.gw-Jjrj.-JWMyD-JjTWM-JjngM-JgkjW
...
-JjrWk-Jjrgw-JgTyM-Jy0g.-JWgyg-Jgngw-JgYgY-JyygM-Jy.yC)
>>
endobj
Ugly, indeed. After decoding, one finally gets the malware URL.
Wepawet now handles this type of malicious PDF files. See this report for an example.
