Kategorie
How Hash-Based Safe Browsing Works in Google Chrome
There are various threats a user faces when browsing the web. Users may be tricked into sharing sensitive information like their passwords with a misleading or fake website, also called phishing. They may also be led into installing malicious software on their machines, called malware, which can collect personal data and also hold it for ransom. Google Chrome, henceforth called Chrome, enables its users to protect themselves from such threats on the internet. When Chrome users browse the web with Safe Browsing protections, Chrome uses the Safe Browsing service from Google to identify and ward off various threats.
Safe Browsing works in different ways depending on the user's preferences. In the most common case, Chrome uses the privacy-conscious Update API (Application Programming Interface) from the Safe Browsing service. This API was developed with user privacy in mind and ensures Google gets as little information about the user's browsing history as possible. If the user has opted-in to "Enhanced Protection" (covered in an earlier post) or "Make Searches and Browsing Better", Chrome shares limited additional data with Safe Browsing only to further improve user protection.
This post describes how Chrome implements the Update API, with appropriate pointers to the technical implementation and details about the privacy-conscious aspects of the Update API. This should be useful for users to understand how Safe Browsing protects them, and for interested developers to browse through and understand the implementation. We will cover the APIs used for Enhanced Protection users in a future post.
Threats on the InternetWhen a user navigates to a webpage on the internet, their browser fetches objects hosted on the internet. These objects include the structure of the webpage (HTML), the styling (CSS), dynamic behavior in the browser (Javascript), images, downloads initiated by the navigation, and other webpages embedded in the main webpage. These objects, also called resources, have a web address which is called their URL (Uniform Resource Locator). Further, URLs may redirect to other URLs when being loaded. Each of these URLs can potentially host threats such as phishing websites, malware, unwanted downloads, malicious software, unfair billing practices, and more. Chrome with Safe Browsing checks all URLs, redirects or included resources, to identify such threats and protect users.
Safe Browsing ListsSafe Browsing provides a list for each threat it protects users against on the internet. A full catalog of lists that are used in Chrome can be found by visiting chrome://safe-browsing/#tab-db-manager on desktop platforms.
A list does not contain unsafe web addresses, also referred to as URLs, in entirety; it would be prohibitively expensive to keep all of them in a device’s limited memory. Instead it maps a URL, which can be very long, through a cryptographic hash function (SHA-256), to a unique fixed size string. This distinct fixed size string, called a hash, allows a list to be stored efficiently in limited memory. The Update API handles URLs only in the form of hashes and is also called hash-based API in this post.
Further, a list does not store hashes in entirety either, as even that would be too memory intensive. Instead, barring a case where data is not shared with Google and the list is small, it contains prefixes of the hashes. We refer to the original hash as a full hash, and a hash prefix as a partial hash.
A list is updated following the Update API’s request frequency section. Chrome also follows a back-off mode in case of an unsuccessful response. These updates happen roughly every 30 minutes, following the minimum wait duration set by the server in the list update response.
For those interested in browsing relevant source code, here’s where to look:
Source Code- GetListInfos() contains all the lists, along with their associated threat types, the platforms they are used on, and their file names on disk.
- HashPrefixMap shows how the lists are stored and maintained. They are grouped by the size of prefixes, and appended together to allow quick binary search based lookups.
As an example of a Safe Browsing list, let's say that we have one for malware, containing partial hashes of URLs known to host malware. These partial hashes are generally 4 bytes long, but for illustrative purposes, we show only 2 bytes.
['036b', '1a02', 'bac8', 'bb90']Whenever Chrome needs to check the reputation of a resource with the Update API, for example when navigating to a URL, it does not share the raw URL (or any piece of it) with Safe Browsing to perform the lookup. Instead, Chrome uses full hashes of the URL (and some combinations) to look up the partial hashes in the locally maintained Safe Browsing list. Chrome sends only these matched partial hashes to the Safe Browsing service. This ensures that Chrome provides these protections while respecting the user’s privacy. This hash-based lookup happens in three steps in Chrome:
Step 1: Generate URL Combinations and Full HashesWhen Google blocks URLs that host potentially unsafe resources by placing them on a Safe Browsing list, the malicious actor can host the resource on a different URL. A malicious actor can cycle through various subdomains to generate new URLs. Safe Browsing uses host suffixes to identify malicious domains that host malware in their subdomains. Similarly, malicious actors can also cycle through various subpaths to generate new URLs. So Safe Browsing also uses path prefixes to identify websites that host malware at various subpaths. This prevents malicious actors from cycling through subdomains or paths for new malicious URLs, allowing robust and efficient identification of threats.
To incorporate these host suffixes and path prefixes, Chrome first computes the full hashes of the URL and some patterns derived from the URL. Following Safe Browsing API's URLs and Hashing specification, Chrome computes the full hashes of URL combinations by following these steps:
- First, Chrome converts the URL into a canonical format, as defined in the specification.
- Then, Chrome generates up to 5 host suffixes/variants for the URL.
- Then, Chrome generates up to 6 path prefixes/variants for the URL.
- Then, for the combined 30 host suffixes and path prefixes combinations, Chrome generates the full hash for each combination.
- V4LocalDatabaseManager::CheckBrowseURL is an example which performs a hash-based lookup.
- V4ProtocolManagerUtil::UrlToFullHashes creates the various URL combinations for a URL, and computes their full hashes.
For instance, let's say that a user is trying to visit https://evil.example.com/blah#frag. The canonical url is https://evil.example.com/blah. The host suffixes to be tried are evil.example.com, and example.com. The path prefixes are / and /blah. The four combined URL combinations are evil.example.com/, evil.example.com/blah, example.com/, and example.com/blah.
url_combinations = ["evil.example.com/", "evil.example.com/blah","example.com/", "example.com/blah"]full_hashes = ['1a02…28', 'bb90…9f', '7a9e…67', 'bac8…fa']
Step 2: Search Partial Hashes in Local Lists
Chrome then checks the full hashes of the URL combinations against the locally maintained Safe Browsing lists. These lists, which contain partial hashes, do not provide a decisive malicious verdict, but can quickly identify if the URL is considered not malicious. If the full hash of the URL does not match any of the partial hashes from the local lists, the URL is considered safe and Chrome proceeds to load it. This happens for more than 99% of the URLs checked.
Source Code- V4LocalDatabaseManager::GetPrefixMatches gets the matching partial hashes for the full hashes of the URL and its combinations.
Chrome finds that three full hashes 1a02…28, bb90…9f, and bac8…fa match local partial hashes. We note that this is for demonstration purposes, and a match here is rare.
Step 3: Fetch Matching Full HashesNext, Chrome sends only the matching partial hash (not the full URL or any particular part of the URL, or even their full hashes), to the Safe Browsing service's fullHashes.find method. In response, it receives the full hashes of all malicious URLs for which the full hash begins with one of the partial hashes sent by Chrome. Chrome checks the fetched full hashes with the generated full hashes of the URL combinations. If any match is found, it identifies the URL with various threats and their severities inferred from the matched full hashes.
Source Code- V4GetHashProtocolManager::GetFullHashes performs the lookup for the full hashes for the matched partial hashes.
Chrome sends the matched partial hashes 1a02, bb90, and bac8 to fetch the full hashes. The server returns full hashes that match these partial hashes, 1a02…28, bb90…ce, and bac8…01. Chrome finds that one of the full hashes matches with the full hash of the URL combination being checked, and identifies the malicious URL as hosting malware.
ConclusionSafe Browsing protects Chrome users from various malicious threats on the internet. While providing these protections, Chrome faces challenges such as constraints in memory capacity, network bandwidth usage, and a dynamic threat landscape. Chrome is also mindful of the users’ privacy choices, and shares little data with Google.
In a follow up post, we will cover the more advanced protections Chrome provides to its users who have opted in to “Enhanced Protection”.
Phishers Swim Around 2FA in Coinbase Account Heists
Slack admits to leaking hashed passwords for five years
New Orchard Botnet Uses Bitcoin Founder’s Account Info to Generate Malicious Domains
The Benefits of Building a Mature and Diverse Blue Team
Researchers Uncover Classiscam Scam-as-a-Service Operations in Singapore
GwisinLocker A New Ransomware Encrypts Windows and Linux ESXi Servers
Benefits & Drawbacks of Using a VPN on Linux
Brave vs. Tor: Which Browser Offers More Security and Privacy?
Tenhle čip proslavila omezení spojená s Windows 11. Co byste měli vědět o TPM
Targeted attack on industrial enterprises and public institutions
In January 2022, Kaspersky ICS CERT experts detected a wave of targeted attacks on military industrial complex enterprises and public institutions in several countries. In the course of our research, we were able to identify over a dozen of attacked organizations. The attack targeted industrial plants, design bureaus and research institutes, government agencies, ministries and departments in several East European countries (Belarus, Russia, and Ukraine), as well as Afghanistan.
The attackers were able to penetrate dozens of enterprises and even hijack the IT infrastructure of some, taking control of systems used to manage security solutions.
An analysis of information obtained while investigating the incidents indicates that cyberespionage was the goal of this series of attacks.
Initial infectionThe attackers penetrated the enterprise network using carefully crafted phishing emails, some of which use information that is specific to the organization under attack and is not publicly available. This could indicate that the attackers did preparatory work in advance (they may have obtained the information in earlier attacks on the same organization or its employees, or on other organizations or individuals associated with the victim organization).
Microsoft Word documents attached to the phishing emails contained malicious code that exploits the CVE-2017-11882 vulnerability. The vulnerability enables an attacker to execute arbitrary code (in the attacks analyzed, the main module of the PortDoor malware) without any additional user activity.
An earlier series of attacks in which the PortDoor malware was also used was described by Cybereason experts. A new version of PortDoor was identified in the course of our research.
Initial infection of a system
After being launched, PortDoor collects general information on the infected system and sends it to the malware command-and-control (CnC) server. In cases where an infected system is of interest to the attackers, they use the PortDoor functionality to control the system remotely and install additional malware.
Additional malwareThe attackers used five different backdoors at the same time – probably to set up redundant communication channels with infected systems in case one of the malicious programs was detected and removed by a security solution. The backdoors used provide extensive functionality for controlling infected systems and collecting confidential data.
Of the six backdoors identified on infected systems, five (PortDoor, nccTrojan, Logtu, Cotx, and DNSep) have been used earlier in attacks attributed by other researchers to APT TA428. The sixth backdoor is new and has not been observed in other attacks.
Lateral movementAfter gaining a foothold on the initial system, the attackers attempt to spread the malware to other computers on the enterprise network. To gain access to those computers, the attackers use network scanning results, as well as user credentials stolen earlier.
The Ladon hacking utility (which is popular in China) is used as the main lateral movement tool. It combines network scanning, vulnerability search and exploitation, password attack, and other functionality. The attackers also extensively use standard utilities that are part of the Microsoft Windows operating system.
The attack’s final stage involves hijacking the domain controller and gaining full control of all of the organization’s workstations and servers.
The attackers used DLL hijacking and process hollowing techniques extensively in the attack to prevent security software from detecting the malware.
Data theftAfter gaining domain administrator privileges, the attackers searched for and exfiltrated documents and other files that contained the attacked organization’s sensitive data to their servers hosted in different countries. These servers were also used as stage one CnC servers.
The attackers compressed stolen files into encrypted and password-protected ZIP archives. After receiving the data collected, the stage one CnC servers forwarded the archives received to a stage two server located in China.
Transfer of stolen data from infected systems
Who is behind the attack?Significant overlaps in tactics, techniques, and procedures (TTPs) have been observed with APT TA428 activity.
The research identified malware and CnC servers previously used in attacks attributed by other researchers to TA428 APT group.
Some indirect evidence also supports our conclusion.
We believe that the series of attacks that we have identified is highly likely to be an extension of a known campaign that has been described in Cybereason, DrWeb, and NTTSecurity research and has been attributed with a high degree of confidence to APT TA428 activity.
ConclusionThe findings of our research show that spear phishing remains one of the most relevant threats to industrial enterprises and public institutions. In the course of the attack, the attackers used mostly known backdoor malware, as well as standard lateral movement techniques and methods designed to evade detection by security solutions.
The attack series that we have identified is not the first in the campaign. Given that the attackers have had some success, we believe it is highly likely that similar attacks will occur again in the future. Industrial enterprises and public institutions should do a great deal of work to successfully thwart such attacks.
Technical details of the attacks, as well as recommendations and indicators of compromise, can be found in the full public version of the article on the Kaspersky ICS CERT website.
A private version of the article has been published on Kaspersky Threat Intelligence.
We are not wrapping up our investigation as yet and will release information on new findings as they appear. For more information, you can contact ics-cert@kaspersky.com.
Češi budou bojovat proti kyberútokům, které šifrují data
Meta Cracks Down on Cyber Espionage Operations in South Asia Abusing Facebook
New IoT RapperBot Malware Targeting Linux Servers via SSH Brute-Forcing Attack
Hackers Exploit Twitter Vulnerability to Exposes 5.4 Million Accounts
Slack Resets Passwords After a Bug Exposed Hashed Passwords for Some Users
Traffic Light Protocol for cybersecurity responders gets a revamp
Iranian Hackers Likely Behind Disruptive Cyberattacks Against Albanian Government
Open Redirect Flaw Snags Amex, Snapchat User Data
Windows Subsystem for Linux 0.65.1 is now live for all Insiders
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- …
- následující ›
- poslední »
