Thread by @Cryptadamist

🧵
Last week I wrote a piece about how opening the wrong PDF led to a #cybersecurity breach that rapidly escalated

Since then I've figured out how the PDF managed to evade all major virus/malware detection tools and exploit a vulnerability (that may still exist!)

Let's dig in👇

As mentioned in the piece I had suspicions about the PDF because it had come from the vicinity of #cryptocurrency criminals, so before opening I ran it through a bunch of reputable malware detection tools.

They all gave it the all clear... and they still do. Here's a link to the @virustotal report showing 0 out of 61 malware scanners alerted on this PDF.

#VirusTotal is Google's #cybersecurity offering so it's not surprising Gmail also gave it the all clear.
virustotal.com/gui/file/61d47…

It is, however, kind of appalling, given that researchers at Google's own @ProjectZeroBugs have stated that any PDF created in the last decade using @Adobe's Type 1 font technology from the 90s¹ should be considered highly suspicious.

googleprojectzero.github.io/0days-in-the-w…

¹ (foreshadowing)

Classic case of trusting algorithms and "AI" over common sense, which is a brain disease many engineers suffer from. But I digress.

Once I was able to lock down my digital life sufficiently to get back online, I was able to get this evil PDF onto an air gapped machine and dig in

The internet revealed that the rather narrow field of malicious PDF research has given the world a suite of tools, chief among them those created by #cybersecurity knight Sir @DidierStevens.

These revealed the presence of something called an "/OpenAction" (cue scary music)

Curiously, however, neither the tools of Sir @DidierStevens nor another tool called #PeePDF found any Javascript or shell code in the document.

PeePDF's bad case of the poor maintenance made it pretty useless but it was useful enough to flag this "/OpenAction".

In red, even.

As far as I could tell at this juncture this /OpenAction just told the PDF reader to open the first page, which wasn't super alarming in and of itself.

It was around this point that I ended up starting the development of my own malicious PDF tool to fill in the gaps around some of Sir Didier's amazing work. I wanted to be able to visualize the PDF's logical structure so I could follow this /OpenAction.

I called this tool "the PDFalyzer". Among other things it can do, it creates some colorful images showing the PDF's logical structure. One of these image shows a summary and the other shows a lot more than a summary.

Here's what they look like for this document:

(As an aside I just open sourced the pdfalyzer, here's a link)
github.com/michelcrypt4d4…

But I was still stuck. It wasn't obvious what /OpenAction was doing besides opening a page and the document had no executable code that I could see.

At this point I was able to use Sir Didier's pdf-parser.py to extract all the binary stream data in the PDF, which consisted of things like the contents, the layout information, etc, as well as... some fonts¹.

¹ remember that foreshadowing

There were four fonts in the document, two TrueType fonts and two of Adobe's original font format, now called Type 1.

Type 1 fonts are really a weird kind of drawing language, and the binaries are almost human readable...

... at least at the top of the file. In the middle of the file this changed, which was weird.

But far more alarming was the presence of a "currentfile eexec right before the unreadable section.

As anyone who has worked with computers can tell you, there's a couple of magic words computer engineers are very, very afraid of. "eval" is the scariest and most powerful of these words¹ but anything involving "exec" is not far off

¹ just because it works in many languages

These instructions are scary because they tell the computer to take some text and treat it as code instead of text. A large number of security holes can be blamed on some web developer carelessly calling "eval" on text users of his site enter in a form.

So I was concerned.

This turned out to be (sort of) a false alarm. The Type 1 spec indicates "eexec" is actually just sort of the demarcation line in an @Adobe font between the human readable part and the encrypted part.

But at this point I'm digging around in the font's binary garbage dump, which look like this.

It's a depressing sign of how long I looked at this kind of thing that I started to notice... stuff. Stuff that only someone who's spent too much time programming would notice.

In particular I noticed some backticks AK these things: `

Backticks are a sigil with almost as much destructive power as the magic words "eval" and "exec".

Why, you may ask?

Because in a couple of languages - crucially including both the ones that could appear in a PDF - backticks mean "eval".

`evil_code` == eval("evil_code")

And then... as I was looping through the various strings quoted by the backtick sigil, I stumbled on the characters "JS". In binary form.

What, you don't see it?

Well that's why the pdfalyzer will search for and highlight these kinds of scary glyphs in font binaries. Like this:

"/FJS`\xbb`" turned out to be the evil magic that the crypto bros who hacked me had sold their souls for:

1. PDF instructions are prefaced with a /
2. "/F" means URL
3. "JS" is Javascript
4. And the kicker: \xbb is the binary representation of "»"

WTF is '»'?

« and » are quotation marks. Ones we don't use much in English any more. But:

They are the quotation marks used by @Adobe PDFs to mark the boundaries between objects.

Thus "/FJS`\xbb`" translates to: "Close this PDF object before you're done rendering it"

Without getting into the technical details - partially because they are rugged but more because I'm not a cybersecurity expert - prematurely popping the stack like this can leave the computer in a vulnerable state. You've heard that scary term "arbitrary code execution"

Either way, it's conclusive proof that there is JavaScript hiding... inside the font binary.

Whoah.

What's even more amazing is that I was able to use an ancient tool called t1disasm to fully decrypt and decompile these binaries into the 100% semi-human readable format of an Adobe Type 1 font!
github.com/kohler/t1utils

So however this Javascript was embedded, it didn't disrupt the normal operation of the font (!)

Unfortunately my research ends there... the JavaScript turned out to be processed in one of the many ways malware authors like to process their JS and I couldn't sort it out.

I'm also not sure if this PDF was able to exploit Windows or macOS. I only opened the PDF on a windows machine, but I did handle it on macOS Monterey.

But I suspect this vulnerability is still out there in the world, so if you know any cybersecurity folks, please tag them!

I'm pretty sure I could eventually decrypt this JavaScript but I'm much more sure any reasonable malware researcher could do it way faster.

And if you missed, here's the long saga of all the crazy situations opening this PDF led to:
cryptadamus.substack.com/p/the-crypto-b…

Few other things:

1. Both Type1 Fonts in this PDF include "JS"
2. The binaries were actually the same length they advertised, so the evil code wasn't just hiding in the back out of sight.
3. I was even able to build character mappings for these fonts, which was sp00ky

Seeing "To synchrize wtu" emerge after a week or two of digging from the code I wrote was definitely one of the spookier moments. I also stumbled on the word "Quiz" which was pretty weird.

Also uploaded the font binaries to #VirusTotal on their own after freeing them from the walls of the PDF in which their evil had been imprisoned. Unsurprisingly the borg¹ gave them both the all clear
virustotal.com/gui/file/2ed5b…

¹ Google's name for the supercomputer that is Google

also a shout out to @textualizeio. @willmcgugan only recently released the rich.tree python module that made creating attractive diagrams like these shockingly easy.

(images show the official @Adobe type1 font spec PDF and an nmap cheat sheet PDF - high art, in other words)

found a helpful guide to the aesthetics of various malware obfuscation techniques: github.com/g-les/Misc/blo…

but nothing aesthetically matches this font data. posting some screenshots in the region of the "JS" instructions I found in case some 🧵 reader can see a pattern I can't

I improved the #pdfalyzer's "#maliciouspdf font binaries" output to not barf on weird ASCII like the much used #VERTICAL_TAB and also views of a few different encodings.

screenshots of the suspect 'JS' regions (@struppigel, @librehash, @officer_cia, @ferdinan_4, @jdgregson)