Google Security Blog

Posted by Nataliya Stanetsky and Roger Piqueras Jover, Android Security & Privacy Team

Cell-site simulators, also known as False Base Stations (FBS) or Stingrays, are radio devices that mimic real cell sites in order to lure mobile devices to connect to them. These devices are commonly used for security and privacy attacks, such as surveillance and interception of communications. In recent years, carriers have started reporting new types of abuse perpetrated with FBSs for the purposes of financial fraud.

In particular, there is increasingly more evidence of the exploitation of weaknesses in cellular communication standards leveraging cell-site simulators to inject SMS phishing messages directly into smartphones. This method to inject messages entirely bypasses the carrier network, thus bypassing all the sophisticated network-based anti-spam and anti-fraud filters. Instances of this new type of fraud, which carriers refer to as SMS Blaster fraud, have been reported in Vietnam, France, Norway, Thailand and multiple other countries.

GSMA’s Fraud and Security Group (FASG) has developed a briefing paper for GSMA members to raise awareness of SMS Blaster fraud and provide guidelines and mitigation recommendations for carriers, OEMs and other stakeholders. The briefing paper, available for GSMA members only, calls out some Android-specific recommendations and features that can help effectively protect our users from this new type of fraud.

What are SMS Blasters?

SMS Blaster is the term that global carriers use to refer to FBS and cell-site simulators operated unlawfully with the goal of disseminating (blast) SMS payloads. The most common use case is to leverage these devices to inject Smishing (SMS phishing) payloads into user devices. Fraudsters typically do this by driving around with portable FBS devices, and there have even been reports of fraudsters carrying these devices in their backpacks.

The method is straightforward and replicates known techniques to trick mobile devices to an attacker-controlled 2G network. SMS Blasters expose a fake LTE or 5G network which executes a single function: downgrading the user’s connection to a legacy 2G protocol. The same device also exposes a fake 2G network, which lures all the devices to connect to it. At this point, attackers abuse the well known lack of mutual authentication in 2G and force connections to be unencrypted, which enables a complete Person-in-the-Middle (PitM) position to inject SMS payloads.

SMS Blasters are sold on the internet and do not require deep technical expertise. They are simple to set up and ready to operate, and users can easily configure them to imitate a particular carrier or network using a mobile app. Users can also easily configure and customize the SMS payload as well as its metadata, including for example the sender number.

SMS Blasters are very appealing to fraudsters given their great return on investment. Spreading SMS phishing messages commonly yields a small return as it is very difficult to get these messages to fly undetected by sophisticated anti-spam filters. A very small subset of messages eventually reach a victim. In contrast, injecting messages with an SMS blaster entirely bypasses the carrier network and its anti-fraud and anti-spam filters, guaranteeing that all messages will reach a victim. Moreover, using an FBS the fraudster can control all fields of the message. One can make the message look like it is coming from the legitimate SMS aggregator of a bank, for example. In a recent attack that impacted hundreds of thousands of devices, the messages masqueraded as a health insurance notice.

Although the type of abuse carriers are uncovering recently is financial fraud, there is precedent for the use of rogue cellular base stations to disseminate malware, for example injecting phishing messages with a url to download the payload. It is important to note that users are still vulnerable to this type of fraud as long as mobile devices support 2G, regardless of the status of 2G in their local carrier.

Android protects users from phishing and fraud

There are a number of Android-only security features that can significantly mitigate, or in some cases fully block, the impact of this type of fraud.

Android 12 introduced a user option to disable 2G at the modem level, a feature first adopted by Pixel. This option, if used, completely mitigates the risk from SMS Blasters. This feature has been available since Android 12 and requires devices to conform to Radio HAL 1.6+.

Android also has an option to disable null ciphers as a key protection because it is strictly necessary for the 2G FBS to configure a null cipher (e.g. A5/0) in order to inject an SMS payload. This security feature launched with Android 14 requires devices that implement radio HAL 2.0 or above.

Android also provides effective protections that specifically tackles SMS spam and phishing, regardless of whether the delivery channel is an SMS Blaster. Android has built-in spam protection that helps to identify and block spam SMS messages. Additional protection is provided through RCS for Business, a feature that helps users identify legitimate SMS messages from businesses. RCS for Business messages are marked with a blue checkmark, which indicates that the message has been verified by Google.

We advocate leveraging a couple of important Google security features which are available on Android, namely Safe Browsing and Google Play Protect. As an additional layer of protection, Safe Browsing built-in on Android devices protects 5 billion devices globally and helps warn the users about potentially risky sites, downloads and extensions which could be phishing and malware-based.

Let’s say a user decides to download an app from the Play store but the app contains code that is malicious or harmful, users are protected by Google Play Protect which is a security feature that scans apps for malware and other threats. It also warns users about potentially harmful apps before they are installed. Android’s commitment to security and privacy

Android is committed to providing users with a safe and secure mobile experience. We are constantly working to improve our security features and protect users from phishing, fraud, and other threats.

Working with global carriers and other OEMs through the GSMA to support the ecosystem in the development and adoption of further cellular security and privacy features is a priority area for Android. We look forward to partnering with ecosystem partners in further raising the security bar in this space to protect mobile users from threats like SMS blasters.

Thank you to all our colleagues who actively contribute to Android’s efforts in tackling fraud and FBS threats, and special thanks to those who contributed to this blog post: Yomna Nasser, Gil Cukierman, Il-Sung Lee, Eugene Liderman, Siddarth Pandit.

Posted by Will Harris, Chrome Security Team

Cybercriminals using cookie theft infostealer malware continue to pose a risk to the safety and security of our users. We already have a number of initiatives in this area including Chrome’s download protection using Safe Browsing, Device Bound Session Credentials, and Google’s account-based threat detection to flag the use of stolen cookies. Today, we’re announcing another layer of protection to make Windows users safer from this type of malware.

Like other software that needs to store secrets, Chrome currently secures sensitive data like cookies and passwords using the strongest techniques the OS makes available to us - on macOS this is the Keychain services, and on Linux we use a system provided wallet such as kwallet or gnome-libsecret. On Windows, Chrome uses the Data Protection API (DPAPI) which protects the data at rest from other users on the system or cold boot attacks. However, the DPAPI does not protect against malicious applications able to execute code as the logged in user - which infostealers take advantage of.

In Chrome 127 we are introducing a new protection on Windows that improves on the DPAPI by providing Application-Bound (App-Bound) Encryption primitives. Rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS.

We will be migrating each type of secret to this new system starting with cookies in Chrome 127. In future releases we intend to expand this protection to passwords, payment data, and other persistent authentication tokens, further protecting users from infostealer malware.

How it works

App-Bound Encryption relies on a privileged service to verify the identity of the requesting application. During encryption, the App-Bound Encryption service encodes the app's identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail.

Because the App-Bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing. This makes their actions more suspicious to antivirus software – and more likely to be detected. Our other recent initiatives such as providing event logs for cookie decryption work in tandem with this protection, with the goal of further increasing the cost and risk of detection to attackers attempting to steal user data.

Enterprise Considerations

Since malware can bypass this protection by running elevated, enterprise environments that do not grant their users the ability to run downloaded files as Administrator are particularly helped by this protection - malware cannot simply request elevation privilege in these environments and is forced to use techniques such as injection that can be more easily detected by endpoint agents.

App-Bound Encryption strongly binds the encryption key to the machine, so will not function correctly in environments where Chrome profiles roam between multiple machines. We encourage enterprises who wish to support roaming profiles to follow current best practices. If it becomes necessary, App-Bound encryption can be configured using the new ApplicationBoundEncryptionEnabled policy.

To further help detect any incompatibilities, Chrome emits an event when a failed verification occurs. The Event is ID 257 from 'Chrome' source in the Application log.

Conclusion

App-Bound Encryption increases the cost of data theft to attackers and also makes their actions far noisier on the system. It helps defenders draw a clear line in the sand for what is acceptable behavior for other apps on the system. As the malware landscape continually evolves we are keen to continue engaging with others in the security community on improving detections and strengthening operating system protections, such as stronger app isolation primitives, for any bypasses.

