July 15 security incident
Dani
Hi everyone. We are unfortunate to tell you that we have experienced a security incident. I didn't expect this to be my first blog post, but we want to disclose what happened before, during and after the unplanned maintenance and what we are doing to improve our security and prevent this incident from happening again.
Before starting, we want to assure everyone that no passwords, console or payment information has been leaked, and an email will be sent to all potential victims about their account security.
What happened
On July 15, we received a report about an exploit that a user was using to seemingly reset anybody's account password and get access into it. Given the danger of the exploit if it were true, we decided to take down the servers while we investigated into the claims of the report and the damage they could have done.
The evidence from the report showed an attempt of a "padding oracle"-style attack against our tokens to trigger a password reset. I'll explain what that means in layman's terms:
When you login with your username (in our case the PNID) and password, the server gives your web browser or your console a "token", which is a number that identifies that specific session in your device. You don't want to store any sensitive data there for anyone to see, or worse, you don't want to make the token simple, otherwise anyone would be able to guess a token and pretend to be you.
To prevent this, our tokens (up until today) only had basic information like the account ID (called PID) to identify you, and the purpose of the token. This data would be encrypted to prevent anyone from getting this data or replace it to disguise as another person. However, there is still the possibility of doing a "padding-oracle" attack which allows you to effectively guess and try to replace the PID with a different one, letting the attacker temporary access into the account, which they could protect with a password reset.
Impact
During the investigation, we saw activity that correlated with someone attempting this attack thousands of times starting on July 9, and according to our records, 1864 password resets were triggered on that timeframe (note that not all of those resets are necessarily compromised accounts, that number includes legitimate resets). This is a small fraction of the userbase (about 0.3% of all PNIDs).
We haven't seen any evidence of data exfiltration from our databases. However, with a compromised account, the attacker may have also had access to detailed information of the PNID, though this data is generally already public:
- Access level: whether you have tester access or the account is banned
- Account creation and updated date
- PNID and PID
- Birth date
- Gender: this is usually already public with your Mii
- Country and timezone: these are technically already public if you have played online, since many games show this information to others and on multiplayer your IP address has to be made available to other players
- Email address
- Discord user ID: if you have Discord linked
- Basic tier level data: whether you have Mario or Super Mario perks
Once again, we want to reiterate that no passwords, console or payment information has been leaked. The payment information is managed exclusively by Stripe, our payment processor, so we don't have any access into it. And in any case, we store secure password hashes so hackers can't recover the password had those hashes gotten leaked (which they haven't).
What we're doing
Regarding the compromised accounts, while passwords were not leaked, as a precaution we will be forcing a mandatory password reset to all potentially affected users by changing the passwords to random ones. Alongside that, we will restore the previous emails of the accounts in the cases that it got changed (which was only 7 people). We will notify all possible victims about these measures via email too.
We are also making improvements on the technical side to prevent this from happening anymore. Oracle attacks work by manipulating unauthenticated encrypted data (which was our case, as the Wii U/3DS impose limits on how large certain tokens may be). As we explained we were storing some metadata about the user in the token for consuming services to use (this is also what Nintendo did with their tokens), but even prior to this incident we knew that this system would not work long term and were already planning to phase it out.
The new system which we have migrated to embeds no data inside tokens, and instead uses completely random (opaque) data, and require services to instead always phone back home to get the data that would normally be inside the tokens. The size of the new tokens, along with them cryptographically secure random byte, are functionally impossible to brute force or tamper with, rendering the attack useless.
Some of you may have thought about implementing two-factor authentication (2FA) into our services to improve security. But as promising as that sounds at first, it is much harder to implement within the limitations of the consoles, as the 3DS and Wii U have never supported it. There has been discussion about potential solutions to mitigate this, but it will take time before those ideas come into life.
Closing
We want to apologise to everyone who has been affected by this incident, whether it be for being a victim of the attack or by our maintenance period. And also give my thanks to the rest of the team who has been working on this maintenance to get our servers out as soon as possible, or handling moderation in our platforms during the incident. I hope our next blog post goes on a more positive note.