1 Aol Email Hacked
2 ==================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5
6 == {doctitle}
7
8 About four days ago, my dad's email account began spamming me. I initially
9 thought the email looked fishy, but it had a few things about it that made it
10 seem relatively legitemate. The first reason being that my dad frequently sends
11 me news articles (the email had a link to a "news" article, albeit a suspicious
12 one). The second was that the people included on the email were all people he
13 knows. And thus, I clicked the link on my phone and it promptly took me to a
14 website that downloaded the file "security.update.apk" to my phone. I said to
15 myself, "Self, that looks like something bad. Better not install that."
16
17 And so I didn't. After seeing the malicious file download though, I went back
18 to my "dad's" email and had a good look at the headers and there it was:
19 several non-Aol mail servers in line, ending with my server which didn't mark
20 it as spam for a very key reason.
21
22
23 == The Problem
24
25 Most people don't know that the to, cc, bcc, subject, and body are not the only
26 fields you can change in an email. Many who run their own mail servers for the
27 first time have an epiphany that they can change any field on an email,
28 including the *from* field. So what's to keep us from framing Roger Rabbit?
29 It's very easy to send an email from someone else without actually being logged
30 in to their account. The server conversation for that scenario would go roughly
31 like this...
32
33 [quote]
34 ____
35 **super_sketchymail.info**: Pssst. Hey you over there...I have a letter for
36 you. _*sulks into the shadows*_
37
38 **gmail.com**: Okay? Lemme see... Oh look. It's a letter to
39 frank15689@gmail.com and it's from james19875@aol.com. Okay! I'll go deliver
40 this to him.
41
42 **super_sketchymail.info**: _*continues handing out false letters*_
43 ____
44
45 There might be a subtle something you missed in that conversation just now. The
46 email is coming from __super_sketchymail.info__, but the letter itself says
47 it's from aol.com. The point here is that Gmail missed that it was a fraudulent
48 email and now Frank has it in his inbox.
49
50
51 == The Solution: SPF
52
53 There are many methods to detect and respond to fraudulent emails. One of them
54 (the topic of this post) is this great thing invented by the elders of the
55 internet called SPF, or **s**ender **p**olicy **f**ramework. In a scenario
56 where SPF was implemented, the mail server conversation would go roughly like
57 this...
58
59 [quote]
60 ____
61 **super_sketchymail.info**: Pssst. Hey you over there...I have a letter for
62 you. _*sulks into the shadows*_
63
64 **gmail.com**: Okay? Lemme see... Oh look. It's a letter to
65 frank15689@gmail.com and it's from james19875@aol.com. Lemme check with aol.com
66 first to make sure they say _super_sketchymail.info_ can send email on their
67 behalf
68
69 **gmail.com**: Hey **aol.com**, can *super_sketchymail.info* send email on your
70 behalf?
71
72 **AOL.com**: No they cannot!
73
74 **gmail.com**: Nope! They say you can't. Sorry pal, I'm not going to
75 deliver this.
76 ____
77
78 Effectively what SPF provides is a way for a mail server to verify that the
79 server delivering the mail is approved to do so for the given email address
80 (the _from_ field). In the previous conversation, super_sketchymail.info was
81 trying to deliver mail on behalf of Aol. Gmail then checked with Aol (their
82 SPF records) and saw that their list of approved mail servers did not include
83 super_sketchymail.info, and thus the email would not be delivered.
84
85 Isn't that a great little bit of functionality?
86
87
88 [[where-aol-went-wrong]]
89 == Where AOL Went Wrong
90
91 [[the-technical-version]]
92 === The Technical Version
93
94 The functionality I just described is really great...if you have it in
95 place. Aol _does_ have it in place, just not correctly. A quick lookup
96 of their DNS and we'll see why.
97
98 **Note** that this DNS lookup is as of 2014.04.21.
99
100 ----
101 $ dig -t txt aol.com
102
103 ; <<>> DiG 9.9.2-P2 <<>> -t txt aol.com
104 ;; global options: +cmd
105 ;; Got answer:
106 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32129
107 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
108
109 ;; OPT PSEUDOSECTION:
110 ; EDNS: version: 0, flags:; udp: 4000
111 ;; QUESTION SECTION:
112 ;aol.com. IN TXT
113
114 ;; ANSWER SECTION:
115 aol.com. 3600 IN TXT "v=spf1 ptr:mx.aol.com ?all"
116 aol.com. 3600 IN TXT "spf2.0/pra ptr:mx.aol.com ?all"
117
118 ;; Query time: 62 msec
119 ;; SERVER: 172.20.0.40#53(172.20.0.40)
120 ;; WHEN: Wed Apr 23 08:39:02 2014
121 ;; MSG SIZE rcvd: 228
122 ----
123
124
125 The key bits in there are the two lines that have "spf1" and spf2.0" and
126 end with "?all". Thos two DNS entries say a bit more than we'll discuss
127 here, so the most important bit in there for the purposes of this post
128 is the **?all**. What that says is that any host who doesn't match any
129 of the previous policies in any way, mark as neutral. When a server
130 checks Aol's DNS entries to confirm if a server is approved to send
131 emails, instead of saying an emphatic __no__, it says "__Yeah, sure.
132 Whatever__". I think that flag could be better described as the
133 ambivolent flag.
134
135 The bit that ends an spf record (the _all_ bit) can have one of four
136 qualifiers: +, ?, \~, and -. Most SPF records (arguably all) should end
137 with _-all_ because that disowns all mail servers that don't match the
138 previous policies. Aol uses the __?all__, which is neutral (as
139 mentioned).
140
141
142 [[the-less-technical-version]]
143 === The Less Technical Version
144
145 Basically, the way AOL has their DNS SPF records configured, they almost
146 approve anyone to send mail as Aol. I say _almost approve_ because they take
147 only a neutral standpoint on any server that tries to send mail as them. This
148 is a huge problem because anyone who runs a mail server can spoof headers, send
149 mail as Aol users, and services like Gmail can't verify that it's not from Aol,
150 because Aol says that it's okay for any server to send mail as them.
151
152 The quick solution here for Aol is to flip that *?all* to a **-all**. My guess
153 is that Aol has some vendors sending mail as them and they haven't taken the
154 time to put their vendors servers in DNS (easily fixable with the INCLUDE
155 mechanism). Other than that though, there's really no reason to have the ?all
156 in place that I can think of (besides just not knowing how spf works).
157
158
159 [[one-final-issue]]
160 == One Final Issue
161
162 Despite Aol's DNS mis-configuration, there is one final issue that I can't
163 really speak much to. It goes back to the emails I've been receiving from my
164 "dad's" email account. Each of those is written to people from his contact
165 list, which indicates that someone was able to get in to Aol (or their user
166 data got out) and acquire user's contact lists. If they got their contact lists
167 though, who knows what else they were able to get.
168
169 How big was this breach? I can't say. Aol
170 http://techcrunch.com/2014/04/21/aol-mail-hacked-with-spoofed-accounts-sending-spam/[confirmed
171 the breach] just two days ago. Hopefully Aol doesn't play this out poorly and
172 try to keep everyone in the dark. I'll post back here as I learn more.
173
174
175 [[update-2014.05.11]]
176 == Update: 2014.05.11
177
178 It's actually been a while since the issue was "resolved", I just haven't had a
179 chance yet to post back on it. Now though, it's snowing outside (in spring), I
180 have a hot mug of coffee, and my cat is sleeping on the recliner instead of my
181 keyboard. Let's get started. First, let's have a look at AOL's DNS to see how
182 they've done fixing it up.
183
184
185 ----
186 $ dig -t txt aol.com
187
188 ...
189 ;; ANSWER SECTION:
190 aol.com. 1942 IN TXT "v=spf1 ptr:mx.aol.com include:spf.constantcontact.com include:aspmx.sailthru.com include:zendesk.com ~all"
191 aol.com. 1942 IN TXT "spf2.0/pra ptr:mx.aol.com include:spf.constantcontact.com include:aspmx.sailthru.com include:zendesk.com ~all"
192 ...
193 ----
194
195
196 It looks like they've certainly thoroughly updated their DNS. In application,
197 their fix _should_ prevent folks from being able to spoof legitemate AOL
198 accounts, but that's actually only because of their vendors having their DNS
199 configured properly. To be extra clear, the reason the problem is fixed is not
200 because AOL has actually implemented a solid fix. As mentioned earlier in
201 link:#The_Technical_Version[ the technical version section], there are four
202 qualifiers for the trailing _all_ bit, AOL chose to use the **~**, a soft fail.
203 This will still not disown non-AOL server sending mail as AOL. It will only
204 "raise suspicion" for those emails. However, thanks to their vendors knowing
205 what they're doing (aspmx.sailthru.com and at least), their spf records
206 actually end with a __-all__, or a hard fail.
207
208 To give a simple overview of how AOL's DNS works now, they basically include
209 all of their vendor's spf records in their own spf record. That means that if
210 any of their vendors break their own DNS to allow anyone to spoof the vendor,
211 the "spoofers" can also apoof AOL users because AOL's DNS is including the
212 vendor's bad DNS configuration. In this case though, one of AOL's vendors
213 (aspmx.sailthru.com), ends with a __'-all__, causing AOL's DNS configuration to
214 be secure becuase one of their vendors made an alright decision in their
215 configuration. Dear AOL...
216
217 One final thing to note regarding the remainder of the breach.
218 http://www.pcworld.com/article/2148523/aol-traces-mystery-spam-to-security-breach.html[AOL
219 has confirmed] that there was indeed a security breach wherein the attackers
220 gained access to user's complete address books (email address, names, physical
221 mailing addresses, etc) as well as encrypted security questions/answers and
222 encrypted passwords (gosh I hope they mean hashed instead of encrypted
223 passwords). I hope that AOL comes out with a detailed report as to how the
224 attackers gained access to their systems. Given their mishap with DNS (benefit
225 of the doubt), I hope the hack on their servers wasn't nearly as obvious. Also
226 I'd like to know for my own edification. Due to this leak, I have begun
227 receiving an increased amount of non-AOL spam as if my email address was
228 released to more spammers. Thanks AOL. I guess though that it was bound to
229 happen sometime by someone. Why not AOL.. At least I got to learn
230 link:Exim_Spam_Filtering_with_Bogofilter[how to set up a spam filter for Exim].
231
232 Category:Aol
233 Category:Security
234 Category:DNS
235
236
237 // vim: set syntax=asciidoc:
|
