CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  
ID

CWE-1007: Insufficient Visual Distinction of Homoglyphs Presented to User

Weakness ID: 1007
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar or identical glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action.
+ Extended Description

Some glyphs, pictures, or icons can be semantically distinct to a program, while appearing very similar or identical to a human user. These are referred to as homoglyphs. For example, in some fonts, the lowercase "l" (ell) and uppercase "I" (eye) have different character codes. A program can recognize that they are different, but these characters can be displayed in exactly the same way to a user. This can also occur between different character sets. For example, the upper case Latin "A" and upper case Greek "A" are treated as distinct by programs, but will be displayed in exactly the same way to a user.

Adversaries can exploit this visual similarity for attacks such as phishing, e.g. by providing a link to an attacker-controlled hostname that looks like a hostname that the victim trusts. In a different use of homoglyphs, an adversary may create a back door username that is visually similar to the username of a regular user, which then makes it more difficult for a system administrator to detect the malicious username while reviewing logs.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory442Web Problems
ChildOfClassClass451User Interface (UI) Misrepresentation of Critical Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignThis weakness may occur when characters from various character sets are allowed to be interchanged within a URL, username, email address, etc. without any notification to the user or underlying system being used.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Web Based: (Sometimes Prevalent)

Technologies

Web Server: (Sometimes Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Other

An attacker may ultimately redirect a user to a malicious website, by deceiving the user into believing the URL they are accessing is a trusted domain. However, the attack can also be used to forge log entries by using homoglyphs in usernames. Homoglyph manipulations are often the first step towards executing advanced attacks such as stealing a user's credentials, Cross-Site Scripting (XSS), or log forgery. If an attacker redirects a user to a malicious site, the attacker can mimic a trusted domain to steal account credentials and perform actions on behalf of the user, without the user's knowledge. Similarly, an attacker could create a username for a website that contains homoglyph characters, making it difficult for an admin to review logs and determine which users performed which actions.
+ Alternate Terms
Homograph Attack:"Homograph" is often used as a synonym of "homoglyph" by researchers, but according to Wikipedia, a homograph is a word that has multiple, distinct meanings.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following displays a simple, trusted URL that a user may frequently access.

(attack)
 
http://www.еxаmрlе.соm

The URL is comprised of Cyrillic characters that look identical to the expected ASCII characters. This results in most users not being able to distinguish between the two and assuming that the above URL is trusted and safe. An adversary can utilize this approach to perform an attack such as a phishing attack in order to drive traffic to a malicious website.

Example 2

The following displays an example of how creating usernames containing homoglyphs can lead to log forgery.

Reusing the trusted domain of http://www.example.com, assume an attacker visits the legitimate, trusted domain and creates the account "admin" where the 'a' and 'i' characters are Cyrillic characters instead of the expected ACII. Any actions the attacker performs will be saved to the log file as if they were performed by the actual "admin" account (all ASCII).

(result)
 
123.123.123.123 аdmіn [17/Jul/2017:09:05:49 -0400] "GET /example/users/userlist HTTP/1.1" 401 12846
123.123.123.123 аdmіn [17/Jul/2017:09:06:51 -0400] "GET /example/users/userlist HTTP/1.1" 200 4523
123.123.123.123 аdmіn [17/Jul/2017:09:10:02 -0400] "GET /example/users/editusers HTTP/1.1" 200 6291
123.123.123.123 аdmіn [17/Jul/2017:09:10:02 -0400] "GET /example/users/editusers HTTP/1.1" 200 6291
123.123.123.123 аdmіn [17/Jul/2017:09:10:02 -0400] "GET /example/users/editusers HTTP/1.1" 200 6291
123.123.123.123 аdmіn [17/Jul/2017:09:10:02 -0400] "GET /example/users/editusers HTTP/1.1" 200 6291

This makes it more difficult to determine which actions were performed by the adversary and which actions were executed by the legitimate admin account.

+ Observed Examples
ReferenceDescription
web forum allows impersonation of users with homoglyphs in account names
Improper character restriction in URLs in web browser
Incomplete blacklist does not include homoglyphs of "/" and "?" characters in URLs
web browser does not convert hyphens to punycode, allowing IDN spoofing in URLs
homoglyph spoofing using punycode in URLs and certificates
homoglyph spoofing using punycode in URLs and certificates
homoglyph spoofing using punycode in URLs and certificates
+ Potential Mitigations

Phase: Implementation

Use a browser that displays Punycode for IDNs in the URL and status bars, or which color code various scripts in URLs. Due to the prominence of homoglyph attacks, several browsers now help safeguard against this attack via the use of Punycode. For example, Mozilla Firefox and Google Chrome will display IDNs as Punycode if top-level domains do not restrict which characters can be used in domain names or if labels mix scripts for different languages.

Phase: Implementation

Use an email client that has strict filters and prevents messages that mix character sets to end up in a user's inbox. Certain email clients such as Google's GMail prevent the use of non-Latin characters in email addresses or in links contained within emails. This helps prevent homoglyph attacks by flagging these emails and redirecting them to a user's spam folder.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Manual Dynamic Analysis

If utilizing user accounts, attempt to submit a username that contains homoglyphs. Similarly, check to see if links containing homoglyphs can be sent via email, web browsers, or other mechanisms.

Effectiveness: Moderate

+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 11, "Canonical Representation Issues", Page 382. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-8] Gregory Baatard and Peter Hannay. "The 2011 IDN Homograph Attack Mitigation Survey". ECU Publications. 2012. <http://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1174&context=ecuworks2012>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2017-07-24CWE Content TeamMITRE

More information is available — Please select a different filter.
Page Last Updated: November 15, 2017