Tedious email fraud attacks and Solutions

From: Xinlu

Recently, the most popular method of malicious stream client attacks is XSS and other WEB attacks. Taking advantage of this opportunity, I will talk about the old and cumbersome problem of email fraud by the way. Although the problem is old, it is still quite dangerous to combine social engineering and do something about Trojan fraud. For example, if you receive an email from your boss one day and give you a Word document, won't you open it? Of course, if the boss emails are opened in the virtual machine, let's talk about it.

I will not talk about how to do it. Here I will give a general description of the principle. HypothesisA@domain-a.comTo send an emailB @domain-b.com, The normal workflow is like this: User a connects to the smtp service of the smtp.domain-a.com for identity authentication, send mail content. The smtp.domain-a.com then parses the mx record of the domain-b.com to get the mx.domain-b.com, connects to the smtp service port for this mx recordA@domain-a.comThe mail sent to the mx.domain-b.com, then forwarded to the pop3.domain-b.com, sentB @domain-b.com. Here the problem comes, because the mail is sent from another smtp server, and the smtp.domain-a.com cannot have a mx.domain-b.com account, that is, the mx.domain-b.com cannot authenticate the smtp.domain-a.com. Why does the user receive the sender information in the email? This is the smtp.domain-a.com casually said. Therefore, you may receive emails from your Boss at any time, attaching a 0-day word document as an attachment ......

To solve this problem, I did some tests at night and sent a counterfeit source to hotmailAdmin@hotmail.comThe emails are identified as forged and put in the garbage bin. Other mailboxes, including gmail and yahoo, have not been effectively deployed. As for the internal work mailboxes of major enterprises, I did not dare to test it. Maybe the situation is not optimistic.

After talking about the attack, the following describes the solution. The solution may not be complete, but at least it can solve fraud emails from the domain, so that you will not receive emails that appear to be from your boss. The solution is very concise, mainly Microsoft's Sender ID Technology and yahoo's DomainKeys technology, and these two technical ideas are also very close.

The Sender ID uses DNS extension to verify whether the Sender actually comes from the domain it claims. The workflow is as follows:

The preceding process is the same as the START process. User a (Sender) sends itB @domain-b.comTo the smtp.domain-a.com. The smtp.domain-a.com claims that the sender is a user of the domain-a.com domain, sends the mail to the mx.domain-b.com (inbound e-mail server), and then forwards it to the pop3.domain-b.com. However, after a Sender ID is deployed, the mx.domain-b.com queries the SPF record for the domain-a.com domain when it receives the mail, while the SPF record holds the IP segment that allows sending the domain-a.com domain mail. Apparently, this is controlled by the owner of the domain-a.com domain name, and others cannot forge. Therefore, when an attacker impersonates a domain-b.com to send a mail to another person in the domain-b.com domain, the connected IP address is the attacker's mail server, and the queried allowed IP segment is the IP address of the domain-b.com domain company, obviously, the two IP addresses do not match, so we can see that the email is forged.

Simply put, the Sender ID is to first add an SPF record to the domain-b.com's dns server with the content of the IP segment that allows sending domain-b.com domain mail, which generally points to the smtp.domain-b.com's IP address. When you receive an email from a domain-b.com domain, match the dns spf resolution result with the connection IP address obtained at the IP layer. If the match is successful, the email is correct. If the match is not matched, the email is a fraudulent attack.

Compared with DomainKeys, DomainKeys is more secure and uses asymmetric encryption signatures, which can even prevent email tampering, but consumes a lot of system resources. The difference with Sender ID is that the DomainKeys solution does not save the IP segments allowed to relax the domain email in the domain DNS record, but saves a public key, the relative private key is saved on the SMTP server. When usersA@domain-a.comWhen sending a mail, the SMTP.domain-a.com uses the Private Key together with the header of user a's mail for RSA signature, and then attaches the signature to the mail header for sending. The public key for the domain is obtained from the _ domainkey record of the mx.domain-b.com when the mail recipient server domain-a.com receives the mail, and the digital signature contained in the mail header is verified using the public key. If the signature test fails, the email is forged. If the signature test is successful, the email is normal.

In general, both methods require the sender to make a specific record in the DNS, either the sender's IP segment or the public key. The final mail recipient compares the received mail information with the DNS-Resolved features. Matching is not a counterfeit mail. Both technologies require the support of the sender, so it is difficult to promote them. However, at least, you can enable it in your own domain to prevent attackers from forging emails in your own domain. According to the test, hotmail uses its own Sender ID Technology to recognize forged hotmail.com domain emails.