Today I'm going to talk about email spoofing and how it can be used to improve the quality of targeted spear phishing. I'll demonstrate a simple technique to test for potentially vulnerable SMTP servers and apply it to the Alexa top 100 sites.
Although there's nothing really original about this post after searching around it did seem there was a lack of good information and practical demonstration of this topic so hopefully this post might help fill that space.
Be warned it's a long one :)
SMTP and Email back to basics
The simple mail transfer protocol (SMTP) is the defacto way of sending email while receiving of email is performed using POP or IMAP. These services together with a sprinkle of DNS form the email system we know and love. Wikipedia had a great diagram showing how everything ties together:
Back to the 90's with Telnet and SMTP
These days most people use local or web based email clients and the details of the sending process are hidden from view. However you can still connect and communicate directly with SMTP servers using a command line tool like telnet or netcat. The basic commands you'll need are HELO, MAIL FROM, RCPT TO and DATA.
Here's an example involving the mail server for a large media organisation:
- I greet the server with a random domain instead of my own, the server does not verify that my ip and HELO domain match.
- I set the sender address (MAIL FROM), again the server doesn't verify the domain to make sure I am a test.com server.
- With the RCPT command we set the recipient. The server actual performs some verification at this point. It won't let me use an external domain in the address in order to stop mail relaying by spammers. However what about sending email to an internal recipient? The test and admin addresses were unused or blocked, but by doing a quick google I found a valid employee email address. "Recipient ok". Sweet!
- Sender sorted, recipient sorted, now we just define our message (DATA).
- And finally to send you put a dot . on a line by itself. Done.
Notice how easy it was to send a spoofed email (Email where the sender address and other parts of the email header are altered to appear as though the email originated from a different source). There was no login process, no verification of who we were and although we couldn't send email to external addresses (a.k.a Open relay), we were still free to spoof email to any employee within the organisation. Not good.
Next level spear-phishing!
So what's stopping us from spoofing email from one employee to another within the same organisation, e.g. bill@company.com to mary@company.com? If there are no mitigations on the SMTP server and no filtering on the POP server then nothing. Any external party is free to spoof email from one employee to another.
But why should you care? One big reason is spear-phishing. Spear-phishing relies on tricking users into opening attachments and following links from cleverly crafted emails. The more convincing the email the more successful the attack and what's one very easy way of making email convincing? By sending it from a legitimate address.
What about spoofing prevention?
Prevention can be performed using sender verification, reputation based systems and rate limiting. These mitigations can be applied on the SMTP server to prevent sending of malicious email or on the inbound mail gateway to filter received mail. For SMTP the site below has a great overview of securing your mail server and includes some spoofing specific protections:
http://www.vircom.com/security/top-10-tips-to-secure-your-email-server/
- SMTP authentication the sender will need to login before sending email. Although a solid mitigation, it's not practical/scalable for senders or receivers.
- A reverse DNS check can be used to confirm the sending IP has a PTR record or also to check the domain name in the HELO or MAIL FROM fields matches the PTR.
- An SPF check can be used to verify which ip addresses are authorized to send email for a particular domain by querying for an SPF DNS record. The check can be performed on the IP/HELO/MAIL FROM.
- DKIM provides a way to digitally sign messages. Receivers pull the public key from DNS to verify the sender. It applies to the header/body of the message but not the SMTP envelope.
- Monitor inbound mail for externally sourced email using your @yourdomain. Sometimes companies will have external offices/employees using the company email so you may need to do some whitelisting.
http://ask.slashdot.org/story/11/10/13/1643202/ask-slashdot-is-reverse-dns-a-worthy-standard-for-fighting-spam
Every company has different priorities and will choose to balance security and functionality differently. However even if the checks above aren't stringently enforced to block email, the rDNS/SPF/DKIM results can be combined to evaluate email (as spam filters do today).
Monitoring and filtering of emails that try to spoof your company's own domain (e.g. joe@company.com to mary@company.com) can easily be implemented on an email gateway and can give a decent security gain with minimal service impact.
...is this real life?
Lets take a look at some of these preventions in real life.
Before I got the chance to enter any commands Facebook performed a reverse DNS lookup on my IP. On my home internet connection my ISP has not defined a PTR record for my IP, so the check fails and the connection is dropped.
Ebay
My IP was on a blacklist so before i could enter any commands Ebay closed the connection. Time to change IP!
Google didn't appear to force any checks on the SMTP server, instead they seemed to focus on clever filtering on the receiving end:
The Gmail spam filter is pretty complex taking into account multiple factors. Interestingly SPF is taken into account but not required for an email to be classed as legit. In the valid email above you can see some of the checks being performed. This link has more info: http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=1366858&expand=5
Spoofed Example:
I received a spoofed message from bbc.co.uk and Gmail sent the message to the spam folder. The "neutral" error message was quite interesting. Looking at the BBC SPF record:
Related to Gmail spoofing is the awesome story of the guy who cracked Google's DKIM allowing him to spoof email to Google addresses, worth a read: http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/all/
So those are some of the big guys. But what about everyone else? What about the average corporate mail server, does it use protection..?
Spoofing the Alexa Top 100
I was curious how many companies were open to spoofing so I created a simple test script that would connect to a server, supply an invalid HELO and a spoofed MAIL FROM using that company's domain. As most mitigations should have kicked in by this point, if you receive a "Sender ok" chances are the server will send your spoofed mail.
And what better place to test this script than the Alexa Top 100!
1. Creating a list of mail servers
I first compiled a list of the Alexa Top 100 mail servers using a bit of curl/grep/nslookup magic.
for i in `seq 0 3`; do host=$(curl -s "http://www.alexa.com/topsites/global;$i"|grep "<span class=\"small topsites-label\">"|cut -d ">" -f2|cut -d "<" -f1);for j in $host; do mx=$(nslookup -query=mx $j|grep 'mail exchanger'|cut -d " " -f5|sed 's/\.$//g');for k in $mx; do echo $j $k >> mxlist;done;done;done;
This will output a file containing a list of domains and corresponding mail servers, one per line.
Note: Most companies have multiple SMTP servers. This script will return ALL of the mail servers.
2. Script to spoof servers
I created a python script to test for servers that would accept a bogus HELO and spoofed MAIL FROM using their own domain.
#!/usr/bin/python
import socket
import time
helo = "HELO test.com\r\n"
fname = "/mxlist"
lines = [line.strip() for line in open(fname)]
for i in lines:
site = i.split(' ')
mailfrom = "MAIL FROM: <pwned@" + site[0] + ">\r\n"
try:
socket.setdefaulttimeout(7)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((site[1], 25))
print site[0], "***",
print s.recv(1024).rstrip(), "***",
s.send(helo)
print s.recv(1024).rstrip(), "***",
s.send(mailfrom)
print s.recv(1024).rstrip(), "***"
s.send("quit\r\n")
s.close()
except Exception, e:
print i + "***" + str(e)
There's a lot of ways you could output the data, I decided to just print out the domain and responses from the SMTP server separated by *** for easy splitting in Excel.
If you modify the script remember to include the \r\n after each command. Without it the SMTP server won't respond. This had me stumped for quite a while until I spotted the missing 0d0a using wireshark ;)
I chose to use raw python to get more granularity. You may want to consider using smtplib:
http://www.tutorialspoint.com/python/python_sending_email.htm
And for you Ruby fans out there:
https://defuse.ca/email-spoofing-in-ruby.htm
3. Analyzing the results
In the Alexa100 there are approximately 330 mail servers covering 74 unique companies. Why only 74? A number of companies such as Google, Amazon, Microsoft and Yahoo have multiple sites in the top100. For example Yahoo has, yahoo.com, yahoo.co.jp and flickr.com.
Then there's also the issue of the mail provider. 33 of the top 100 domains are either Google owned or companies that use Google mail or Postini (also Google). Microsoft as well as Netflix and Dailymotion use Microsoft's Bigfish email service. The four Amazon sites use the same Amazon mail servers, the three Yahoo sites use Yahoo mail servers and two sites, t.co (Twitter) and hao123.com (Baidu), use mail servers on their main domains.
With most sites also using multiple mail servers the analysis started to melt my brain somewhat. In the end I decided to start with a list of all the mail servers:
And here's a chart of just the top 100 sites showing potentially spoofable sites:
At first glance it looks like two thirds of the sites can be spoofed, but how accurate are the results?
Well one of the biggest flaws with my script is that the check is inconclusive. Without actually sending and receiving the email there's no way to know whether the company is using any mitigations or filters to stop spoofed messages.
Also Google makes up a large chunk of the servers. In my testing although Google SMTP servers allowed spoofing their inbound filtering correctly identified my messages as spam, so I'd class Google as spoof proof(?). No doubt there are ways around the Google filters but it's something I'll save for another post ;)
To try and improve the reliability of results I also took a look at the Alexa top 200.
So the big question is have companies accepted/partially mitigated the spoofing risk and moved on, or are they blissfully unaware of the risks and simple mitigations that can have a big impact?
Conclusion
I started this post knowing next to nothing about email spoofing. Through research and testing I've found it interesting to see just how many companies deploy relatively liberal SMTP policies.
Often security mitigations are black and white but in the case of spoofing it's more grey because of the risk of blocking legitimate mail. Although at the moment spoofing hasn't been a big priority I believe it's something people are going to be focusing on more in the future. Especially as systems become more secure and attackers transition further into social engineering.
If you work for one of the Alexa 200 affected let your CIO know he needs to update his mail servers or at least switch to Gmail ;)
I hope you guys have found this useful, as usual questions, comments (and corrections!) are always welcome.
Pwndizzle
Conclusion
I started this post knowing next to nothing about email spoofing. Through research and testing I've found it interesting to see just how many companies deploy relatively liberal SMTP policies.
Often security mitigations are black and white but in the case of spoofing it's more grey because of the risk of blocking legitimate mail. Although at the moment spoofing hasn't been a big priority I believe it's something people are going to be focusing on more in the future. Especially as systems become more secure and attackers transition further into social engineering.
If you work for one of the Alexa 200 affected let your CIO know he needs to update his mail servers or at least switch to Gmail ;)
I hope you guys have found this useful, as usual questions, comments (and corrections!) are always welcome.
Pwndizzle
