Cerbero Blog – Page 25

Microsoft Authenticode

Based on RSA’s PKCS7 standard, Authenticode is the technology developed by Microsoft to digitally certify programs and drivers on Windows. Trusted signatures guarantee that the certificate owner is indeed the author of the signed executable, and also that the data itself has not been tampered with by anyone else.

In a default configuration scenario, the operating system considers these signatures during all but three events:

When kernel-mode drivers are loaded
When executable images that derive directly from content downloaded using Internet Explorer (or any other third-party browser which supports it) are written to disk.
When an application requires admin privileges.

Point two is a weak security measure for the following reasons:

Even if the right browser is used, there’s still no guarantee that the verification request (because it is by no means mandatory) is honored by the operating system unless the UAC privilege elevation dialog is invoked (either via manifest or using the “Run as Administrator” menu item). It’s important to note that if the Authenticode signature can’t be verified, the dialog being shown to the user is the same as the one for unsigned executables. At this point, there is no way to distinguish from unsigned (no code signature) and untrusted programs (invalid code signature) using the UAC dialog alone.
Once an application has been authorized by a user and his certificate store, no checks are performed when it is moved to another system (even if the new certificate store can’t validate the Authenticode signature)
The whole mechanism heavily relies on the file system being used; copying unauthorized files to a non-NTFS file system (which happens quite a lot, considering the vast majority of USB drives are using FAT32) doesn’t preserve the alternate data streams created by browser.

Also the verification is not self evident if done manually using Windows Explorer, as the properties dialog doesn’t show the validity of the certificate until the user clicks the “Details” button. This is highly misleading, because the user might get a false sense of security by just checking whether the executable contains a digital signature.

Windows certificate dialog

The upcoming version 0.8.6 of the Profiler introduces support for this technology, allowing users to very quickly access and verify code signing information.

The following screenshot shows a perfectly valid digital signature; all the certificates taken from the Authenticode data have been successfully used to build a trust chain that validates the PKCS7 using the system store, which means that those at the root of the tree have been directly validated by the Windows Certificate Store.

As you can see, the risk factor is set to zero, since the validity of the publisher has been determined. This behavior can be changed from the Risk panel of the options: it is not on by default!

For comparison, the following screenshot shows how an invalid digital certificate is displayed:

In this case the hash is no longer what expected, issuing both a digest and an invalid certificate errors.
Countersignatures are of course supported and I think you’ll be pleased with how fast our implementation is.

Additional resources:

Validation of Portable Executable resources

One of the new features of the upcoming 0.8.6 version of the Profiler is the validation of resources. This means the Profiler verifies the integrity of resources and lets the user inspect problems, making it easy to discover things like appended files or fake resources. This feature comes handy since very often malware is hidden in resources and droppers often use resources to store their payload.

All the most important resource types are supported:

Version info
Bitmaps
Icons
Cursors
Icon groups
Cursor groups
Configuration files
Accelerators
Menus
Dialogs
String tables
Message tables
Any other supported file format

So let’s see a simple test case. What I did is to append a DLL to a bitmap and then replace one of the bitmaps in explorer.exe with my modified one.

I could’ve used any other resource type, or even a PNG or GIF, it wouldn’t have mattered.

The simplified resource tree highlights problems with their risk color, while unsupported types are highlighted in gray.

One can jump to problems with the F2 shortcut, no need to scroll the tree ourselves in search of problems.

In the screenshot above the analysis shown is for my fake bitmap. As it’s possible to see, the bitmap ends where the red-marked data begins.

In this context it is very easy to just load the embedded PE with the “Load as…” (Ctrl+W) command.

And this gives me the opportunity to mention briefly another nice improvement to the hierarchy view.

As you can see files are now grouped according to their type. This makes it much easier to go over the files or to look for specific types. This behavior is optional and can be changed from the settings.

I think I could’ve presented this new feature with a more interesting real-world case. However, there are still some things to do in order for the new version to come out and there wasn’t enough time. I hope, nevertheless, that you enjoyed the post. 🙂

News for version 0.8.5

Since there are many improvements and additions, here’s a list with the most important ones:

– finished support for Portable Executable directories (.NET excluded): Delay Import, Bound Import, Exception (x64, IA64), Security
– improved detection of files in MSI archives
– replaced the native scan table with the custom table control: now it’s fast and efficient
– added threat highlighting and jump in scan table and hierarchy view
– increased the UI responsiveness during batch scans
– introduced option to disable intrinsic risk factors
– added search functionality to every control which lacked it
– added support for PNG and APNG files
– added support for GIF files
– improved PE Debug directory view
– added language switch in text view
– improved file format choose dialog
– improved initialization performance by delay-loading some modules
– updated OpenSSL

This version prepares the ground for the next .6 version, which as I expect will be very interesting. However, even in 0.8.5 there are many useful new things, so in this post I’ll just do a tour of those which might need an explanation.

Threat highlighting

This means that files with a risk factor > 0 are now highlighted with different gradients of orange (low risk) and red (high risk). This is true for the new file system scan results table, which by the way is now blazingly fast.

Scan threat highlighting

But also for the file hierarchy itself.

Hierarchy threat highlighting

It’s possible to jump to files with risk factor > _customizable_threshold_limit_ with F2 (next) and Shift+F2 (previous).

Disable intrinsic risk factors

It’s pretty clear that an executable can contain native code, right? It’s expected to, just as a font file is expected to contain its specific bytecode. These characteristics are intrinsic to these file formats and as users we might not desire to be alarmed by that.

Disable intrinsic risk

By enabling this new handy option, these factors will no longer contribute to calculate the risk of a file.

PE directories

Apart from .NET, all Portable Executable directories are now supported. Specifically, support for the following directories has been added: Delay Import, Bound Import, Exception (x64, IA64) and Security.

Security Directory

This month we will post about some new interesting features and the PE analysis series will be continued. 🙂

PE analysis (part 1)

This is the first of a series of posts which will be dedicated to PE analysis features. In previous posts we have seen how the Profiler has started supporting PE as a format and while it still lacks support for a few directories (and .NET), it supports enough of them for x86 PE analysis.

While the upcoming version 0.8.4 of the Profiler also features analysis checks as CRC, recursion, metadata, etc., this post will be about the in-depth range analysis for PE files. As the screenshot above previews, in-depth ranges show PE data structures in a hex view and the distribution of data in a PE file.

Let’s take as first sample “kernel32.dll”. After having it opened in the Profiler, let’s execute the “PE->Display ranges” action.

PE ranges action

We get the PE ranges for kernel32.

The big region of data marked as fluorescent green represents executable code. As you can see, it is interrupted by a gray region of data which the tooltip tells us being a combination of “Code” and “Export Name Data”. If we move the cursor, we can see that it’s not only Export data, but also Import data. Which means that the Export and Import directory are contained in the executable part of the file (the IAT is in the thin gray area at the beginning of the code section). But we may not be interested in having the code section covering other data regions. This is why we can filter what we want to see (Ctrl+B).

PE ranges filter

I unmarked the “Code” range. Thus, we now get all the ranges except the unmarked one.

We can also jump to regions of data, but before seeing that, I want to briefly mention that the hex view can be printed to file/PDF or captured.

Hex View caputre

Not a big feature, but it may come handy when generating reports.

Now let’s look at a file I have especially crafted for the occasion, although it reflects a very common real-world case.

We’ve got a PE with an extremely high quantity (50%) of foreign data and the entropy level of that data is also extremely high.

So let’s jump to the first occurrence of foreign data (Ctrl+J).

Ranges jump

What we see is that right there where the analyzed PE files finishes, another one has been appended.

Appended PE

So let’s select the contiguous range of data (Ctrl+Alt+A: this will select the foreign range of data) and “Load selection as…” (Ctrl+E) will asks us to select the file type to load (it is automatically identified as being a PE).

Load appended PE

We are now able to analyze the embedded PE file.

Loaded appended PE

While this procedure doesn’t highlight anything new, since loading of embedded files has been featured by the Profiler from its earliest versions, I wanted to show a practical use of it in connection with ranges.

It has to be noted that this particular case is so simple that it can be detected automatically without interaction of the user. In fact, detection of appended files in PEs will be added most probably in version 0.8.5.

Hope you enjoyed this post and stay tuned for the next parts!

PS: take advantage of our promotional offer in time. Prices will be updated in August!

ActionScript2 Disassembler

While a disassembler for ActionScript3 has been featured by the earliest versions of the Profiler, it was still missing one for ActionScript2. This has changed in the upcoming 0.8.4 version and thus largely extending the support for the Flash file format.

The main goal I had during the development of this component was to represent the input file as close as possible in the output. To achieve this, the resulting disasm contains offsets, sizes, and also warnings and errors in case wrong values are detected.

Sorry for making this post so short, but there’s still a lot to do for the upcoming release!

Resource & Load Config Directory

The upcoming 0.8.3 version of the Profiler features two new directories. Most of the work went into implementing an efficient model view controller for the Resource Directory tree.

