Aol Email Hacked

About four days ago, my dad’s email account began spamming me. I initially thought the email looked fishy, but it had a few things about it that made it seem relatively legitemate. The first reason being that my dad frequently sends me news articles (the email had a link to a "news" article, albeit a suspicious one). The second was that the people included on the email were all people he knows. And thus, I clicked the link on my phone and it promptly took me to a website that downloaded the file "security.update.apk" to my phone. I said to myself, "Self, that looks like something bad. Better not install that."

And so I didn’t. After seeing the malicious file download though, I went back to my "dad’s" email and had a good look at the headers and there it was: several non-Aol mail servers in line, ending with my server which didn’t mark it as spam for a very key reason.

The Problem

Most people don’t know that the to, cc, bcc, subject, and body are not the only fields you can change in an email. Many who run their own mail servers for the first time have an epiphany that they can change any field on an email, including the from field. So what’s to keep us from framing Roger Rabbit? It’s very easy to send an email from someone else without actually being logged in to their account. The server conversation for that scenario would go roughly like this…​ Pssst. Hey you over there…​I have a letter for you. *sulks into the shadows* Okay? Lemme see…​ Oh look. It’s a letter to and it’s from Okay! I’ll go deliver this to him. *continues handing out false letters*

There might be a subtle something you missed in that conversation just now. The email is coming from, but the letter itself says it’s from The point here is that Gmail missed that it was a fraudulent email and now Frank has it in his inbox.

The Solution: SPF

There are many methods to detect and respond to fraudulent emails. One of them (the topic of this post) is this great thing invented by the elders of the internet called SPF, or sender policy framework. In a scenario where SPF was implemented, the mail server conversation would go roughly like this…​ Pssst. Hey you over there…​I have a letter for you. *sulks into the shadows* Okay? Lemme see…​ Oh look. It’s a letter to and it’s from Lemme check with first to make sure they say can send email on their behalf Hey, can send email on your behalf? No they cannot! Nope! They say you can’t. Sorry pal, I’m not going to deliver this.

Effectively what SPF provides is a way for a mail server to verify that the server delivering the mail is approved to do so for the given email address (the from field). In the previous conversation, was trying to deliver mail on behalf of Aol. Gmail then checked with Aol (their SPF records) and saw that their list of approved mail servers did not include, and thus the email would not be delivered.

Isn’t that a great little bit of functionality?

Where AOL Went Wrong

The Technical Version

The functionality I just described is really great…​if you have it in place. Aol does have it in place, just not correctly. A quick lookup of their DNS and we’ll see why.

Note that this DNS lookup is as of 2014.04.21.

$ dig -t txt

; <<>> DiG 9.9.2-P2 <<>> -t txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32129
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4000
;                       IN      TXT

;; ANSWER SECTION:                3600    IN      TXT     "v=spf1 ?all"                3600    IN      TXT     "spf2.0/pra ?all"

;; Query time: 62 msec
;; WHEN: Wed Apr 23 08:39:02 2014
;; MSG SIZE  rcvd: 228

The key bits in there are the two lines that have "spf1" and spf2.0" and end with "?all". Thos two DNS entries say a bit more than we’ll discuss here, so the most important bit in there for the purposes of this post is the ?all. What that says is that any host who doesn’t match any of the previous policies in any way, mark as neutral. When a server checks Aol’s DNS entries to confirm if a server is approved to send emails, instead of saying an emphatic no, it says "Yeah, sure. Whatever". I think that flag could be better described as the ambivolent flag.

The bit that ends an spf record (the all bit) can have one of four qualifiers: +, ?, \~, and -. Most SPF records (arguably all) should end with -all because that disowns all mail servers that don’t match the previous policies. Aol uses the ?all, which is neutral (as mentioned).

The Less Technical Version

