Artificial intelligence, fuzzy logic, neural networks, deep learning…
…any tools that help computers to behave in a way that’s closer to what we could call “thinking” are immensely useful in fighting cybercrime.
That’s because what’s generally known today as machine learning is good at dealing quickly with immense amounts ofthreat-related data, pruning out the many irrelevancies to leaving the interesting and important stuff in clear sight.
But don’t knock human savvy just yet!
Sometimes, a single, informed glance by a human expert is more than enough, like this great tweet from last week by computer security practitioner Paul Melson:
Do you see what I see? ―-BEGIN CERTIFICATE― UEsDBBQ…
Melson didn’t say exactly how or where he came across the file mentioned in his tweet. Given that he describes himself as an “unrepentant blue teamer” someone whose job is to keep unwanted visitors out of a network, or to find and eject those who have already sneaked in it’s reasonable to infer that he oughtn’t, and isn’t planning, to tell us. Let’s just assume he spotted the file as part of ruining some malicious hacker’s sneaky experiments.
If you’re a security researcher yourself, you’re probably going, “Hey, that’s cool!” (Or, perhaps more appropriately, “That’s very uncool .”)
But if you aren’t a sysadmin, you might be wondering what the fuss is about so we figured it would be informative to dig into the story behind the story.
Why does the text ----BEGIN CERTIFICATE---- UEsDBBQ... ring all sort of alarm bells, and what do those bells tell you?
Here goes.
Why the alarm bells?If you’ve ever dealt with public key cryptography for example, setting up web servers to accept HTTPS connections you’ll know you need a public/private keypair and a cryptographically signed certificate that vouches for your public key.
HTTPS relies on an underlying protocol called TLS, short for Transport Layer Security, and most TLS systems use a file format called X.509 to store their cryptographic material.
X.509 is a product of the 1980s telecommunications world, and follows the fashions of that era its native representation relies based on a rather complicated binary file storage system called DER (Distinguished Encoding Rules), which is, in turns, based on the resoundingly-named Abstract Syntax Notation One (ASN.1).
Let’s make a self-signed certificate of our own to play with (we used Lua code here, linked with LibreSSL, but you don’t need to reproduce what we did, so don’t worry if you aren’t a programmer):
We saved the raw binary data of the certificate as a DER file, giving us a decidedly text-unfriendly certificate that looks like this when dumped:
Even with the careful help of LibreSSL’s built-in ASN.1 parser, we get the still-not-very-readable:
To make X.509 certificates more robust so you can add them to emails, keep them in text files and so on without risk of corruption they are usually saved in Privacy-Enhanced Mail format, or PEM for short:
PEM files consist of the raw DER data converted into base64 , a text-only format in which four text characters are used to encode every three bytes of binary data, thus sticking to plain ASCII and avoiding control characters, risky punctuation marks and so on.
So, as a security practitioner, you’ll quickly get used to seeing -----BEGIN CERTIFICATE----- in security-related files.
In fact, you sort-of stop noticing certificates after a while they aren’t supposed to be secret, and any modification, whether by accident or design, automatically renders them useless.
So why would Melson’s rogue certificate stand out?
Certificates are there to share. Every time someone connects to your website, you send them a copy of your certificate, which contains your public key and a digital signature by which a trusted third party vouches for the fact that it really is your public key, issued for your website.
What are certificates supposed to look like?Let’s dump the first few bytes of the 149 certificates that are built into Mozilla products as officially-trusted certificate authorities these are the trusted third parties that Mozilla currently accepts as fit to vouch for websites that you visit with Firefox:
Note that every certificate starts with the bytes 30 82 0x .
That’s because the X.509 encoding always kicks off like this:
30 - what follows is an X.509 SEQUENCE of objects82 - the next 2 bytes encode the length of the rest of the objects
HH - the high 8 bits of the 2-byte length
LL - the low 8 bits of the 2-byte length
The lengths of all these Mozilla “root” certificates range from 442 to at most 2007 bytes, so their encoded lengths are never lower than 0x0100 (256 in decimal), and never bigger than 0x07FF (2047), so their X.509 encodings always start with one of these sequences:
30 82 01 0030 82 01 01
30 82 01 02
. . .
30 82 07 fe
30 82 07 fe
30 82 07 ff
We’ve printed the hexadecimal length of each DER file in the chart above it always comes out as 4 plus the length encoded into the SEQUENCE mark, which denotes the four bytes used for the sequence mark itself, plus the length of the sequence.
Now, when you convert three bytes starting 30 82 0x into base64 notation, you end up with four encoded bytes like this…
Raw Base64------ ------
30 82 00 MIIA
30 82 01 MIIB
30 82 02 MIIC
30 82 03 MIID
30 82 04 MIIE
. . .
…and so on.
In fact, you get this pattern all the way to 80 82 3f :
Raw Base64------ ------
. . .
30 82 3d MII9
30 82 3e MII+
30 82 3f MII/
30 82 40 MIJA
30 82 41 MIJB
In other words, for any X.509 certificate that is less than 0x3FFF (16,383) bytes long, the first three base64 characters of the corresponding PEM data will always be MII .
And therefore ---BEGIN CERTIFICATE---- UEsDBBQ smells plain wrong!
Know your base64 magicActually, there’s more to it that that.
The first two characters of a base64 sequence decode to the first 12 bits of the original content, and many popular file types aways start with the first two or more bytes.
Constant bytes at the start of files are known in the jargon as magic numbers , because they magically tell you the type of the file.
More precisely, magic numbers give you a strong hint that a file will turn out to be of type X, or tell you that it can’t be of type Y or Z.
Here are some common examples:
Here are those sequences converted into base64 strings, shortened to just two or three characters for easy recognition:
Experienced security researchers will readily recognise dozens of these base64 “hints”, but even if you only memorise TV (which stands for MZ) and UE (for PK), you will be able to spot loads of potentially malicious files at a glance.
The MZ file marker covers a whole range of windows executable files, including both EXEs and DLLs, which share the same format.
And ZIP archives are used for many purposes, including by Android apps, which come with a .APK extension but are stored in ZIP format, and Microsoft Word files, which use a variety of different internal layouts, including ZIP.
All of this raises the question, “What had Melson spotted?”
From the UE at the start, you can tell at once it was a ZIP file, but what was inside?
It turned out to be an Excel spreadsheet complete with macros (embedded program code) set to execute when the document was opened:
VBA (Visual Basic for Applications) macros inside an Excel file are embedded into the component called xl/vbaProject.bin :
By default, Office won’t automatically run macros, so a little caution will keep you safe crooks trying to spread malware this way not only have to persuade you to open the document but also have to trick you into clicking a button to [Enable macros].
Fortunately, it looks as though Melson spotted this one while the crooks were still messing around with the idea, because the embedded Auto_Open macro simply tries to run a program called C:\shell.exe that has already been installed in the root directory of the C: drive.
Given that the root directory is not writable by a regular user, any crook hiding malware there probably already has sysadmin powers, so this attack really doesn’t add much.
But it’s a neat way of hiding in plain sight and it means that the crooks can use the inconspicuous and official Windows utility CERTUTIL.EXE to decode the file.
CERTUTIL knows to expect the -----BEGIN CERTIFICATE----- marker and therefore automatically strips it off before un-base64ing the enclosed data:
Of course, if you use CERTUTIL to verify the extracted “certificate” afterwards, you will immediately realise that it is bogus, because it isn’t in DER format at all:
…but the crooks already know that and can therefore use CERTUTIL as an attack utility rather than as a security tool.
What to do? Don’t trust files based only on filenames or headers they include. The crooks don’t play by the rules so they routinely mis-label data in the hope of staying off your radar a bit longer. Take care when you verify downloaded data. Make sure that the scripts or tools you use to validate untrusted file don’t themselves try to “assist” you by choosing a helper app based on what the files seem to be.The second point sounds above obvious but it is easily overlooked.
Notably, never double-click a file just to see what the operating system makes of it you will often end up launching it,- with all the security risks that entails, instead of merely viewing it.