Resource Directory

Last year I was notified by Ange Albertini that his resourceloop.exe sample crashed the CFF Explorer (by exhausting the stack). Recursion is one of the things to look after when parsing a file as mentioned in my speech about the security of non-executable files. The screenshot below shows Ange’s sample in the Profiler.

Recursive Resource Directory

The red marked Resource Directory Entry points back to the top-level Resource Directory and thus creates a recursion in the tree.

The Profiler is intended to offer complete support for the PE file format, this is why all directories will be supported. One of the directories missing in the CFF Explorer, for instance, is the Load Config (alias SafeSEH).

Load Config Directory

Another small addition is the smart address converter (VA/RVA/Offset). This action guesses the address which needs to be converted from the context. Jumping to a location in the hex view is usually a matter of Ctrl+R and twice Ctrl+Enter.

Address converter

Five directories are still missing: Security, Exception, Bound Import, Delay Import and .NET. The analysis of x86 PEs can already be implemented by adding basic support for the Security Directory. x64 needs Exception as well. Bound and Delay Import support will follow. .NET is the one which has least priority, but it won’t take much time to impelement.

The coming posts about Portable Executable will involve analysis and will be more interesting than this one. So stay tuned. 😉

Profiler 0.8.2 Demo

The first evaluation version of the Profiler is available.
SHA1: F1CA1B8B1BAE51977EE0BE827DC13E2E17BD81A3

Please note that the demo is subject to limitations:

only standard .doc files are supported (not even other Office file types)
embedded and referenced files can’t be inspected
only single file analysis is available
although the action system is working, some actions are not available

But now let’s see what features it does offer.

The file report and the hex view along with marked ranges.

Demo 1

The extraction of metadata.

Demo 2

The extraction of VBA code is also available.

Demo 3

And, of course, the inspection of the CFBF file format itself.

Demo 4

Other common features are also available. Enjoy!

Portable Executable: coming soon

In the upcoming 0.8.1 release of the Profiler initial support for PE files has been introduced. 🙂

Most of the work went into optimizing the UI and allowing for complex custom views to be built easily, while maintaining great speed. Even the grid control you can see here displayed is a custom control.

In the following screenshot you can see a complex view displaying the section headers.

And here’s a more basic view for the import directory.

Import Directory

Another eye candy screenshot of the section headers with entropy computation for one section.

Section Entropy

What will be present in this first PE edition is mainly about the file format itself. What is going to be missing is a viewer for the resources and one for the .NET directory, because we need first to implement an efficient and customizable tree control. Also ranges won’t be supported as long as the whole file format isn’t supported. This is due to the fact that the PE is one of the most studied and documented file formats around, hence the necessity to be very precise when calculating data ranges.

Also, soon we’ll release a demo of the Profiler. Stay tuned!

Entropy

The upcoming version 0.8.0 version of the Profiler features computation of entropy and the representation of it through a graphical plot. The algorithm used for the calculation is the one described by Ero Carrera on his blog.

When foreign data is present in a file, its entropy is automatically calculated. This is very important, because foreign data can be completely harmless and entropic analysis hugely helps evaluating the risk factor of it.

Normal PDF foreign entropy

In this case the analyzed PDF contains 0x0A separators between objects and since it contains many objects, there’s also a lot of foreign data. However, since the entropy is extremely low, it is possible to assume that the foreign data doesn’t have a purpose.

Let’s take a look at a malicious PDF with foreign data. As one can see, the entropy is very high in this case.

Malicious PDF foreign entropy

Of course, it’s also possible to calculate the entropy in any hex view of a custom range of bytes and block size through the action Data->Entropy. This is the entropy for an entire malicious PDF with a block size of 256 bytes.

The encrypted malware begins at the position where the entropy raises and remains steady.

In the future the plot control will be exposed to the Python SDK so that plugin writers can use it too.

Enjoy!

Info-Tech Storage Format support

The Info-Tech Storage Format (ITSF) is the primary format that has been adopted by Microsoft for online help files since Windows 98. Due to its popularity, it has been used (and exploited) by many other third parties, mostly because of the support provided by documentation utilities like Doxygen.

With the upcoming 0.8.0 release, the Profiler comes with full compatibility for the following file extensions: CHM, CHI, CHQ, CHW, KPD.

Despite the name (Microsoft Compiled HTML Files), the image above shows the Profiler analyzing a CHM containing not only HTML, but also fonts and PDF documents. These files tend to contain a lot of information, and may require you to increase the unpack limit from the settings.