In the upcoming 0.8.0 version of the Profiler it will be possible to print out the matches of PDF object searches. This comes very handy during analysis if we want to know, for instance, all values for a given key. The option can be activated in the initial configuration dialog.
In this case we’re going to search for URI keys (which specify links).
URI search has also been added as a predefined search.
While the Profiler was designed for document analysis and currently has virtual memory limitations, let’s see how it performs with a Zip bomb. 🙂
A friend of mine linked me the Zip file on this page.
The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.
That’s 16^5 or 1048576 files. If we try to scan it with the Profiler, it will just take endless time trying to scan all the files. It won’t crash nor exhaust memory, just take ages. But we want to analyze the file right now, so how do we do it?
It’s very easy. By default the Profiler has quite a huge nesting limit (10), we can decrease that limit from the Setup -> Limits page. The nesting limit tells the Profiler at which depth of embedding/referencing the scan should stop.
In this case I have decreased it to 1, but 2 or 3 would still have been reasonable. A value of 1 means that only files at the first level will be analyzed. By inserting a value of 0, the file will be opened without any scanning of sub-files.
But what if we want to analyze more in depth one or more branches in the hiearchy? The nesting limit applies only to automatic analyzes, not to manual ones, which means that we can activate items and get the analysis for them (and their children).
As you can see, we’re now analyzing the Zip bomb at the fourth level of nesting. 🙂
The upcoming version 0.7.9 of the Profiler features support for the still to be publicly released PDF symmetric encryption revision 6. While the PDF specifications are not yet freely available, Adobe has already started supporting the new standard.
This is part of our effort of keeping the product up-to-date with the latest standards.
Among other additions, the new 0.7.8 version of the Profiler features support for Zip archives and an improved interface for displaying the file hierarchy.
The supported decompression methods are Deflate and BZIP2 (more will be added). All popular encryption technologies are supported: ZipCrypto and WinZip AES. Support for the undocumented and proprietary PKWare encryption technology is still missing.
One of the handy UI improvements is the in depth risk report.
In this case the global risk signals that the calculated risk is 45% but could be more because some files could not be analyzed, since their format is not supported. This risk reporting is available both for the global risk and individual files.
In this case the main file “nested_crypto.zip” was decrypted but the decryption of the embedded file “test.zip” failed, because I didn’t enter the password for it. We can see that “test.zip” has not been decrypted (nor the files it contains) because of the e character next to the risk percentage. The meaning of these kind of characters is explained by the tooltip.
The Zip format covers an enourmous amount of extensions and hugely increases the usefulness of the Profiler. Enjoy! 😉
MicroType Express is the (optional) compression technology used by Embedded OpenType fonts. It was specifically designed to compress TrueType fonts. These fonts are generally to be found in web pages or Office documents.
In this screenshot we have Internet Explorer displaying fonts download from remote. It is very easy to embed fonts in a web page.
@font-face {
font-family: Piefont;
font-style: normal;
font-weight: normal;
src: url(PIE0.eot);
}
@font-face {
font-family: GS;
font-style: normal;
font-weight: normal;
src: url(GOUDYST2.eot);
}
@font-face {
font-family: Garabold;
font-style: normal;
font-weight: 700;
src: url(GARAMON5.eot);
}
@font-face {
font-family: Garanorm;
font-style: normal;
font-weight: normal;
src: url(GARAMON4.eot);
}
@font-face {
font-family: Script;
font-style: normal;
font-weight: normal;
src: url(SCRIPTM2.eot);
}
What happens when Internet Explorer tries to open EOT fonts is that it loads T2Embed.dll from the System32 directory.
The job of this DLL is to convert EOT fonts back to the original OpenType format which is then parsed and displayed. Thus, EOT fonts are subject to exploits either in their MicroType Express layer or in the resulting OpenType font. In fact, lzcomp, the custom compression algorithm based on lz77 used by MicroType Express, has been exploited as a vector for remote code execution. It should be noted that the vulnerability has been reported in 2010 and the W3 submission by Microsoft of the MicroType Express standard is dated 2008. The lzcomp decompression code contained in the W3 submission does not include the patches introduced after the vulnerability was reported (I checked). So while probably few will use the code anyway, they should be careful to add safety checks in order to not include the above mentioned vulnerability in their own code.
While already with version 0.7.6 the Profiler had support for uncompressed Embedded OpenType fonts, only with the upcoming 0.7.7 version a partial support for MicroType Express has been added. I say partial because, although the embedded OpenType font gets completely decompressed, only the glyf and loca tables out of those which are deconstructed are rebuilded in order to allow the disassembling of bytecode. Tables which are not yet rebuilded are: cvt, hdmx and VDMX. The use of the T2Embed.dll for conversion was not an option, since it doesn’t fit with the Profiler safety standards.
This is a Word Document containing Embedded OpenType fonts.:)
The Compact Font Format (CFont) was developed by Adobe and it is a container for one or more fonts. Although not compressed, it’s a format designed to save space as the name suggests.
The bytecode contained in CFonts is either Type1 or Type2, both very similar and supported by the Profiler, although nothing prevents from storing another type of bytecode.
The support of this font format also improves the support for OpenType fonts, because these fonts can store glyph outlines in a CFF table, rather than in a glyf table such as TrueType fonts. CFF tables contain Compact Fonts.
In this last screenshot we can see an example of font detection inside of a PDF.
This font format is very common and mainly found in PDFs. It was used as a vector for native code exeuction in the iOS 4.3 jailbreak. To trigger the vulnerability it was sufficient to open a PDF inside Safari.
In the screenshot we can see the disassembled code and more precisely the first line of the exploit (a call with a negative number of arguments). As I wrote in this paper and discussed at DeepSec 2011, there are some interesting parts in the Adobe specification of the format. One part explains the reason for Type1 fonts to contain bytecode.
Since Type 1 fonts are expressed as computer programs, they are copyrightable as is any other computer software. For some time, the copyright status of some types of typeface software was unclear, since typeface designs are not copyrightable in the United States. Because Type 1 fonts are computer programs rather than mere data depicting a typeface, they are clearly copyrightable. A copyright on a Type 1 font program confers the same protection against unauthorized copying that other copyrightable works, including computer software, enjoy.
This is important, not only because it tells a great deal about priorities during development (copyright vs security), but also because Type1 is one of the oldest font formats and as such it sets a trend. In fact, the price of the license granted by Adobe to implement such fonts was so high that in 1991 Apple created their own font type (TrueType).
The other part of the specification says something about the security of the parser.
Because Type 1 font programs were originally produced and were carefully checked only within Adobe Systems, Type 1 BuildChar was designed with the expectation that only error-free Type 1 font programs would be presented to it. Consequently, Type 1 BuildChar does not protect itself against data inconsistencies and other problems.
In the upcoming 0.7.6 release of the Profiler a great effort has been invested into supporting font formats. After SFonts (TrueType and collections) released with 0.7.5, the first font formats I’m going to present are WOFFs and EOTs. Both this font formats are actually containers for SFonts and they are used to deploy fonts on the web and are therefore usually compressed.
The Web Open Font Format (WOFF) is quite easy as format and certainly the more secure and logical of the two.
Being containers for SFonts, the Profiler contains a converter to SFont, which gives the ability to analyze the compressed font.
Same applies to Embedded OpenType fonts which is a format created by Microsoft.
These fonts are not only deployed on the web but can be found in Office documents as well. Unfortunately the Profiler doesn’t yet support compressed Embedded OpenType fonts. The compression happens in stages and uses a custom compression algorithm created by Microsoft and based on lz77 called lzcomp. This algorithm has been used as an exploit vector for remote code execution.
We’re happy to announce that the new 0.7.5 version of the Profiler offers support for TrueType (SFNT) fonts. This is the first step in the direction of giving our users a complete solution for font formats and analyze them inside documents. The recent threat landscape has seen the rise of fonts as an infection vector. Two notable examples are Duqu and the iOS 4.3 jailbreak.
In the screenshot above we see several TrueType fonts being analyzed inside of a PDF document.
One of the offered features is the capability to output the code contained in a TrueType font. While this feature can’t be used to establish the risk factor of a font at glance, it is useful to security analysts.
Functions are associated with their glyph name, in order to more easily establish which instructions are associated to a particular character.
The report also shows the metadata, which doesn’t offer any kind of security assurance, but might be of interest to the user.
As with every file type supported by the Profiler it is possible to inspect the format of TrueType and TrueType Collections fonts as well.
The screenshot above shows the format of a TrueType collection. Collections host more than one font and every one of them can be analyzed.
It should be noted that TrueType fonts are hosted in a format called SFont. SFonts can also host other font types. An example of this scenario are OpenType fonts by Microsoft, which can be TrueType compatible but go beyond the TrueType format. While the current support for TrueType also allows to inspect OpenType fonts, it is our intent in the near future to cover OpenType fonts in detail.
More updates related to fonts should soon be available. So, as usual, stay tuned. 🙂
The soon to be released version 0.7.4 of the Profiler features a useful PDF object search functionality. The introduction of this feature was possible thanks to the newly introduced parameters API and format specific actions.
Through this action it’s possible to perform predefined searches as for object with streams, JavaScript or embedded files.
But it’s also possible to perform custom dictionary searches.
Matches can be tagged and highlighted. Also new searches can be performed without resetting previous matches. In fact, in the screenshot below we can observe two different type of matches.
This was a requested feature and it certainly is very useful when analyzing PDFs. Stay tuned as more important news will be soon announced. 🙂