Odd Socks! | day-z

Whilst wandering around the Internet a few days ago, I stumbled across a company serving a binary (exe) file that when executed, fired up a web socket server using TLS. This piqued my interest a little.

Immediately, I thought "Well obviously it must be a dynamically generated self-signed cert. No-one would bake their own certificate and private key into a binary and then ship it to the world... Right?!"

After many years in security, I should know by now to prepare for a wild ride when the spidey senses start tingling. But it still makes me chuckle every time I find design decisions like this being made.

Initially I opened the binary in IDA, but there was hardly any information, which I thought was strange. The imports table only showed one import: _CorExeMain from mscoree.dll.

_CorExeMain in IDA — The one and only graph node in IDA

IDA Imports — The one imported function in IDA

After a bit of Googling, I realised I was working with a .NET application.

MSCorEE.dll is a Microsoft library file which is essential for the execution of managed code applications written for use with the .NET Framework.

mscoree.dll

Here's a few other quick and dirty methods to check if you're working with a .NET application:

objdump

objdump -x target.exe | grep -A 50 "Import"


The Import Tables:
  lookup 000095f8 time 00000000 fwd 00000000 name 00009612 addr 00002000

    DLL Name: mscoree.dll
    Hint/Ord  Name
           0  _CorExeMain

rabin2 from radare2

rabin2 -i target.exe


nth vaddr      bind type lib         name
―――――――――――――――――――――――――――――――――――――――――
1   0x00402000 NONE FUNC mscoree.dll _CorExeMain

Any time you see mscoree.dll, you know you're working with a binary that uses the .NET runtime.

.NET applications are different from binaries compiled directly into machine code i.e. raw x86/x64 CPU instructions. They're compiled into Intermediate Language (IL) bytecode, which is JIT-compiled to machine code at runtime.

IL can be fairly accurately be decompiled to C# (even if C# wasn't the original language) with tools like dnSpy, ilSpy and dotPeek.

What's also interesting about .NET applications is that they can include embedded resources.

According to Microsoft:

You can include resources, such as strings, images, or object data, in resources files to make them easily available to your application.

embedded resources

This seemed like a good place to go hunting for some secret sauce.

I fired up dnSpy and loaded the application in question and headed straight for the embedded resources.

.NET embedded resources — Embedded resources in a .NET application

There were only two embedded resources, but they sounded pretty promising:

[REDACTED]Cert
certpass

dnSpy has a neat little feature that allows you to save the resources to a file, and that's exactly what I did.

The certpass file looked to be an 8 character unencrypted string. And experience told me that I was likely dealing with a PKCS#12 certificate, so I gave the certificate file a p12 extension and used openssl to do some digging.

The first command I ran to validate my assumption about the certificate was:

openssl pkcs12 -in certificate.p12 -nodes

This essentially says, dump everything from the PKCS#12 container.

I was prompted for a password... Positive start. So I pasted the string from the certpass file and crossed my fingers!

p12 nodes — Using the unencrypted password to decrypt the certificate

Nice! Next I wanted to see who issued the certificate and what it could be used for. The issuer will determine the scope of trust i.e. whether every man and his dog will trust it or whether it's internal to the organisation.

openssl pkcs12 -in certificate.p12 -clcerts -nokeys | openssl x509 -text -noout

Inspecting the EKU to see what the certificate can be used for.

Ooooooo - spicy!!

The issuer was Digicert, and their root CA is pretty much globally trusted by every browser, OS and device. So the scope of trust is huge!

And in terms of the Extended Key Usage (EKU) i.e. what the certificate can be used for - Unfortunately, we don't get the ability to sign-code. That would have been awesome! But we're still able to use the certificate for:

TLS Web Server Authentication
TLS Web Client Authentication

So theoretically, anyone who extracted the certificate, and used the certpass to decrypt and unpack it, would gain the ability to:

Impersonate the domain in the SAN - this means pretty green padlocks in browsers. But successful attacks would require some other pre-requisite conditions such as DNS poisoning. Although if the SAN was a wildcard (which it wasn't...Boo!), this wouldn't even be required!
Authenticate to any services that accept the certificate
Impersonate a machine identity which could provide access to internal services or VPNs that rely on client certs
And much more

I should add that I didn't attempt to use the certificate for any of these purposes - that would have been naughty!

However, theoretically it may have been possible. So all-in-all a significant finding with significant potential impact.

The company was made aware, have revoked the certificate and remediated the issue.