Aol Email Hacked ================== :author: Aaron Ball :email: nullspoon@iohq.net == {doctitle} 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... [quote] ____ **super_sketchymail.info**: Pssst. Hey you over there...I have a letter for you. _*sulks into the shadows*_ **gmail.com**: Okay? Lemme see... Oh look. It's a letter to frank15689@gmail.com and it's from james19875@aol.com. Okay! I'll go deliver this to him. **super_sketchymail.info**: _*continues handing out false letters*_ ____ There might be a subtle something you missed in that conversation just now. The email is coming from __super_sketchymail.info__, but the letter itself says it's from aol.com. 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 **s**ender **p**olicy **f**ramework. In a scenario where SPF was implemented, the mail server conversation would go roughly like this... [quote] ____ **super_sketchymail.info**: Pssst. Hey you over there...I have a letter for you. _*sulks into the shadows*_ **gmail.com**: Okay? Lemme see... Oh look. It's a letter to frank15689@gmail.com and it's from james19875@aol.com. Lemme check with aol.com first to make sure they say _super_sketchymail.info_ can send email on their behalf **gmail.com**: Hey **aol.com**, can *super_sketchymail.info* send email on your behalf? **AOL.com**: No they cannot! **gmail.com**: 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, super_sketchymail.info 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 super_sketchymail.info, and thus the email would not be delivered. Isn't that a great little bit of functionality? [[where-aol-went-wrong]] == Where AOL Went Wrong [[the-technical-version]] === 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 aol.com ; <<>> DiG 9.9.2-P2 <<>> -t txt aol.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32129 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;aol.com. IN TXT ;; ANSWER SECTION: aol.com. 3600 IN TXT "v=spf1 ptr:mx.aol.com ?all" aol.com. 3600 IN TXT "spf2.0/pra ptr:mx.aol.com ?all" ;; Query time: 62 msec ;; SERVER: 172.20.0.40#53(172.20.0.40) ;; 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]] === 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]] == 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 http://techcrunch.com/2014/04/21/aol-mail-hacked-with-spoofed-accounts-sending-spam/[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]] == 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 aol.com ... ;; ANSWER SECTION: aol.com. 1942 IN TXT "v=spf1 ptr:mx.aol.com include:spf.constantcontact.com include:aspmx.sailthru.com include:zendesk.com ~all" aol.com. 1942 IN TXT "spf2.0/pra ptr:mx.aol.com include:spf.constantcontact.com include:aspmx.sailthru.com include:zendesk.com ~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 link:#The_Technical_Version[ 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 (aspmx.sailthru.com 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 (aspmx.sailthru.com), 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. http://www.pcworld.com/article/2148523/aol-traces-mystery-spam-to-security-breach.html[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 link:Exim_Spam_Filtering_with_Bogofilter[how to set up a spam filter for Exim]. Category:Aol Category:Security Category:DNS // vim: set syntax=asciidoc: