Didier Stevens

Sunday 30 November 2008

Quickpost: Citibank Phishing E-mails

Filed under: Quickpost,Spam — Didier Stevens @ 11:28

On November 23th 2008, the US Government rescued Citigroup by investing an additional $25 billion.

On November 25th 2008, I started to receive Citibank phishing e-mails in my “SPAM-trap”. At the time of writing, the spam campaign is still active and I’ve received 300+ e-mails, like this one:

20081130-105959

This can’t be a coincidence. Although the phishing e-mails don’t mention the financial problems of Citigroup, I’m sure the scammers started this phishing campaign to benefit from the uncertainty surrounding the future of Citigroup.

“I want to be sure that I can get my money out if things start to go really wrong” will be the reaction of many people falling for this scam. The timing and design of this campaign reveals an understanding of the psychology of fear by these scammers. The fear of losing their money due to a Citibank bankruptcy, will blind some people for the signs of a scam. People who would be more suspicious under normal circumstances.

BTW, one particular Citibank phishing e-mail caught my eye. Its subject starts with [PHISHING] and the body starts with a Panda Antivirus warning:

20081130-113325

Pedro Bustamante from Panda security told me that this default message is added by Panda Antivirus 2008 to incoming and outgoing phishing e-mails.

This e-mail was probably send from a botnet member with an installion of Panda Antivirus 2008. As I have only the e-mail and no other info on the botnet member, I can’t analyze why the botnet software isn’t being neutralized by the AV. There can be many reasons.

Many malware uses a brute-force approach to attack AV software. One simple trick I’ve seen many times in malware assembler listings, is enumerating all services and disable those who match an “AV blacklist”. Recent AV products contains many components. It’s likely that in this case, the botnet malware neutralized the AV engine but missed the spam engine.

Anyways, this particular e-mail provided me some WTF entertainment šŸ˜‰ .

Quickpost info

Wednesday 26 November 2008

Update: Restoring Safe Mode with a .REG file, and a Live CD

Filed under: Malware,Update — Didier Stevens @ 19:39

As more malware seems to delete the SafeBoot keys nowadays, and even prevents you from restoring these keys, I’m posting this “Enhanced Fix Safe Mode” procedure. In essence, it’s the same as my first procedure, but to avoid interference by the malware, we will boot from a Live CD and then fix the registry. Booting from a Live CD means that we boot a clean OS from the CD, and thus prevent the malware from running and interfering with our rescue operation. In a nutshell: boot from a Live CD, load the HKLM registry hive and merge the missing SafeBoot keys.

Notice that the configuration of the machine you’re fixing might be different from the one I’m describing. The system directory could be on another drive than C, you could need to fix ControlSet002 in stead of ControlSet001, …
So watch out, and update this procedure according to the configuration of the crippled machine.

And since you’re going to modify a critical system file, make a backup first (at least of the CONFIG directory).

Copy the respective reg file to your C:\ drive (for example SafeBoot-for-Windows-XP-SP2.reg for XP SP2).
Shutdown the PC and start from a Windows Live CD, like the Ultimate Boot CD For Windows.

Start RegEdit:

safeboot-0000

Select HKEY_LOCAL_MACHINE, and load the hive file C:\WINDOWS\system32\config\system (File / Load Hive…):

safeboot-0003

Name the loaded hive FixSafeboot:

safeboot-0004

Open the key HKLM\FixSafeboot\ControlSet### which is lacking the Safeboot key (there could be more than one ControlSet key you want to fix):

safeboot-0005

safeboot-0006

If the SafeBoot key is not missing (or the keys beneath it), you’re either looking in the wrong place or you’re not dealing with a corrupted SafeBoot key (in which case applying this procedure is useless).

If you’re not sure which ControlSet### to fix, take a peek at the value of Current in the Select key:

safeboot-0016

Here the value for Current is 1, so it’s ControlSet001 which will be used when the system boots, and that’s the one we want to fix.

Open C:\SafeBoot-for-Windows-XP-SP2.reg (the one you copied on the C:\ drive) with notepad:

safeboot-0007

safeboot-0008

Perform a search and replace: replace SYSTEM\CurrentControlSet with FixSafeboot\ControlSet### (### being the number of the ControlSet you want to fix, like 001). Save the modified reg file:

safeboot-0009

safeboot-0010

Import the reg file C:\SafeBoot-for-Windows-XP-SP2.reg with regedit (File / Import…):

safeboot-0011

safeboot-0012

Check that the SafeBoot key has been added:

safeboot-0013

Select the FixSafeboot key and unload it (File / Unload Hive…):

safeboot-0014

safeboot-0015

