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
Comments
|
This is not going to be simple to fix. Some references: I guess this should become part of a bigger anti-phishing solution together with e.g. #5627. |
|
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 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. |
|
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. |
|
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? |
|
What if any nonASCII symbols will be highlighted by other color? Example: |
|
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 |
|
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 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. |
|
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. |
|
While there's a place for improvement I consider this fixed. |
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.
Cheers,
Julio
The text was updated successfully, but these errors were encountered: