Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CVE-2019-15237] IDN homograph attack when displaying e-mail addresses. #6891

Closed
juliocesarfort opened this issue Aug 18, 2019 · 11 comments
Closed

Comments

@juliocesarfort
Copy link

Homograph attack is a security vulnerability that can deceive users into thinking they are visiting a certain website or the origin of an e-mail when in fact it is a different, but homograph, domain name. This type of vulnerability can be used to weaponize social engineering, significantly increasing the chances for a successful attack.

I have created a homograph of here.com using purely cyrillic characters http://һеге.com/ -- (the punycode is xn--c1adb74c.com). I have other homographs, too, and registering them isn't a big deal.

So I have sent an e-mail from info@xn--c1adb74c.com as SMTP, DNS, etc. only handle ASCII. However, for the sake of user-friendliness, Roundcube will convert the domain name from ASCII to Unicode, without taking into consideration confusables. Therefore, the user will see the e-mail as coming from @here.com when in fact it came from another domain, xn--c1adb74c.com.

In the case of here.com, the 'r' looks a bit off but this largerly depends on the display, system fonts, etc. Other confusables are completely visually indistinguishable.

I have attached an example of an e-mail coming from xn--c1adb74c.com when rendered in Roundcube.

roundcube

Cheers,
Julio

@alecpl
Copy link
Member

alecpl commented Aug 19, 2019

This is not going to be simple to fix. Some references:
https://en.wikipedia.org/wiki/IDN_homograph_attack
https://bugzilla.mozilla.org/show_bug.cgi?id=279099
https://dev.to/logan/homographs-attack--5a1p
https://www.chromium.org/developers/design-documents/idn-in-google-chrome

I guess this should become part of a bigger anti-phishing solution together with e.g. #5627.

@alecpl alecpl added this to the later milestone Aug 19, 2019
@arnt
Copy link

arnt commented Aug 20, 2019

This has been discussed several times in the context of EAI, and AFAICT there's nothing particular about it. Impersonators can and do impersonate here.com using "HERE Support <37298423@8904238490asdf.sar8wejfsd.com>", ie. a perfect match on the display-name and no match on localpart/domain.

However: Why does roundcube convert xn--blah to human-friendly letters? None of the email RFCs require that, and so far I haven't come across any non-evil mail program that generates xn--blah.

@alecpl
Copy link
Member

alecpl commented Aug 20, 2019

@arnt we can't do much about the case you describe, but we can protect users from the cases described in the ticket. Did you read references? Do you know how web browsers or other mail clients deal with this? Here's some RFCs about IDN: 5890, 5891

@arnt
Copy link

arnt commented Aug 21, 2019

@alecpl I read what was available when we discussed the issue while RFCs 6532 and 6858 were being written; from a quick glance nothing significant has changed since.

As far as I know (which might be described as "middling"), noone tries to defend specifically against this issue. Some browsers and at least one email client defends against impersonation in general using Google's Safe Browsing API, which will tell you whether Google thinks a particular link points to "social engineering sites (phishing and deceptive sites) and sites that host malware or unwanted software". Safe Browsing doesn't distinguish between an attack based on homographs and one based on name similarity (say postbank-kundendienst.de), they're both just deceptive.

@alecpl
Copy link
Member

alecpl commented Aug 21, 2019

As I understand, the idea of IDNA is that end users see human-readable names in UI, punnycode is for communication between servers. I don't remember if that's mentioned in any RFC directly, but this is what most apps do.

Of course, Thunderbird has an option to disable conversion to UTF8. We might consider such an option in Roundcube, but as an additional feature, not the real fix.

If you read https://www.chromium.org/developers/design-documents/idn-in-google-chrome you'll see that browsers have policies to protect from IDN homograph attacks. While this might free us from securing normal links in email bodies, it does not free us from a need to secure displaying of email addresses.

@arnt
Copy link

arnt commented Aug 21, 2019

FYI: Since around 2012, email may use UTF8 almost everywhere where it was necessary to encode using using q-p encoding, 2046/2231, xn--blah before. This message is perfectly valid. The experimental RFCs from around 2006 were deprecated at the same time. At one of the meetings, someone said that by now, all implementations of the experimental RFCs have been updated or removed from the old download locations.

People regularly suggest that it's necessary to distinguish between ASCII originals and non-ASCII homographs, but it seems like a half-solution to me: Doesn't help against the typical attack and doesn't protect non-ASCII names such Міст (a Ukrainian company the only cyrillic one I remember offhand). Why bother with protecting against one case when it isn't general, nor the most common case, nor significantly exploited?

@alecpl alecpl changed the title IDN homograph attack when displaying e-mail addresses. [CVE-2019-15237] IDN homograph attack when displaying e-mail addresses. Aug 30, 2019
@alecpl alecpl modified the milestones: later, 1.5-beta Sep 30, 2020
@alecpl alecpl modified the milestones: 1.5-beta, 1.5-rc Dec 28, 2020
@zlobniyshurik
Copy link

What if any nonASCII symbols will be highlighted by other color?

Example:
boss@example.com - email address with pure ASCII letters
boss@ехаmple.com - email address with cyrillic letters е, х,а in domain name

@alecpl
Copy link
Member

alecpl commented Feb 13, 2021

https://www.php.net/manual/en/class.spoofchecker.php would be the engine to detect the spoofed domains. The question is how to display these. I think highlighting letters (and removing links?) might not be the best way. Maybe use a red color and add title attribute with a warning. Or display a general warning (like we do for external resources in HTML message) stating that some email addresses in the message might be spoofed. We'd need to find a proper wording to not confuse users.

@johndoh
Copy link
Contributor

johndoh commented Feb 13, 2021

I like the idea of a general warning like the external links one. I wonder if only colouring of the text to red might be too easy to miss.

This message contains suspicious sender information and may be fraudulent
This message contains suspicious links and may be fraudulent

or may be...

To protect your privacy potentially dangerous links have been disabled/removed.

In the case of spoofed senders perhaps a warning could be displayed if the user clicks reply? I'm not sure if that is even possible or may be its overkill, may be if a dialog comes up with the reply address and the suspicious characters highlighted in red and asks the user to retype the address to confirm it is correct? If an address was in trusted senders it could by pass this.

@arnt
Copy link

arnt commented Feb 15, 2021

Red often means important (as does any emphasis).

A domain such as postbank.de is often spoofed as postbank123@outlook.com, postbank.0mm.net or postbank-service.com. A user who sees postbаnk.0mm.org (note the cyrillic а) in red and is used to unmarked spoofing might reasonably think the red indicates that it is NOT the usual spoofing, but rather an important message from postbank.

@alecpl
Copy link
Member

alecpl commented Mar 21, 2021

While there's a place for improvement I consider this fixed.

@alecpl alecpl closed this as completed Mar 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants