1131817 - Potential email spoofing due to mixed-case display of email domains (homograph attacks)

Status: NEW

(Thunderbird :: Message Reader UI, defect)

Description

[b+bugzilla]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

Steps to reproduce:

1) register a domain which is similar to established email providers replacing all occurences of the letter "l" by "i" (e.g. gmail.com becomes gmaii.com)

2) send a mail:

	baduser@attaking-mail-server:~# sendmail -t
	To: [e-mail]
	From: [e-mail]
	Subject: Who is the sender?
	Content-Type: text/plain
	
	I love sans-serif.
	.

(note that the email is not being sent from gmail.com, but from gmaiI.com, the "I" of the second domain being an uppercase "i")

3) have the victim receive and reply to the mail

4) receive the reply to gmaii.com which is under your control


Actual results:

The email is delivered without problems as there are no SPF-validation-issues. However, if one does not watch very closely, one does not see that the email is not really coming from [e-mail] as expected, but from [e-mail]. This may cause potential advanced email spoofing attacks allowing the attacker to receive the reply to those emails.


Expected results:

The domain part of the sender email address could/should have been transformed into lower case as it happens to domains in currently all major browsers in order to prevent spoofing attacks. This is also the default behaviour of many email clients but Thunderbird.

Comment 1

[WADA:World Anti-bad-Duping Agency]

What is actual problem?

> one does not see that the email is not really coming from [e-mail] as expected

In email system, mail sender can put any data in From: header, etc. because SMTP mail transmission doesn't care about "Message header" nor "dataa in mail".
To pass mail address of mail sender and mail recipients to SMTP server, FROM command and RCPT commnd is used.
Mail sender can use different mail addres for FROM/RCPT and From: header and To:/CC: header in mail data.

i.e. There is no gurantee of "message header in message  source is absolutely correct/proper/valid" in current email system.

When mail recipient want to send reply, mail recipients request to send reply mail to "mail address writen in From: header". So, who sends a mail to someone usulaly writes his mail address in From: header of  mail, because if he wrote different mail address, he can not receive reply mail.
And, many mailer usually requests to SMTP server with FROM=mail address in From: header of the mail, RECPT=mail address in To:/CC:/BCC: header of mail, so "mail address in message source" is usually correct one.

And, "the mail should be transfered to which server" is determined from domainpart of localpart@dominpart, and domainprt is registered to DNS server.
And, hostname in DNS is case insensitive. (fonnd by simple Google search for "fqdn case sensitive")
> http://serverfault.com/questions/261341/is-the-hostname-case-sensitive

Queston again. What is actual problem of this bug?
If you want to say "problem exists", it's perhaps problem like "attack to people who owns abc@a.b.c, by sendng many mails with From:abc@a.b.c to many peoples". If many peoples sends reply to the mail, many mails will be sent to people who owns abc@a.b.c.
However, if spmmer want to send many mails to abc@a.b.c, "spammer sends many maitls to abc@a.b.c" is sufficient and effective, and spammers currently does do so.

Please distingush with problem of "spoofing by unicode character of similar Glyph in IDN".
   ™ 　 : U+2122
   TM   : ascii T + ascii M
   In IDN,  A™  != ATM, so @A™ and @ATM is different domain, but some font may show similar Glyph.
   In such case, user thinks "he sent mail  to abc@ATM", but "mail is sent to abc@A™" can happen.
This kind of issue is already recognized well, and IIUC, "different IDN with unicode character of similar Glyph" is already rejected upon FQDN registration.

Comment 2

[b+bugzilla]

(In reply to WADA from comment #1)
> What is actual problem?

The concern is not that one could abuse this "bug" for spam but that targetted spoofing attacks could be performed.

> problem of "spoofing by unicode character of similar Glyph in IDN".
That seems to be similar to what I am aiming at. If I was the owner of "gmaii.com", I could easily send an email from that domain, spelling it "gmaiI.com". This domain being displayed in Thunderbird looks almost exactly like "gmail.com".
If I was an attacker, I could abuse that. In contrary to "normal" email spoofing, I can now receive the replies to the spoofed email address which is not possible if I cannot control the domain which was spoofed. Just spoofing "gmail.com", I would not receive replies to that mail. In this case, I have access to "gmaii.com" which means I can receive replies.

Comment 3

[b+bugzilla]

Possibly, the word "spoofing" is a bit misleading as spoofing is not really required. If one can control "gmaii.com", one does not require spoofing the source address, just making the second "i" uppercase so that the domain looks like "gmail.com".

Comment 4

[WADA:World Anti-bad-Duping Agency]

My point/question is :
If you are trying to talk about "IDN homograph attack", your claim is absolutely invalid, because "IDN homograph attack" is never based on "case of letter" and "case of a letter" is irrelevant to "server name in DNS".
".com", ".COM", ".Com", ".cOm", ".coM", ... , are same domain.

Example of "IDN homograph attack" in 7bits-ascii world.
> http://en.wikipedia.org/wiki/IDN_homograph_attack
>    google.com  (lower "l" of upper "L")
>    googIe.com (upper "I" of lower "i")

Bug based on wrong/incorrect/invalid/improper assumption is INVALID even at B.M.O where anyone can open any bug.

Comment 5

[b+bugzilla]

> https://en.wikipedia.org/wiki/IDN_homograph_attack#Homographs_in_ASCII
Why is the claim invalid?

Comment 6

[b+bugzilla]

My point is simple: If Thunderbird would always display sender email addresses with the domain part transformed to lower case (which is done by many other email clients), it would be more difficult to spoof emails based on a ASCII-homograph attack.
Thunderbird could simply display an email coming from "[e-mail]" as "[e-mail]" so that an average user would directly notice that the email is NOT coming from "google.com". This would also prevent similarities of "0" and "O" in the domain part.

Comment 7

[WADA:World Anti-bad-Duping Agency]

If you are talking about "IDN homograph attack", "due to case-sensitive domain" part  is wrong, because server name in DNS is case insensitive.
"Always show domainpart in lower case" part is correct request, because "spoof l by I" can be reduced simply by "show in lower case", as you say.

Comment 8

[b+bugzilla]

I am sorry for the communication problem because I never intended to say that domains are case-sensitive. What I actually meant is the case-sensitive display of the domain part in Thunderbird. I have corrected the title to make the issue more understandable.

Comment 9

[WADA:World Anti-bad-Duping Agency]

Thanks for bug summary change.

Comment 10

[Thomas D. (:thomas8)]

Thanks b+bugzilla for filing this, and thanks for your patience. Showing all email addresses / domains in the main UI normalized to lowercase looks like a valid request to reduce the risk of spoofing attacks -> confirming.

TB is run by volunteers whose manpower is limited; would you be able to try and fix this yourself?