Defeating TLS on the 3DS

[Poryhack]

In the last two weeks there has been news of two critical flaws in TLS implementations; one affecting iOS/OS X and another affecting GnuTLS (Linux). Both flaws have allowed 3rd parties with man in the middle access to effectively defeat TLS. This is disastrous from a security standpoint, but if the implementation of TLS on the 3DS is similarly flawed it opens up a vector for PKX sniffing/injection (amongst other less interesting things) that wouldn't require the end-user to have specialized hardware.

Based on the legal notices on page 99 of the 3DS manual Nintendo is using OpenSSL (a direct competitor to GnuTLS), Ubiquitous TCP/IP+SSL, and RSA BSAFE. All three appear to be equipped to handle TLS operations which makes it hard to say which implementation the 3DS actually uses for TLS. Nintendo could also have a homegrown implementation but it seems unlikely. Its worth noting that RSA BSAFE has been referenced as far back as the original DS while OpenSSL and Ubiquitous only go back to the DSi.

I freely admit that defeating TLS seems like a less promising avenue to a gen 6 editor than existing work already being done with save decryption and unsigned code execution, but I wanted to point out the possibility to all who may be interested.

Edited April 8, 2014 by Poryhack
typo

[Reisyukaku]

Neat! I remember when I was capturing packets from the 3DS, I noticed all the trade packets were TLS. I was also trying to think about how to do a MitM, but I've never actually done one without using things like charles, so i gave up

But yea, I'd probably just end up waiting until someone figures out how to rehash the saves or something.

[Poryhack]

Another critical bug has been found (this time in OpenSSL) that could allow us to actually gain access to the private keys Nintendo's servers use to authenticate themselves to the 3DS. This is significantly different from what I described in my first post as it doesn't take advantage of the client (3DS) TLS implementation; it steals the private keys right out of server memory. With the private keys we wouldn't need to rely on a flawed client implementation. We could mimic the server with 100% accuracy. As far as I can tell there are no public exploits available yet, but they will surely come soon.

[haoLink]

Another critical bug has been found (this time in OpenSSL) that could allow us to actually gain access to the private keys Nintendo's servers use to authenticate themselves to the 3DS.

I was reading up on this myself earlier this morning and obviously it sounds promising. THere are already tests to check if your server is affected by the bug - for example on http://filippo.io/Heartbleed/ - what they do there: they inject a message into the TLS handshake and check if that message is being returned. Nicely enough servers I manage at work for clients were affected so I had to upgrade OpenSSL on many of them in the last hour. Most webpages I randomly checked seem to be already fixed (or they used old OpenSSL versions to begin with which aren't affected).

[Poryhack]

I was reading up on this myself earlier this morning and obviously it sounds promising. THere are already tests to check if your server is affected by the bug - for example on http://filippo.io/Heartbleed/ - what they do there: they inject a message into the TLS handshake and check if that message is being returned. Nicely enough servers I manage at work for clients were affected so I had to upgrade OpenSSL on many of them in the last hour. Most webpages I randomly checked seem to be already fixed (or they used old OpenSSL versions to begin with which aren't affected).

This particular test seems to fail on Nintendo's servers ("Uh-oh, something went wrong."). 3ds1-us.pokemon-gl.com however tests fine, and doesn't appear to be vulnerable. EDIT: Appears to be hosted on Amazon EC2, which has already addressed the bug.

Here's a small subset of domains worth testing:

nppl.c.app.nintendowifi.net

nasc.nintendowifi.net

account.nintendo.net

mii-secure.account.nintendo.net

npdl.cdn.nintendowifi.net

tagaya-ctr.cdn.nintendo.net

pls.c.shop.nintendowifi.net

npul.c.app.nintendowifi.net

nus.c.shop.nintendowifi.net

ecs.c.shop.nintendowifi.net

[Poryhack]

An exploit is now available here. I tried it against the domains I mentioned in the last post and they all came back negative. They may have never been vulnerable or they have been already updated to the latest OpenSSL.

[Pipian]

nas.nintendowifi.net (the server required to support online play with Pokemon Pearl/Diamond and others) apparently does not support the TLS heartbeat extension, and as such was never vulnerable to the attack.

[MetalMario]

Question: Does the DS accept X.509 certificates using signing algorithms other than SHA1-RSA? Like perhaps MD5? Also, does it care what's contained in the subject or just that it's signed by Nintendo CA?

Edit: Found this in a Google search for "factoring RSA":

http://windowsontheory.org/2012/05/15/979/

Basically, if either Nintendo CA's public key or that of any of the certificates they've signed share a common factor with any random public key we can find on the internet, it can be broken in a reasonable time if enough people have bitcoin mining clusters they're willing to lend.

[Poryhack]

Question: Does the DS accept X.509 certificates using signing algorithms other than SHA1-RSA? Like perhaps MD5?

I'm not sure. I've seen the 3DS accept SHA256-RSA. My best guess is that the DS does accept MD5.

Also, does it care what's contained in the subject or just that it's signed by Nintendo CA?

Again, not sure. I can difinitively say from my own testing though that 3DS titles do care about the subject field and not just being signed by the correct CA.

Edit: Found this in a Google search for "factoring RSA":

http://windowsontheory.org/2012/05/15/979/

Basically, if either Nintendo CA's public key or that of any of the certificates they've signed share a common factor with any random public key we can find on the internet, it can be broken in a reasonable time if enough people have bitcoin mining clusters they're willing to lend.

I don't see any mention of Bitcoin in that article, where are you getting that part?

[MetalMario]

I'm not sure. I've seen the 3DS accept SHA256-RSA. My best guess is that the DS does accept MD5.

The only significance is that MD5 computes faster so would be easier to use for a brute force preimage search.

Again, not sure. I can difinitively say from my own testing though that 3DS titles do care about the subject field and not just being signed by the correct CA.

Pipian will probably need to answer this. If the DS/Wii don't care very much about the subject then it might be possible to use the same (forged) certificate for both their authentication servers.

I don't see any mention of Bitcoin in that article, where are you getting that part?

I meant it as a generic term for lots of spare compute power that can be diverted from relatively useless tasks like bitcoin mining.

The RSA common factors attack also requires that they did a bad job generating their key. This being Nintendo (in 2005), who knows.

All this is idle speculation in absence of more facts.

[Poryhack]

Most of this is easy enough to test. Gens 4 and 5 store Nintendo CA's public key directly in the ROM. You can generate your own key pair with OpenSSL and replace the public key in the ROM with your own. From there you can generate and sign your own certificates with whatever algorithm and subject field you'd like.

The factoring thing is a longshot but maybe worth pursuing. Once you have a collection of public keys from Nintendo CA and the certificates it has signed you can check out the EFF SSL Observatory or something similar to comb through a large number of certificates for common factors. For what it's worth, Nintendo uses OpenSSL to create/sign certificates.

[Hozu]

Wouldn't cracking this affect ALL 3DS games? Something tells me Nintendo wouldn't like that, and they'd make large efforts to close any holes that people find due to the sheer magnitude of things.

[Poryhack]

It depends. Most, but not all, of the ways to defeat TLS that have been described in this thread would affect the 3DS/DS as a whole and not just specific games. For the 3DS at least, Nintendo probably would patch out anything that affected the platform as a whole. The cool part about breaking TLS though is that you could potentially build up your own online infrastructure and simply never upgrade your firmware. I don't know if that's very realistic but it is an option.

I will admit that discretion would probably be optimal if a hole is found.

[MetalMario]

They use a different CA for 3DS as opposed to DS and Wii. DS is also unpatchable and a Wii patch seems unlikely at this point. Since their official servers are shutting down, issuing a patch blocking all online activity seems especially troll and unlikely.

As long as we don't attempt to crack (or at least release publicly) their 3DS CA's private key, it shouldn't prompt them to issue a patch. In absence of any bad key generation, cracking an 1024 bit RSA would take hundreds of years with current technology.

Forging individual certificates is going to be much easier than breaking a private key.

[Poryhack]

Yet another OpenSSL bug was announced today. This one is MITM only unlike heartbleed. Some relevant links:

https://www.openssl.org/news/secadv_20140605.txt

http://ccsinjection.lepidum.co.jp/

https://www.imperialviolet.org/2014/06/05/earlyccs.html

[MetalMario]

It seems to deal with forcing the client to use weak session keys, so it doesn't appear to be of any help in implementing custom servers. Also I don't think the DS/3DS use OpenSSL?

[Poryhack]

I was thinking more about fake clients than fake servers. If we can decrypt the traffic and reverse-engineer the protocol we could write a client that would allow for exporting and importing PKMs via trade or whatever.

I'm not certain that the actual implementation of TLS on the (3)DS uses OpenSSL, but like I mentioned in my opening post, the DSi and 3DS manuals include OpenSSL's copyright notice (as well a 2 other crypto products).

[MetalMario]

As we all know from Instacheck, any MITM exploit on the official servers can and will be patched. I'd hedge my bets on the game breaking pkm injection being client-only, like breaking save file signing or however the hell Datel does it.

[Poryhack]

Fake clients aren't technically MITM. You don't even really need a MITM exploit to develop them. In an ideal situation Nintendo's servers would just see the fake client as a regular 3DS.

If unsigned code execution continues to be a privilege limited to a select few then we could see fake clients pop up, assuming those select few are willing to do some research into the protocol. If it goes widespread however that that will obviously be the preferred way to do things. Although IMO there is something kinda elegant about just "trading" your pokemon away to a Pokecheck type website, editing it via your web browser, and returning it the same way. No fiddling with save files or clunky windows forms apps...

[Poryhack]

I am a little late with this, but Red Hat has an online tool (I've seen a couple other downloadable ones) to check for the presence of this vulnerability on the server side (the vulnerability needs to exist on client and server for a successful exploit) located here. Interestingly, all the Nintendo domains not hosted on Amazon EC2 (there are a few, mostly for 2nd/3rd party stuff like Pokemon) are affected. This also confirms that Nintendo is using OpenSSL on their servers. Still no confirmation of OpenSSL on the client side, but it could be useful to know for sure that their servers are running OpenSSL in case of future exploits.

I will stay on the lookout for a way to test for this vulnerability on the client aka (3)DS side. The information is out there for people a little more inclined than I am, so I expect one will pop up soon.

[MetalMario]

But this exploit is for MITM only.

Edit: And both client and server need to be vulnerable to allow for reading cleartext.

Edit2: If we can modify the client then we don't even need an exploit to document the protocol. This is how custom DS wifi servers were made. So breaking TLS is moot if this is possible. (but certainly *not* moot for getting unmodified clients to connect)

[Poryhack]

We already can modify the client. "We" being the select few people that have setups enabling them to run unsigned code. Those people could technically document the protocol now and allow us to develop fake clients. You're right about a TLS exploit not really being needed, but it's a potential vector for somebody who wants to document the protocol and write up a fake client (which would work for everyone).