Posted by Jasika Bawa, Lily Chen, and Daniel Rubery, Chrome Security

Last year, we introduced a redesign of the Chrome downloads experience on desktop to make it easier for users to interact with recent downloads. At the time, we mentioned that the additional space and more flexible UI of the new Chrome downloads experience would give us new opportunities to make sure users stay safe when downloading files.

Adding context and consistency to download warnings

The redesigned Chrome downloads experience gives us the opportunity to provide even more context when Chrome protects a user from a potentially malicious file. Taking advantage of the additional space available in the new downloads UI, we have replaced our previous warning messages with more detailed ones that convey more nuance about the nature of the danger and can help users make more informed decisions.

Our legacy, space-constrained warning vs. our redesigned one

We also made download warnings more understandable by introducing a two-tier download warning taxonomy based on AI-powered malware verdicts from Google Safe Browsing. These are:

1. Suspicious files (lower confidence verdict, unknown risk of user harm)
2. Dangerous files (high confidence verdict, high risk of user harm)

These two tiers of warnings are distinguished by iconography, color, and text, to make it easy for users to quickly and confidently make the best choice for themselves based on the nature of the danger and Safe Browsing's level of certainty. Overall, these improvements in clarity and consistency have resulted in significant changes in user behavior, including fewer warnings bypassed, warnings heeded more quickly, and all in all, better protection from malicious downloads.

Differentiation between suspicious and dangerous warnings

Protecting more downloads with automatic deep scans

Users who have opted-in to the Enhanced Protection mode of Safe Browsing in Chrome are prompted to send the contents of suspicious files to Safe Browsing for deep scanning before opening the file. Suspicious files are a small fraction of overall downloads, and file contents are only scanned for security purposes and are deleted shortly after a verdict is returned.

We've found these additional scans to have been extraordinarily successful – they help catch brand new malware that Safe Browsing has not seen before and dangerous files hosted on brand new sites. In fact, files sent for deep scanning are over 50x more likely to be flagged as malware than downloads in the aggregate.

Since Enhanced Protection users have already agreed to send a small fraction of their downloads to Safe Browsing for security purposes in order to benefit from additional protections, we recently moved towards automatic deep scans for these users rather than prompting each time. This will protect users from risky downloads while reducing user friction.

An automatic deep scan resulting in a warning

Staying ahead of attackers who hide in encrypted archives

Not all deep scans can be conducted automatically. A current trend in cookie theft malware distribution is packaging malicious software in an encrypted archive – a .zip, .7z, or .rar file, protected by a password – which hides file contents from Safe Browsing and other antivirus detection scans. In order to combat this evasion technique, we have introduced two protection mechanisms depending on the mode of Safe Browsing selected by the user in Chrome.

Attackers often make the passwords to encrypted archives available in places like the page from which the file was downloaded, or in the download file name. For Enhanced Protection users, downloads of suspicious encrypted archives will now prompt the user to enter the file's password and send it along with the file to Safe Browsing so that the file can be opened and a deep scan may be performed. Uploaded files and file passwords are deleted a short time after they're scanned, and all collected data is only used by Safe Browsing to provide better download protections.

Enter a file password to send an encrypted file for a malware scan

For those who use Standard Protection mode which is the default in Chrome, we still wanted to be able to provide some level of protection. In Standard Protection mode, downloading a suspicious encrypted archive will also trigger a prompt to enter the file's password, but in this case, both the file and the password stay on the local device and only the metadata of the archive contents are checked with Safe Browsing. As such, in this mode, users are still protected as long as Safe Browsing had previously seen and categorized the malware.

The Chrome Security team works closely with Safe Browsing, Google's Threat Analysis Group, and security researchers from around the world to gain insights into the techniques attackers are using. Using these insights, we are constantly adapting our product strategy to stay ahead of attackers and to keep users safe while downloading files in Chrome. We look forward to sharing more in the future!