Canary, the leading-edge v36 of the Google Chrome browser, includes a new feature that attempts to make malicious websites easier to identify by burying the URL and moving the domains from the URI/URL address bar (known in Chrome as the “Omnibox”) into a location now known as “Origin Chip”. In theory, this makes it easier for users to identify phishing sites, but we’ve discovered a major oversight that makes the reality much different.
Canary is still in beta, but a flaw that impacts the visibility of a URL is typically something we only see once every few years. We’ve discovered that if a URL is long enough, Canary will not display any domain or URL at all, instead showing an empty text box with the ghost text “Search Google or type URL.” While Canary is intended to help the user identify a link’s true destination, it will actually make it impossible for even the savviest users to evaluate the authenticity of a URL.
This creates a golden opportunity for attackers to carry out data-entry phishing attacks. A data-entry attack will send an email luring the recipient to a seemingly genuine website asking the recipient to enter user credentials. (Rohyt described this tactic in more detail in a previous blog). Since these attacks do not use malware, the best (and sometimes only) defense against them is a well-trained user who recognizes that the URL is not leading to a legitimate website. Without the ability to evaluate the URL, even the savviest user could fall victim to this type of attack.
How does Canary differ from current versions of Chrome, and how exactly can this flaw be abused?
Canary, by default, maintains the look and feel of the current or previous Chrome versions (as shown in Figure 1).
Canary comes with an option to enable “Origin Chip” in the Omnibox. Users and administrators have been able to modify the Chrome browser flags through chrome://flags/ properties according to their home or corporate environment. In this version of Google Chrome, Version 36.0.1975.0 Canary, there is a new flag added as shown in Figure 2.
Once the Origin Chip is enabled and the browser has been restarted, we immediately see its effect as shown in Figure 3.
When it comes to subfolders versus subdomains, subfolders do not appear in the Origin Chip nor in the Omnibox but the main domain and subdomains are displayed in the Origin Chip (Figure 4).
Browsers become the primary target when it comes to the largely used applications that directly run on the client-side. To determine if there are any limitations to the Origin Chip, we created three scenarios to test its boundaries. In this case, we considered character or size limitation for URLs in the Origin Chip. In all three scenarios, let’s assume that the link came from a phishing email or a suspicious email.
In our first scenario, we considered a URL that fits into the space provided for Origin Chip with a domain and subdomain length combined to make 30-40 characters. This displayed as Canary intended.
In our second scenario, we considered a longer domain and subdomain combination with longer subfolder (60-70 characters total) to see if it makes any change to the Origin Chip. This scenario also displayed correctly.
For our final scenario, we considered a really long URL, and this is where things got interesting This URL had to be something that exceeded the space provided for the Origin Chip within the Omnibox. The URL in this scenario is as follows:
hxxp://this.is.a.test.for.longurl.to.test.the.canary.property.in.the.new.chrome.browser.and.see.if.it.works.DOMAINNAME.com/CheckingNowWithSampleURLInHere/eb31ac/?login_id=48ea2b9a-4f1b-4bbb-b573-89524db025e9 [URL and DOMAIN obfuscated]
In this case, the subdomain and the domain name has exceeded 100 characters (between 110-120 characters) as shown in Figure 5.
To confirm that our scenarios using multilevel subdomains are not the only cases where this happens, we tried adding Scenario 4 with the following URL, which is 98 characters long and is as shown in Figure 6:
www[.]ThisIsAVeryLongURLThatIsCreatedForTestingTheAcceptableLengthsOfOriginChipAndItsLimitations[.]com [URL obfuscated with “[“ and “]”]
Adding one more character to the above URL would remove the URL from the Origin Chip as shown in Figure 6. This proves that it doesn’t matter whether it is the subdomain length, multilevel subdomain, or the main domain length itself, if the character length goes beyond 98 characters the Origin Chip will not display any URL.
Omni Chip’s length is subjective to the browser size, so the URL length limits change when the browser is resized. For example, reducing your browser window size reduces the length at which Omni Chip will stop displaying the URL and vice versa. The lengths considered in the above scenarios will work on the default size, although the underlying fact that the URL disappears when Omni Chip exceeds specific length (determined by the size of the browser) remains unchanged.
By burying the concept of URL, or by making this setting permanent in the future versions of Chrome, users will not know the exact link or domain they are visiting, since the URL in the Omnibox disappears, meaning that even security savvy users who have been trained to recognize malicious URLs will be at risk.
How should Chrome remediate this issue? Merely extending the length of the URLs it will display isn’t a solution, because attackers will just make URLs as long as they need to be to avoid being displayed. A potential solution would be to keep the entire URL intact, but put a visual focus on the root domain.
Regardless of what Chrome decides to do, development teams considering this concept should consider alternative methods to display the complete URL.