FBI email: when a hack isn't a hack

The FBI server was exploited, but not compromised.

The latest hack in the news is an FBI server that hackers used to send 100,000 spam emails [1][2]. A subtle but important detail of this story is that the server wasn’t hacked, at least not in the traditional meaning of the word. Hackers didn’t break into the server — they tricked the server.

It’s difficult to explain the difference in a non-technical way because techies themselves get confused. Brian Krebs has a good technical description[*] but I’m going to try a more high level view of the problem.

Interactive websites are built from code/data within webpages combined with code/data on the servers. The stuff on the server is trustworthy, anything sent to the browser is not. The web-page you see in the browser can be changed. You can hit F12 to see the raw code, and modify it to do unexpected things.

This isn’t “hacking” in the traditional sense because the only person who will see your changes is yourself. In other words, if you hit F12 and change the title of this article, only you will see it.

We can change not only what’s displayed but also what’s sent back to the server. When you click on things (on interactive webpages), such as filling out a form, this data gets sent to the server. When you modify a webpage, you can modify these forms, and add or change fields. These forms typically have “hidden” fields that hackers can also manipulate.

Thus, when interactive websites receive things back from such modified webpages, it may not be what they expect. Every request from a web-browser must be treated as if it were malicious. Servers shouldn’t trust anything from a web-browser.

The FBI server failed to do this. The server in question is for registering new accounts. Like all such servers, it sends a confirmation email.

However, instead of generating those confirmation emails purely on the server, it allowed the web-page to create them. This is fine when nobody modifies the webpage — but it means hackers can modify the webpage on their own computer to send different confirmation emails, ones that don’t look like confirmations at all.

Thus, to make FBI server send fraudulent email to people, a hacker went to the sign-up page and modified it slightly. The hacker changed the fields “Subject” and “TextContent” sent to the server when creating an account, resulting in the server using them when sending confirmation emails.

Moreover, with a little code, hackers could read a file containing 100,000 email address, and attempt to create an account for each of them, causing a custom confirmation email to be sent each time.

Thus, hackers didn’t hack into the server — they tricked the server. They didn’t break into the server. Any data on the server is still safe. Hackers just caused account creation requests with customized data.

As I said, this is hard to explain to non-techies because it’s something that confuses techies as well. Websites are often made using “frameworks” that hide complex details. That’s because website makers are often skilled in the artistic aspects of website creation rather than technical aspects. One of those hidden technical details is the difference between untrustworthy code/data up in the browser and trustworthy code/data that’s on the server.

The FBI has a press-release[*] talking about this incident. It has the following advice:

We continue to encourage the public to be cautious of unknown senders

This is common, but wrong cybersecurity advice. Again, it’s a subtle difference that techies get wrong. Sometimes you can’t ignore emails from unknown senders.

This happened to my mom, who continued to get confirmation emails for 6 years when somebody else tried to create a Twitter account mistyping her email address. She kept ignoring them, rather than opening a confirmation email and hitting the “reject” option. (I explain the whole thing here[*] — it was really annoying).

The conclusion of this article is that subtle technical details are meaningful. There are lots of news stories about how the FBI server was hacked. But this leads to assumptions that aren’t true, like whether any data was compromised on the server. It’s not even clear hackers broke the law here, because technically, they didn’t do anything they weren’t “authorized” by the server to do.