Every day thousands of phishing emails are sent to unsuspecting people who are tricked into handing over their credentials for online services or directly bilked out of their money. Phishers go to great lengths to lean on the credibility of the organizations they’re impersonating. So what could be better than the ability to post a document onto an actual official website?
Recently, it came to light that as part of the FCC’s public commenting system that malicious individuals could upload their own PDFs and image files to the FCC’s site. These files are indistinguishable from official communications that the agency might post – and the potential to abuse that vulnerability is incredibly high.
Just think of the implications of this capability: Phishers could use hosted PDFs to level fake fines on people. Stock market manipulators could post fake FCC sanctions for public companies. Not surprisingly, trolls and mischief makers are already generating fake FCC memos mocking the agency.
Service Oriented Security Issues
It’s since been fixed, but when reported, the FCC’s commenting application was utilizing an internal app API they had built. For large or complex applications, this style of building a single user facing application out of smaller component apps is becoming more common. This type of Service Oriented Architecture (SOA) can let you build powerful applications more simply (you could imagine that there are many applications the FCC might built that would require the ability to attach files), but greatly increases the potential surface area for attacks.
What’s an API Key Really?
To utilize their own FCC File Upload App, they issued themselves an API key to the application. While the term ‘key’ brings up associations of Public Key Cryptography and and the Public and Private keys used for SSH, an API key is really better considered to be just a password.
Typically they’re long randomly generated sets of characters, like: ‘20yhy3093-3asdfewer34093049-2394xcv02” but there’s no reason an API key couldn’t be something like “this-is-my-super-secret-password-api-key”.
In many ways it’s just as insecure if you were able to log into an application using only a password (With no username).
The FCC’s original commenting application pre-assigned a URL for uploading from their file handling application. In the process of this they also exposed the API key that they’d assigned to the larger commenting app.
Hackers and mischief makers were then able to reuse that same API key (essentially impersonating the legitimate FCC app) to make calls placing extremely questionable files on the FCC server among other actions.
Separate from the above leak of their own API key, it was also found that the FCC was issuing official API keys to anyone who asked. While the intent and possibilities here were great: developers could find interesting aspects about FCC data, or build their own clients to interact with FCC servers, they didn’t take into consideration all the different ways that the system could be abused.
What Are the Lessons?
The internet has identified a huge vulnerability in the FCC’s site – leaving them open to a whole mess of abuse.
Properly authorizing API access is notoriously tricky and there are a few key areas that are paramount to maintaining a secure state:
Keep your own public API key private. Use a secrets management store, or at least don’t check them into source control and call them from environment variables.
Monitor API keys and manage who has access to them in the first place (pro-tip: most people shouldn’t have access)
Separate the publicly modifiable aspects of your service from official communications.
Beyond API Keys
API key issuance as a means of authentication and authorization is in many ways on the way out. It’s too brittle. There isn’t an efficient means to indicate what modules of a larger system an API key should have access to (scoping) and often times there isn’t a great way to revoke privileges once given.
The general solution to all of these challenges is use OAuth. We’d recommend checking out our: Introduction to OAuth post to start learning more.
The intersection between an organization’s own services and the public is a highly valuable area that needs to be secured. A century ago it was faked telegraphs and memos sent on stolen letterhead. A decade ago it was common for email servers (or even just HTML forms connected to services that send emails) to be coerced into sending messages from a phisher that look as if they originate from the legitimate organization.
Today it’s API abuse. Just the latest method that horrible people on the Internet are using to defraud people. As you build and secure systems, focus on protecting your data, your users and your organization’s credibility.