Decryping TLS packets between Windows 8 apps and Azure

Question

In Windows Store application development for Windows 8, there is a class called remoteSettings that lets a developer store batches of data so that the user will have access to it across several machines, as long as they are logged in with the same account.

I hooked up WireShark and discovered that the packet is stored in Azure, and is secured with TLS. I would like to MITM myself so that I can decrypt the packet and see if the data in encrypted on Azure.

I obviously don't have the private key for Azure, so I'd like to know if anyone has an idea on how to accomplish that MITM analysis.

Answer 1

If the data is being passed as HTTPS you could try the classic Fiddler man-in-the-middle approach. I'm not sure whether the Windows store respects the proxy settings or whether it has a pinned certificate. If it does respect the proxy settings, which it should, and it doesn't have a pinned certificate you should be able to trivially man-in-the-middle it with Fiddler.

If the data isn't HTTPS and the cerificate isn't pinned, one option is to proxy the secure connection using SSLNetcat. What you do is that you change your hosts file so that the Store executable connects to SSLNetcat running locally, then you set up SSLNetcat such that it uses a cerificate for which you have the private key. Then you either just have SSLNetcat forward the data directly to a program of your choice or enter the private keys into Wireshark and use it to sniff the traffic.

If the data isn't HTTPS, if the cerificate in the binary is pinned and not stored in a file, you can either patch the Windows Store executable and replace the certificate with your own for which you have the private key. OpenSSL should be able to generate a replacement certificate for you easily. This private key can then be entered into Wireshark which will then decrypt the traffic.

You're fairly close to copy protection territory so you might run into a number of complications.

Answer 2

One other thing that you could do, which is perhaps overkill but is useful in other scenarios, is to intercept the creation of the 48-byte TLS master secret. For many Windows applications (including IE), this happens in lsass.exe in the following function (taken from Win7 SP1 32-bit):

Caller:  ncrypt!_Tls1ComputeMasterKey@32+0x57 
EIP:     ncrypt!_PRF@40+0x11a

You can then decrypt the captured packets after the fact in Wireshark by setting (Pre)-Master-Secret log filename in the SSL preferences to a file file that looks like:

RSA Session-ID:87492B3586DE289FAE1598B0A19CC7BCCB69371993F2C0DF32438034E06FE3FB
Master-Key:F58C0EFA2BF87602646B318400DFEB0C8CCDE59408C9F13C6D923F6208743BD34EA8BA17BCE02B9BD8DFED5A58036068

The session ID here can be found in the TLS headers (unencrypted) for the stream you're interested in. (Don't be fooled by the RSA -- this works for all TLS connections regardless of the ciphersuite in use.)

The advantage of this method is that, since you're not doing a man in the middle, the client application doesn't have to trust your CA, which is especially handy if you're trying to reverse some malware that actually does crypto right.

The downside is that you need to be able to debug lsass.exe, which can be tricky; there's some information on how to do that here.

Answer 3

There are a number of approaches you could take with extracting the local key being used by Windows Store and feeding that into Wireshark, however, I think your best bet is to inject a DLL that hooks the Network IO functions send() and recv() out of your process.

You could try to do this on a "low level" yourself, but in the interest of pragmatism you'd be wise to examine Microsoft Detours for hooking, there are so many examples that utilize it - it's easy enough now that knowing your function prototype is the only essential requirement.

Answer 4

You could also try oSpy which basically hooks the appropriate API calls and lets you see the data before and after it has been encrypted/decrypted.

oSpy is a tool which aids in reverse-engineering software running on the Windows platform. [...] when the sniffing is done on the API level it allows a much more fine-grained view of what's going on. [...] if an application uses encrypted communication it's easy to intercept these calls as well. oSpy already intercepts one such API, and is the API used by MSN Messenger, Google Talk, etc. for encrypting/decrypting HTTPS data.

Answer 5

Most probably Windows 8 is using WinINet to connect with the App Store. If this is the case, you can see the unencrypted streams hooking into the wininet.dll instead of using a proxy. HookME does this and it was presented last year in BlackHat.

Probably you need to make some minor changes to compile and use it under Windows 8.