Didier Stevens

Tuesday 13 August 2013

A Bit More Than A Signature

Filed under: Encryption,Forensics,Hacking,My Software — Didier Stevens @ 19:07

Soon I’ll release new versions of my Authenticode Tools.

Detecting extra data in the signature field is one of the new features. For example, it will analyze the size specified in the optional header data directory for security, the size specified in the WIN_CERTIFICATE structure and the size specified in the PKCS7 signature itself. These should be the same, taking into account some zero-byte padding.

In case you didn’t know: extra data can be added in the data directory that contains the signature, without invalidating the signature. My Disitool can do this.

With this new version of AnalyzePESig, I found some setup programs that contain extra data after the signature; data that seems to contain installation options for the installer. For example, the Google Chrome installer has this:

20130813-205011

As you can see, the size specified in the optional header data directory for security and the size specified in the WIN_CERTIFICATE structure are both 6272 bytes, but the size of the PKCS7 signature is 6079. So that leaves 181 extra bytes. You can see them here:

20130813-205744

And I found some other installers with extra data (config data or license information) in the signature directory: GotoMyPc, PowerGrep, RegexBuddy.

Sunday 4 August 2013

Quickpost: Rovnix PCAP

Filed under: Forensics,Malware,Networking,Quickpost — Didier Stevens @ 21:04

Microsoft’s Malware Protection Center has a blogpost on a version of Rovnix that uses its own TCP/IP stack.

I used Wireshark to capture the network traffic generated by this sample when it is executed in a VMware guest.

20130804-225716

I ran the sample on a XP SP3 guest machine in VMware. The hostname is XPPROSP3 (this name will appear in the HTTP GET request).
The guest uses NAT.
I ran the Wireshark capture on my host machine on the VMware Virtual Ethernet Adapter.
I removed some traffic coming from my host machine (NetBIOS Name Service and DHCPv6 to be precise).

When I executed the sample on XPPROSP3, it rebooted after a few seconds.

The trace:
The 37 second gap between packet 6 and 7 is due to the reboot of XPPROSP3
Packet 44: DNS request for youtubeflashserver
There are 3 HTTP requests. Notice User-Agent FWVersionTestAgent in all 3 GET requests.
Packet 50: first GET request with hostname XPPROSP3 as a parameter. Response: 404
Packet 61: second GET request, malformed. Response: 400
Packet 70: third GET request, malformed. Response: 400

rovnix-capture-filtered.zip (https)
MD5: C941D1716B6248C3FBFB4DFFA8AD2E86
SHA256: 51EDA61199DD9EDC1E50C5A9B5A4B69F32DB74E90CF098849554C56217D06EFD


Quickpost info


Monday 29 July 2013

OHM2013

Filed under: Announcement — Didier Stevens @ 0:00

I’m attending OHM2013. To mark the occasion of this outdoor hacker conference taking place every 2 years, I’m doing a 20% promo on my workshop videos.

In case you missed it, I posted this during the weekend: MSI: The Case Of The Invalid Signature.

Friday 26 July 2013

MSI: The Case Of The Invalid Signature

Filed under: Forensics,Malware,Windows 7 — Didier Stevens @ 22:01

I found a suspicious file on a Windows XP machine. I was able to trace its origin back to a Windows Installer package (.msi). This package in c:\windows\installer had an invalid digital signature. Like this:

20130726-233848

Very suspicious.

A bit later I found another msi package containing the same suspicious file. But this time, the package had a valid digital signature. What’s going on?

After a deep dive into the internals of msi packages, I found the answer.

When an msi package is installed, it is cached inside the Windows Installer directory (%windir%\Installer). Prior to Windows Installer 5.0 (released with Windows 7), cached packages were stripped of their embedded cab files. But with digitally signed msi files, the signature remained inside the file: the digitally signed file was modified, hence the signature was invalidated. This behavior changed with Windows Installer 5.0: cached packages are no longer stripped, hence the signature remains valid.

This blogpost by Heath Stewart explains this change in more detail. Unfortunately, my Google-skills were not good enough to find this blogpost prior to my deep dive into msi files. Hindsight Googling FTW! ;-)

Thursday 25 July 2013

Update: Lookup Tools

Filed under: My Software,Networking,Update — Didier Stevens @ 20:11

It looks like I didn’t release this update to my lookup tools.

lookup-hosts.py has a new argument: -R. This does a reverse lookup of the IP addresses (thus after it resolved the hostname).

20130725-220124

And now you can also use letters as a counter: test-[a-z].com

lookup-tools_V0_0_2.zip (https)
MD5: 310904722F900FA34C567FC38634124E
SHA256: 85626574A99BF4D2AB786D8C2FF5B8F6649F1FC7410F1786A24EF0201AAF64AA

Thursday 18 July 2013

Update: js-unicode-unescape.1sc

Filed under: 010 Editor,My Software,Update — Didier Stevens @ 18:36

