MSI support

Even though CAB file support is still under development, the CFBF parser already lets us inspect Windows Installer packages and patches.

MSI streams

Having such feature comes in handy when you want to analyse their contents, and eliminates the need for external tools.

In the screenshot above, I’ve selected one of the DLLs that link to MSI custom actions, i.e. code that is potentially executed as soon as Windows Installer opens the package.

Data type quotas

While it is already possible to inspect data ranges through the hex view and its bar on the left, now there’s a new view to express the type data quotas. This is useful in order to understand at first sight how much of a file is actually part of the format, how much is custom data and how much is foreign or unreferenced data.

Data quotas pie

Also, from the options it is possible to fine tune at which point foreign data should be reported as a security problem. The amount can be expressed either in percentage and/or size.

Foreign quota limit

The security of non-exec files

This article is based on a speech I gave couple of months ago at DeepSec. I wrote it during the summer, which means I would now expand on some of the paragraphs. Nonetheless, I hope you’ll enjoy the read.

Introduction

As we know there’s has been a huge increase of malware attacks carried out with files other than executable ones. I’m aware that this is a very generic definition. If we consider a PDF with JavaScript stored inside, would you call it an executable? Probably you wouldn’t, although the script might be executed. Even saying that an executable can only be a file which contains native machine code isn’t accurate. A .NET assembly which contains only managed code would still be considered an executable. But a Shockwave Flash file (with its SWF extension) may not be regarded as standing in the same category. Of course, a Shockwave Flash file is not the same thing as a .NET assembly, but they both contain byte code which at some point is converted into machine code and is executed.

This means that the barriers between executable and non-executable files are thin and in many cases there’s a problem of perception, hence the difficulty of giving this article a completely accurate title. A more appropriate one would have been: the security of all those files generally perceived as harmless or, at least, less dangerous than applications. You may guess why I opted for the other title.

Does this look infected? (no, I’m talking about the file)

This is the most feared issue. How can a non-exec file infect a system? Basically through:

  • Scripting or byte code
  • Shellcode (buffer overflows)
  • Dangerous format features

These vectors are the most common for infection.

Scripting and byte code (security α 1/functionality)

Many file types offer the capability to execute code. However, a distinction has to be drawn between those file formats which offer it just as an additional feature and those formats which completely rely on it.

Shockwave Flash has been a very popular infection vector thanks to its powerful byte code. While it may be apparent even to an unskilled user that a Flash game on the internet is a sort of application, it’s not as apparent under other circumstances.

Very often playing a video in a web browser involves Flash. And I’ve heard many users referring to this as “Flash videos”. They don’t know that what actually happens is that a Flash file is downloaded and its ActionScript code executed.

Download the PDF to continue the reading.

Automatic hierarchical profiling

One of the technical priorities of the Cerbero Profiler is to automatically analyze files embedded in the main file being profiled. Not only that, it automatically analyzes files embedded into embedded files as well, and so on, going completely through the embedding hierarchy.

This is necessary, because otherwise it is not possible to fully evaluate the threats and privacy issues which a file contains. To demonstrate this feature, I’ve built a silly Shockwave Flash file with a multiple level embedding hierarchy.

Stay tuned, there’s more to come.