Basically, the way AOL has their DNS SPF records configured, they almost approve anyone to send mail as Aol. I say almost approve because they take only a neutral standpoint on any server that tries to send mail as them. This is a huge problem because anyone who runs a mail server can spoof headers, send mail as Aol users, and services like Gmail can’t verify that it’s not from Aol, because Aol says that it’s okay for any server to send mail as them.

The quick solution here for Aol is to flip that ?all to a -all. My guess is that Aol has some vendors sending mail as them and they haven’t taken the time to put their vendors servers in DNS (easily fixable with the INCLUDE mechanism). Other than that though, there’s really no reason to have the ?all in place that I can think of (besides just not knowing how spf works).

One Final Issue

Despite Aol’s DNS mis-configuration, there is one final issue that I can’t really speak much to. It goes back to the emails I’ve been receiving from my "dad’s" email account. Each of those is written to people from his contact list, which indicates that someone was able to get in to Aol (or their user data got out) and acquire user’s contact lists. If they got their contact lists though, who knows what else they were able to get.

How big was this breach? I can’t say. Aol confirmed the breach just two days ago. Hopefully Aol doesn’t play this out poorly and try to keep everyone in the dark. I’ll post back here as I learn more.

Update: 2014.05.11

It’s actually been a while since the issue was "resolved", I just haven’t had a chance yet to post back on it. Now though, it’s snowing outside (in spring), I have a hot mug of coffee, and my cat is sleeping on the recliner instead of my keyboard. Let’s get started. First, let’s have a look at AOL’s DNS to see how they’ve done fixing it up.

$ dig -t txt

;; ANSWER SECTION:                1942    IN      TXT     "v=spf1 ~all"                1942    IN      TXT     "spf2.0/pra ~all"

It looks like they’ve certainly thoroughly updated their DNS. In application, their fix should prevent folks from being able to spoof legitemate AOL accounts, but that’s actually only because of their vendors having their DNS configured properly. To be extra clear, the reason the problem is fixed is not because AOL has actually implemented a solid fix. As mentioned earlier in the technical version section, there are four qualifiers for the trailing all bit, AOL chose to use the ~, a soft fail. This will still not disown non-AOL server sending mail as AOL. It will only "raise suspicion" for those emails. However, thanks to their vendors knowing what they’re doing ( and at least), their spf records actually end with a -all, or a hard fail.

To give a simple overview of how AOL’s DNS works now, they basically include all of their vendor’s spf records in their own spf record. That means that if any of their vendors break their own DNS to allow anyone to spoof the vendor, the "spoofers" can also apoof AOL users because AOL’s DNS is including the vendor’s bad DNS configuration. In this case though, one of AOL’s vendors (, ends with a '-all, causing AOL’s DNS configuration to be secure becuase one of their vendors made an alright decision in their configuration. Dear AOL…​

One final thing to note regarding the remainder of the breach. AOL has confirmed that there was indeed a security breach wherein the attackers gained access to user’s complete address books (email address, names, physical mailing addresses, etc) as well as encrypted security questions/answers and encrypted passwords (gosh I hope they mean hashed instead of encrypted passwords). I hope that AOL comes out with a detailed report as to how the attackers gained access to their systems. Given their mishap with DNS (benefit of the doubt), I hope the hack on their servers wasn’t nearly as obvious. Also I’d like to know for my own edification. Due to this leak, I have begun receiving an increased amount of non-AOL spam as if my email address was released to more spammers. Thanks AOL. I guess though that it was bound to happen sometime by someone. Why not AOL.. At least I got to learn how to set up a spam filter for Exim.

Update 2018.05.15

This morning I got three more spam emails from my dad’s email address. Upon inspecting the headers, I found they were not from AOL (surprise surprise).

Per this post, I checked their SPF records as of today and look what they have set…​

dig -t txt +short
"spf2.0/pra ip4: ~all"
"v=spf1 ip4: ~all"

They still have soft fails (note the ~all rather than -all at the end) on their SPF records, which allowed those emails to be sent and received with a measure of validity.

Good thing I have bogofilter scanning my email.

Last edited: 2019-09-28 23:22:07 UTC