Microsoft Outlook displays real person’s contact information for IDN phishing emails


Shaded figures lie beneath a Microsoft logo on a faux wood wall.

If you receive an email from [email protected]іca.comIs it really from someone from Ars? Definitely not, the domain at that email address is not the same arstechnica.com that you know The character ‘і’ found there comes from the Cyrillic script and not from the Latin alphabet.

This is not a new problem either. Until a few years ago (but not anymore), modern browsers did not make any visible distinctions when typing domains containing mixed character sets in the address bar.

And it turns out that Microsoft Outlook is no exception, but the problem got worse: emails originating from a similar domain in Outlook were showing the contact card of a real person, which is actually registered with the legitimate domain, not the address Similary.

Outlook displays real contact information for spoofed IDN domains

This week, infosec professional and pentester DobbyWanKenobi demonstrated how they were able to trick the Microsoft Office Address Book component into displaying a real person’s contact information for a spoofed sender email address by using IDNs. Internationalized domain names (IDN) are domains that consist of a mixed set of Unicode characters, such as letters in the Latin and Cyrillic alphabets that could make the domain appear identical to a normal ASCII domain.

The concept of IDN was proposed in 1996 to extend the domain name space to non-Latin languages ​​and to address the aforementioned ambiguity of different characters appearing identical (“homoglyphs”) to humans. IDNs can also be easily represented in ASCII format onlythe “punycode” version of the domain, which leaves no room for ambiguity between two similar domains.

For example, copying and pasting the resemblance “arstechnіca.com” into the address bar of the latest Chrome browser would immediately make it your puny code representation to avoid ambiguity: xn--arstechnca-42i.com. This does not happen when real arstechnica.comalready in ASCII and without the Cyrillic ‘і’, it is written in the address bar. This visible distinction is necessary to protect end users who may inadvertently land on imposter websites, used as part of phishing campaigns.

But recently, DobbyWanKenobi found that this was not entirely obvious with Microsoft Outlook for Windows. And the Address Book feature would make no distinction when displaying the person’s contact details.

“I recently discovered a vulnerability affecting the address book component of Microsoft Office for Windows that could allow anyone on the Internet to spoof the contact details of employees within an organization using a similar external internationalized domain name (IDN) “wrote the pentester. in a blog post. “This means that if the domain of a company is’ some company[.]com ‘, an attacker who registers an IDN as’ a company[.]com ‘(xn – omecompany-l2i[.]com) could exploit this bug and send compelling phishing emails to ‘somecompany.com’ employees using Microsoft Outlook for Windows. “

Coincidentally, the next day, another report The topic came from Mike Manzotti, Dionach’s senior consultant. For a contact created in the domain “onmìcrosoft.com” of Manzotti (see the I), Outlook displayed valid contact details for the person whose email address contained the actual domain “onmicrosoft.com”.

“In other words, the phishing email is directed to the user NestorW @ …. onmIcrosoft.com, however, the valid Active Directory details and NestorW @ …. onmicrosoft.com image are displayed as if the email came from a trusted source, “says Manzotti.

Manzotti has traced the cause of the problem until Outlook does not correctly validate email addresses in MIME (Multipurpose Internet Mail Extensions) headers.

“When you send an HTML email, you can specify the SMTP ‘sender’ address and the Mime sender address,” explains Manzotti.

“This is because MIME headers are encapsulated in the SMTP protocol. MIME is used to extend 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, allowing an attacker to impersonate any valid contact in the target organization.

IDN Phishing: An Old Problem Revived

The problem of IDN-based phishing websites gained attention in 2017 when web application developer Xudong Zheng demonstrated how modern browsers, at the time, did not distinguish their аpple.com similar site (an IDN) of the real apple.com.

Zheng was worried that attackers could abuse IDNs 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 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 “a” (U + 0430) instead of 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 can not only not distinguish between the spoofed email address and the real one, they also see the contact card of a legitimate contact, and, therefore, he is the victim of the attack. .

It is not clear if Microsoft is willing to fix the problem in Outlook at this time:

“We have finished reviewing your case, but in this case, it was decided that we will not fix this vulnerability in the current version,” a Microsoft staff member is seen saying DobbyWanKenobi in an email.

“While spoofing could occur, the identity of the sender cannot be trusted without a digital signature. The necessary changes are likely to cause false positives and problems in other ways,” continued the email seen by Ars:

Microsoft has not responded to Ars’ request for comment sent in advance.

Researchers have seen this vulnerability affect 32-bit and 64-bit versions of the latest versions of Microsoft Outlook for Microsoft 365, although it appears that the issue is no longer reproducible in version 16.0.14228.20216 after Manzotti notified Microsoft. .

Interestingly, Microsoft’s response to Manzotti maintained that the vulnerability will not be fixed. In addition, Manzotti points out that this type of phishing attack will not be successful in Outlook Web Access (OWA).

Taking advantage of security features like “external sender“Email warnings and email signing are steps organizations can take to deter phishing attacks.




arstechnica.com

Leave a Reply

Your email address will not be published. Required fields are marked *