Because I had to use a workaround in my js-unicode-unescape.1sc script to copy an array of bytes to the clipboard, I asked the 010 Editor developers if they could add a function that does exactly this.

They included this new function, CopyBytesToClipboard, in their new version 5.0.

Here is a new version that uses this function:
js-unicode-unescape_v0_0_2.zip (https)
MD5: 6200C4F235CA527E8C0DCD5076CB1C09
SHA256: 2CACC9EE1BB1D1BC4C9FABC6EC3B3440CFF304AA560966B0B531279C369549BB

Wednesday 10 July 2013

The Art Of Defuzzing

Filed under: My Software — Didier Stevens @ 21:05

I had something of a puzzle to solve. A friend asked me to look at a set of files, all of the same size, but with some differences.

After some analysis, it dawned on me that these files were the result of a simple fuzzer applied to a single file. So I quickly wrote a program that took these files as input and reconstituted the original file. Later I wrote a more generic defuzzer. Here is an example:

defuzzer.py result.png a*.png

Number of defuzzed bytes: 171
Number of defuzzed sequences: 33
Length of shortest defuzzed sequence: 1
Length of longest defuzzed sequence: 10
Fuzz bytes:
'A': 171

From the result you can see that the program was able to reconstitute the original file, and that the fuzzer that was used to produce the different a*.png files, overwrote 33 byte-sequences with the character A. The longest sequence was 10 bytes long, the shortest only 1 byte. In total, 171 bytes were overwritten.

defuzzer_v0_0_2.zip (https)
MD5: 75188EF950625B78937C3473D825C582
SHA256: 056AB8BA7F3B2B52F8C7BFC2959D7F1AE3FEAC4BE90C675B2DFF6B521225D93E

Wednesday 3 July 2013

Update: virustotal-search.py

Filed under: My Software,Update — Didier Stevens @ 20:09

Mark Woan reported an issue with virustotal-search.py: sometimes VirusTotal returns a JSON object that the json parser can’t parse.

That’s something I didn’t expect. I’ve added error handling for this case.

virustotal-search_V0_0_9.zip (https)
MD5: FECD02796889CDFE9FA67287F2DE567C
SHA256: 0CE06CBAFC6341835EB8A62377F5C4EB067747EE28E7ED8BB25FD69A4B99FA97

Monday 24 June 2013

shellcode2vba

Filed under: Hacking,My Software,Shellcode — Didier Stevens @ 4:00

This update adds x64 shellcode support to my shellcode2vbs.py script.

shellcode2vba_v0_3.zip (https)
MD5: 44AF2685975346F9DE09E48E7FB855CE
SHA256: 04C42FA26717CCC7BC17A7BEDA02C746CA1A8BC8C6CE184670CD686796B5FF10

Monday 10 June 2013

PDFiD: False Positives

Filed under: My Software,PDF — Didier Stevens @ 8:48

I’m giving a 2-day training on PDF at Brucon 2013. Early-bird price applies til June 15th.

Sometimes PDFiD will give you false positives for /JS and /AA. This happens with files of a couple of MBs or bigger, because it’s statistically very likely that /AA or /JS (only three bytes long) appear inside a stream. And since PDFiD, contrary to pdf-parser, has no notion of pdf objects and streams, it can produce false positives, like this:

PDFiD 0.1.2 CCNPSecurityFIREWALL642617OfficialCertGuide.pdf
 PDF Header: %PDF-1.6
 obj                 6018
 endobj              6017
 stream              1897
 endstream           1897
 xref                   1
 trailer                1
 startxref              1
 /Page                773
 /Encrypt               1
 /ObjStm                0
 /JS                    3
 /JavaScript            0
 /AA                    1
 /OpenAction            0
 /AcroForm              0
 /JBIG2Decode           0
 /RichMedia             0
 /Launch                0
 /EmbeddedFile          0
 /XFA                   0
 /Colors > 2^24         0

And when you search for /AA or /JS with pdf-parser, you will not find objects that have /AA or /JS in their dictionary:

pdf-parser.py -s /AA CCNPSecurityFIREWALL642617OfficialCertGuide.pdf

Up til now, I advised users suspecting false positives, to search the PDF document with a hex editor and see if they found /AA or /JS inside a stream. But now, with the latest version of pdf-parser supporting searching inside a stream, you can do it like this:

pdf-parser.py --searchstream /AA --unfiltered CCNPSecurityFIREWALL642617OfficialCertGuide.pdf
obj 1848 0
 Type: /XObject
 Referencing: 38 0 R
 Contains stream

  <<
     /Length 121194
     /Filter /DCTDecode
     /Width 800
     /Height 600
     /BitsPerComponent 8
     /ColorSpace 38 0 R
     /Intent /RelativeColorimetric
     /Type /XObject
     /Subtype /Image
  >>
« Previous PageNext Page »

The Rubric Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 198 other followers