Shutdown the PC and start in Safe Mode (F8).

If you still can’t boot into Safe Mode, you’re either facing another problem than a Safe Mode disabling malware, or the malware operates early in the boot process and interferes with Safe Mode booting. If you suspect malware, try scanning with a Live CD with an anti-virus scanner, like the F-Secure Rescue CD.

Sunday 23 November 2008

Quickpost: WiFi Availability

Filed under: Quickpost,WiFi — Didier Stevens @ 11:01

This new video shows how a WiFi camera can be jammed by another wireless device. I produced it for my last talk at the office, illustrating the concept of availability in secure systems.

A WiFi camera, operating on channel 1, is streaming video. When I switch on an analogue, wireless babycam, you see a strong signal appearing near channel 9 (watch the SPECTRAL VIEW of the Wi-Spy spectrum analyzer, e.g. the window in the upper-left corner). After some time, I switch the babycam to a channel near channel 1 of the WiFi camera. Now the transmission of the babycam jams the transmission of the WiFi camera, and we lose connectivity.

Powering off the babycam restores the WiFi connection.

YouTube, Vimeo and XviD hires.

Quickpost info

Tuesday 18 November 2008

My ISSA / OWASP Talk “Risky PDF”

Filed under: PDF — Didier Stevens @ 18:34

For those of you who attended my ISSA / OWASP talk Risky PDF, thanks for your interesting and challenging questions! Iā€™m very pleased with the feedback I got.

You can download the presentation and demo files here. All my PDF blogpost can be found usingĀ  category PDF.

A recurring remark I received afterward is about claiming not to be a PDF expert, while my presentation (and research) clearly shows otherwise.

I didnā€™t express myself clearly. When I started my presentation by stating that Iā€™m not a PDF expert, I meant that I donā€™t know how to produce a PDF document with a nice layout, a content table, an index, captivating graphics, ā€¦ I donā€™t even know how to use Adobe Professional to create a PDF document with embedded JavaScript. So donā€™t ask me questions about producing ā€œbenignā€ PDF documents, because I donā€™t have a clue.

But I do have build-up expertise in malicious PDF documents. Iā€™ve become an expert in analyzing PDF malware. I know how to create a PDF document with embedded JavaScript from scratch, just using a text editor (and Iā€™ve build tools to automate this). And I can perform a forensic analysis of PDF documents.

My PDF expertise is limited to malicious usage and forensics. Outside of the IT security field, people with my expertise are not considered PDF experts. It wasnā€™t intended as false modesty, I just canā€™t help you troubleshoot ā€œbenignā€ PDFs šŸ˜‰

Monday 10 November 2008

Shoulder Surfing a Malicious PDF Author

Filed under: Forensics,Malware,PDF — Didier Stevens @ 21:32

Ever since I read about the incremental updates feature of the PDF file format, I’ve been patiently waiting for a malicious PDF document with incremental updates to come my way. Thanks to Bojan, that day has finally arrived.

The 2 malicious PDF documents I received (data.pdf and info.pdf) both exploit the same Acrobat JavaScript util.printf vulnerability.

data.pdf is very interesting to me: it’s one PDF file containing 5 incremental updates, essentially bringing us an archeological record of the malware author’s trial-and-error session. So let’s start uncovering what the malware writer has been up to.

Looking at the type of objects inside data.pdf (with my PDF parser), we can see many startxref and xref objects:

20081110-202238

The metadata of data.pdf reveals that the guy (from personal experience, I know that most bad programmers are males šŸ˜‰ ) used Adobe Acrobat 8.1.0 to create this document in the early hours of Thursday November 6th 2008, and that his machine has timezone setting +01:00.

It took 52 minutes 32 seconds to create the first version of data.pdf. This version contains everything to execute a JavaScript script upon opening of the document, but the script to be executed is empty.

44 seconds later, a second version is created, containing this script:

20081110-185852

This script performs a heap spray (the most indented section of function main) of shellcode (contained in variable sccs) and then exploits the util.printf format string bug. This exploit is contained in function main, which should be triggered by app.setTimeOut after 3 seconds. However, the use of setTimeOut in this script is buggy (details can be found in Adobe’s JS API Reference), and main() will never execute.

After 44 seconds, another version is created to try to get this exploit to work. He modified the call to setTimeOut like this:

20081110-185933

This is completely wrong, so after 4 minutes and 12 seconds (probably spend Googling for an answer as to why this doesn’t work), he returns to the previous call, but now hopes that 5 seconds will do better than 3 seconds.

20081110-190004

Of course, it doesn’t. After one minute and a half, he gives up, and modifies the script to execute his exploit without delay:

20081110-190045

I can’t say he’s a sharp programmer or tenacious, but at least, he’s result-driven…

Let’s turn our attention to the second malicious PDF (info.pdf) I received. This file contains no incremental updates, but it’s still interesting because it has the same origin as data.pdf. This file was created at exactly the same time, and contains the same identification (/ID[<DD95D438BE408D4FB12AC2FE7ED5E6C6><14FA8F4917ED8449B59BF6CFA41C39BD>]) as data.pdf. Most PDF applications add a unique ID to the trailer of every PDF document they create. info.pdf was saved a day later (about 37 hours later), and contains the same exploit script as data.pdf, but with an extra layer of JavaScript obfuscation.

Bojan confirmed he was the first to submit these files to Virustotal. I calculated the MD5 hashes for the different versions of data.pdf, but none were submitted to VT, so our guy didn’t use VT for QA.

It was an interesting experience, “spying” on this malware author. Let’s hope they don’t stop using incremental updates, and that some of them will be careless enough to leave personal data hidden in their malicious PDF documents.

data.pdf MD5 1A8E5242F21727959683FA8CC7AA94AD

info.pdf MD5 23F31C83EE658BB5C2635BEFDE56199A

Sunday 9 November 2008

Creating PDF Test-Files

Filed under: My Software,PDF — Didier Stevens @ 12:56

As promised, I’m releasing a couple of my PDF tools as a warm-up to my ISSA Belgium and OWASP Belgium talk.

After having manually created some PDF test-files (just using a text editor), I stepped up to the next level and wrote a quick-and-dirty Python module to generate PDF documents by assembling fundamental PDF elements.

My mPDF.py module contains a class with methods to create headers, indirect objects, stream objects, trailers and XREFs. One of the programs I wrote based on this module is make-pdf-javascript.py. This Python program allows me to create a simple PDF document with embedded JavaScript that will execute upon opening of the PDF document. Program details and download here.

An example: to create a PDF document exploiting the util.printf Adobe Reader vulnerability in its simplest form (e.g. no shellcode and no heap spray), issue the following command:

20081109-121930

Here it crashes Adobe Reader 8.1.2 on Windows XP SP2:

20081109-130302

Picture Puzzle

Filed under: Puzzle — Didier Stevens @ 7:41

As I announced via Twitter, here’s a new puzzle. Find the message I’ve hidden in this picture.

First one to post a comment with the correct answer can get a sticker. For those who don’t know, comments are moderated.

Monday 3 November 2008

Quickpost: Remember FireOx?

Filed under: Hacking,Quickpost — Didier Stevens @ 17:05

Remember FireOx?

This time, I tested my Excel scripts on a CommNet machine, here at TechEd Barcelona. Worked without problem.

Saturday 1 November 2008

Quickpost: “An Old IE Trick” Revisited

Filed under: Malware,Quickpost — Didier Stevens @ 22:30

One year ago I blogged about an old IE trick still being used by malware. What can be said now that I resubmitted my test files to Virustotal (VT)? Not much, because VT is not an anti-virus test tool (it’s a virus test tool).

More AV products detect my test files now; and test files with longer zero byte sequences, that weren’t detected a year ago, are getting detected now. So I’m not really going out on a limb here when I say that the detection has improved. But there’s no way to quantify this improvement with VT results alone.

My test file with 255 contiguous zero bytes, which wasn’t detected by VT one year ago, is being detected by 6 AV products now. But it must be clear that I can’t conclude from this that only 6 AV products have been improved in the past year.

First of all, we can’t know if all AV products that have been improved in the past year, have been upgraded on the VT site. It’s very likely that some new engines have not been installed on VT yet.

Second, this improvement might not come to expression on VT. VT uses command-line scanners, and many AV protection features are not present in the command-line versions.

Third, the improved detection could just be the result of new signatures for the very same test files I submitted. Just out of curiosity, I created a new file with 543 contiguous zero bytes. It gets detected by some AV products.

If you’re interested in the detailed detections, here are the links to the VT results:

Quickpost info

Quickpost: Fingerprinting PDF Files

Filed under: Malware,PDF,Quickpost — Didier Stevens @ 11:57

Per request, a more detailed post on how I use my pdf-parser stats option.

I have two malicious PDF files with a different title, different size (100K and 700K) and different content. But they share an identical internal PDF structure, because they have exactly the same number and type of fundamental elements:

These statistics were generated with the following command:

pdf-parser.py --stats malware.pdf

As both malicious PDF files produce identical stats (or fingerprint), I can assume they share the same origin.

Quickpost info

Blog at WordPress.com.