Let's think about this for a minute.
Imagine you receive this email... yay! Right? Hold on a second. Unless you're using some sort of secure email, you really don't have any proof that email came from your professor. The purpose of this article is to show you how a malicious attacker with minimal know-how and a little social engineering could take advantage of you if you're not careful.
The first thing an attacker needs is your email address. This shouldn't be very hard, especially if your teacher has bad email practices. Imagine your professor sends emails out to the whole class with everyone in the "to:" or "cc:" fields. Whoops... everyone knows all the class emails. And if your email has your name in it, it's not very hard to put two and two together. Or perhaps your school makes your email address readily available to anyone who wants to know; my school has a directory that lists not just emails, but addresses and phone numbers! Most students don't know how to opt out of the directory. That's why it's earned itself the nickname "stalkernet." My class happens to use a google group, which is really just a mailing list. Go to a list of the members and voila—emails! All of these are ways in which somebody with bad intensions could get your email address.
Now that the attacker has your email address, they need to find your mail server. Let's say you use a gmail account—the attacker opens up a shell and uses dig to find a gmail mail server (bold text indicates user input).
$ dig MX gmail.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> MX gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39505
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 3469 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3469 IN MX 10 alt1.gmail-smtp-in.l.google.com.
;; Query time: 22 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Mon Dec 13 00:42:43 2010
;; MSG SIZE rcvd: 150
By using the MX option, the attacker tells dig to look for mail servers associated with the gmail.com domain; dig responds by printing an answer section containing a list of mail servers the attacker can use. The attacker can use telnet to talk to the second mail server and send an email. Behold:
$ telnet gmail-smtp-in.l.google.com 25
Trying 74.125.155.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 11si13911500yhl.88
HELO gmail-smtp-in.l.google.com
250 mx.google.com at your service
MAIL FROM:<bob.white@cs.harvard.edu>
250 2.1.0 OK 11si13911500yhl.88
RCPT TO:<student.email@gmail.com>
250 2.1.5 OK 11si13911500yhl.88
DATA
354 Go ahead 11si13911500yhl.88
From: Bob White <bob.white@cs.harvard.com>
To: Your Name <student.email@gmail.com>
Subject:Final Exam
Hello Steve,
You've got a great grade! You don't need to come take the final. Enjoy your break!
Sincerely
-Professor White
.
250 2.0.0 OK 1292218738 11si13911500yhl.88
QUIT
221 2.0.0 closing connection 11si13911500yhl.88
Connection closed by foreign host.
The student at student.email@gmail.com will receive an email that looks exactly as if it had come from his or her professor, cs.harvard.edu email address and all!
Obviously the ability to spoof email has a lot more implications than just this. So, how do you defend against such attacks? One solution is to use secure email—either PGP or X.509 certificates and S/MIME. This is not a very viable option, however, because it requires that all parties involved use the services in order to gain any benefit, and currently it is quite the hassle to set up and use.
Your best bet? Send an email back to the professor, asking him to confirm the email (to be fair to my Professor, this was part of the opt-out process, I'm mostly just making this into a hypothetical situation). Even though they made the email look as if it came from your professor, a reply will go straight back to the real email address, which the attacker does not control. Admittedly, the attacker might be able to intercept the email and spoof a reply, but that would be a much more complicated attack. It's just your grade, not military-grade secrets here.
So, the real key is to be aware that you can never be sure email comes from who it says it does, just like in real mail. As such, use good judgement and common sense.
Obviously the ability to spoof email has a lot more implications than just this. So, how do you defend against such attacks? One solution is to use secure email—either PGP or X.509 certificates and S/MIME. This is not a very viable option, however, because it requires that all parties involved use the services in order to gain any benefit, and currently it is quite the hassle to set up and use.
Your best bet? Send an email back to the professor, asking him to confirm the email (to be fair to my Professor, this was part of the opt-out process, I'm mostly just making this into a hypothetical situation). Even though they made the email look as if it came from your professor, a reply will go straight back to the real email address, which the attacker does not control. Admittedly, the attacker might be able to intercept the email and spoof a reply, but that would be a much more complicated attack. It's just your grade, not military-grade secrets here.
So, the real key is to be aware that you can never be sure email comes from who it says it does, just like in real mail. As such, use good judgement and common sense.
2 comments:
I just found your blog and found it very interesting.
This mail thingy doesn't seem to work anymore though. I'm getting this error:
550-5.7.1 [77.56.154.147] The IP you're using to send mail is not authorized to
550-5.7.1 send email directly to our servers. Please use the SMTP relay at your
550-5.7.1 service provider instead. Learn more at
550 5.7.1 http://mail.google.com/support/bin/answer.py?answer=10336 s8si11620710eeh.7
Connection closed by foreign host.
Seems like gmail's suited up.
Strange, I just tried it again and it worked for me. I'm by no means an expert on SMTP, but it looks like because of spammers some servers don't allow people to send mail directly. Did you try sending to all of the servers on the list? Maybe you're coming from another country where Google blacklists IP Addresses because of spammers? That's about all the ideas I have.
Post a Comment