reader comments
46 with 39 posters participating
If you receive an email from someone@arstechnіca.com, is it really from someone at Ars? Most definitely not—the domain in that email address is not the same arstechnica.com that you know. The ‘і’ character in there is from the Cyrillic script and not the Latin alphabet.
This isn’t a novel problem, either. Up until a few years ago (but not anymore), modern browsers did not make any visible distinction when domains containing mixed character sets were typed into the address bar.
And it turns out Microsoft Outlook is no exception, but the problem just got worse: emails originating from a lookalike domain in Outlook would show the contact card of a real person, who is actually registered to the legitimate domain, not the lookalike address.
Outlook shows real contact’s info for spoofed IDN domains
This week, infosec professional and pentester DobbyWanKenobi demonstrated how they were able to trick the Address Book component of Microsoft Office to display a real person’s contact info for a spoofed sender email address by using IDNs. Internationalized Domain Names (IDNs) are domains consisting of a mixed Unicode character set, such as letters from both Latin and Cyrillic alphabets that could make the domain appear identical to a regular ASCII domain.
The concept of IDN was proposed in 1996 to expand the domain name space to non-Latin languages and to deal with the aforementioned ambiguity of different characters that look identical (“homoglyphs”) to humans. IDNs can also easily be represented purely in ASCII format—the “punycode” version of the domain, which leaves no room for ambiguity between two lookalike domains.
For example, copy-pasting the lookalike “arstechnіca.com” into the address bar of the latest Chrome browser would immediately turn it into its punycode representation to prevent ambiguity: xn--arstechnca-42i.com. This does not happen when actual arstechnica.com—already in ASCII and without the Cyrillic ‘і’, is typed into the address bar. Such visible distinction is necessary to protect the end users who may inadvertently land on imposter websites, used as part of phishing campaigns.
blog post. “This means if a company’s domain is ‘somecompany[.]com’, an attacker that registers an IDN such as ‘ѕomecompany[.]com’ (xn--omecompany-l2i[.]com) could take advantage of this bug and send convincing phishing emails to employees within ‘somecompany.com’ that used Microsoft Outlook for Windows.”
Coincidentally, the following day, another report on the topic emerged from Mike Manzotti, a senior consultant at Dionach. For a contact created on Manzotti’s “onmìcrosoft.com” domain (notice the ì), Outlook displayed valid contact details of the person whose email address contained the real “onmicrosoft.com” domain.
“In other words, the phishing email targets the user NestorW@….onmìcrosoft.com, however, valid Active Directory details and image of NestorW@….onmicrosoft.com are displayed as if the email was coming from a trusted source,” says Manzotti.
Manzotti has traced the cause of the issue to Outlook not correctly validating email addresses in Multipurpose Internet Mail Extensions (MIME) headers.
“When you send an HTML email you can specify the SMTP ‘mail from’ address, and the Mime ‘from’ address,” explains Manzotti.
“This is because the MIME headers are encapsulated into the SMTP protocol. MIME is used for extending simple text messages, for example when sending HTML emails,” he explained with an illustration:
But, according to Manzotti, Microsoft Outlook for Office 365 does not correctly verify the punycode domain, letting an attacker impersonate any valid contact in the target organization.
IDN phishing: An old problem revived
The problem of IDN-based phishing websites gained the spotlight in 2017 when web application developer Xudong Zheng demonstrated how modern browsers, at the time, failed to distinguish his аpple.com look-alike site (an IDN) from the real apple.com.
concerned that IDNs could be abused by attackers for various nefarious purposes such as phishing:
From a security perspective, Unicode domains can be problematic because many Unicode characters are difficult to distinguish from common ASCII characters. It is possible to register domains such as “xn--pple-43d.com”, which is equivalent to “аpple.com”. It may not be obvious at first glance, but “аpple.com” uses the Cyrillic “а” (U+0430) rather than the ASCII “a” (U+0061). This is known as a homograph attack.
But the problem in Outlook is that for a phishing email sent from an IDN, the recipient may not only fail to distinguish between the spoofed email address and the real one but also see the contact card of a legitimate contact, therefore falling victim to the attack.
It is unclear if Microsoft is inclined to fix the issue in Outlook at this time:
“We’ve finished going over your case, but in this instance, it was decided that we will not be fixing this vulnerability in the current version,” a Microsoft staff member is seen telling DobbyWanKenobi in an email.
“While spoofing could occur, the sender’s identity cannot be trusted without a digital signature. The changes needed are likely to cause false positives and issues in other ways,” continued the email seen by Ars:
Microsoft has not responded to Ars’ request for comment sent out in advance.
Researchers have seen this vulnerability impacting both 32-bit and 64-bit versions of the latest Microsoft Outlook for Microsoft 365 versions, although it appears the issue was no longer reproducible on version 16.0.14228.20216 after Manzotti notified Microsoft.
Oddly enough, Microsoft’s response to Manzotti maintained that the vulnerability will not be fixed. Additionally, Manzotti notes this type of phishing attack won’t succeed on Outlook Web Access (OWA).
Taking advantage of security features such as “external sender” email warnings and email signing are a few steps organizations can take to deter spoofing attacks.
