A Nigerian influencer who attracted millions of followers on Instagram by showing off luxury cars and high-end clothing was sentenced on Monday to 11 years in prison for his role in business email compromise schemes and money laundering.
Ramon Abbas, who was known online by his social media handle Hushpuppi, was ordered by a California judge to also pay a total of more than $1.7 million in restitution to two victims.
Abbas pled guilty in April 2021 to — among other things — stealing more than $1 million from a Qatari businessperson who was attempting to finance the construction of a school for children. According to court documents, Abbas and his co-conspirators created bogus websites and pretended to be bank officials as part of the scam. Other targets included the client of a New York law firm, a foreign financial institution, and a professional soccer club, which together caused more than $24 million in losses, according to prosecutors.
The 40-year-old Abbas used the proceeds from his digital crimes to fund a lavish lifestyle that he flaunted on social media. He spent $230,000 of the stolen funds on a Swiss watch, prosecutors alleged, as well as citizenship and a passport from the Caribbean nation of Saint Kitts and Nevis. On Instagram, Abbas regularly posed next to Lamborghinis and Rolls-Royces, shopped at designer stores, and flew on private jets. His Instagram account has since been removed.
“Abbas leveraged his social media platforms – where he amassed a considerable following – to gain notoriety and to brag about the immense wealth he acquired by conducting business email compromise scams, online bank heists and other cyber-enabled fraud that financially ruined scores of victims and provided assistance to the North Korean regime,” said Don Alway, the Assistant Director in Charge of the FBI’s Los Angeles Field Office.
Abbas was arrested in Dubai in June 2020 and was extradited to the U.S. As part of a plea deal, he admitted to playing a role in a scheme to launder $14.7 million stolen from a bank in Malta. In a separate indictment, the U.S. charged three North Korean military hackers for committing the cyber heist, alleging that the stolen funds were “destined for the North Korean government.”
Business email compromise schemes, which often involve compromising legitimate email accounts and using them to trick others into transferring large amounts of funds, have been a growing concern for corporations and law enforcement. In May, the FBI’s Internet Crime Complaint Center (IC3) said such scams have led to more than $43 billion in losses since 2016.
November 2022 Patch Tuesday is here, with fixes for many vulnerabilities actively exploited in the wild, including CVE-2022-41091, a Windows Mark of the Web bypass flaw, and the ProxyNotShell MS Exchange vulnerabilities.
Fixes to prioritize
CVE-2022-41091 is a Windows zero-day vulnerability that allows attackers to bypass the Mark of the Web (MOTW) security feature. They can craft a malicious file triggering the flaw and deliver it either via a malicious or compromised website or via email or instant message.
“In all cases an attacker would have no way to force a user to view attacker-controlled content. Instead, an attacker would have to convince a user to take action. For example, an attacker could entice a user to either click a link that directs the user to the attacker’s site or send a malicious attachment,” Microsoft says, but it has nevertheless been successfully exploited by different attackers in the wild.
And, according to Beaumont, another MOTW bypass vulnerability (CVE-2022-41049) fixed this Patch Tuesday is being exploited in the wild – though Microsoft didn’t confirm it.
Then there’s CVE-2022-41128, a remote code execution flaw in Windows Scripting Languages.
“An attack would need to lure a user to either a specially crafted website or server share. In doing so, they would get their code to execute on an affected system at the level of the logged-on user,” commented Dustin Childs, with Trend Micro’s Zero Day Initiative.
“Microsoft provides no insight into how widespread this may be but considering it’s a browse-and-own type of scenario, I expect this will be a popular bug to include in exploit kits.”
Also under active exploitation: CVE-2022-41073, a Windows Print Spooler elevation of privilege (EoP) bug reported by Microsoft’s own threat intelligence analysts, and CVE-2022-41125, an EOP in the Windows CNG Key Isolation Service.
What else?
Obviously, the “ProxyNotShell” Microsoft Exchange Server flaws need to be patched as soon as possible due to in-the-wild exploitation, and the fact that Microsoft has stumbled with the provided mitigations.
“It’s been over a month since these flaws were disclosed. While the impact of ProxyNotShell is limited due to the authentication requirement, the fact that it has been exploited in the wild and that attackers are capable of obtaining valid credentials still make these important flaws to patch,” commented Satnam Narang, senior staff research engineer at Tenable.
Childs also noted that Microsoft has fixed four additional bugs in Exchange Server this month. “I have a strong premonition many Exchange administrators have a long weekend in front of them,” he added.
Finally, CVE-2022-38023 (an EoP flaw in Netlogon RPC) is not being exploited, but a fix for it should be implemented before Microsoft enforces the necessary updates in July 2023.
UPDATE (November 8, 2022, 17:05 a.m. ET):
This article has been amended to clear up potential confusion between the two fixed MOTW bypass flaws.
Researchers at Proofpoint disclosed in a Tweet Wednesday that more than 250 U.S. news organizations have accessed malicious SocGholish malware in what could potentially become a very dangerous supply chain attack.
In the Tweet, Proofpoint said it observed intermittent injections on a media company that serves video and advertising services to many major news outlets. The targeted media company serves content via Javascript to its partners, and by modifying the codebase of this otherwise benign Javascript, the threat actors used the media company to deploy the SocGholish malware.
SocGholish infections have historically served as a precursor to ransomware and some instances where stealers and keyloggers have been deployed. End stage payloads are variable based on victim profile and ongoing relationships with other threat actors utilizing Russian-linked TA569 for initial access.
Sherrod DeGrippo, vice president of threat research and detection at Proofpoint, said while they are unable to disclose information related to the targeted media company, the company in question provides both video content and advertising to major news outlets.
DeGrippo said while the threat actor has a demonstrated history of compromising content management systems (CMS) and hosting accounts, at this time, Proofpoint does not have evidence supporting the initial access vector, which likely occurs outside of mailflow.
“TA569 has previously leveraged media assets to distribute SocGholish, and this malware can lead to follow-on infections, including potential ransomware,” said DeGrippo. “The situation needs to be closely monitored, as Proofpoint has observed TA569 reinfect the same assets just days after remediation. Fixing the problem once isn’t enough. It’s worth remembering that website security is reliant on a network of assets and services, and that no matter how robust your security is, it’s only as good as the third-party assets you’re importing.”
DeGrippo said the site in question was first observed hosting the TA569 inject within the last 24 hours. The media company targeted has been informed and has been investigating. Only the targeted media company knows the full total of affected media organizations.
“Even with remediation we have seen TA569 reinfect the same assets days later so continued targeting of this company and others is probable,” DeGrippo said. “Supply chain attacks like this where one compromised asset can push out compromises to the entire network has proven to be a successful business model for threat actors. Media companies who are a pivot point in the news industry need to be wary.”
Activity linked to Russia-aligned threat actor as Election Day nears in U.S.
TA569 is believed to be a Russian-aligned threat actor, said Jason Hicks executive advisor and Field CISO at Coalfire. Hicks said given their alignment with a nation-state, it’s not surprising they are attacking media organizations.
Hicks said also given the proximity to Election Day, he expects to see an uptick in this kind of activity given the previous actions taken during previous U.S. elections. Media organizations have a wealth of information that’s of interest to foreign intelligence actors, said Hicks. Sources for stories that are critical of their government, or simply knowing an unfavorable article will get published would be of interest, said Hicks.
“It also gives them access to information before it becomes public, which would be useful for both awareness and investment purposes,” Hicks said. “Often these organizations are going to be easier to penetrate than the companies and government agencies they are reporting on, so attacking them is a quicker and easier way to collect useful information. Also, by infecting a service provider that caters to many organizations they can quickly expand their footprint and collect data from a wider variety of sources. Media organizations are also easier targets since they lack any significant regulatory burden around security.”
News organizations vulnerable to supply chain attacks
Dan Vasile, vice president of strategic development at BlueVoyant and former vice president of information security at Paramount, explained that the reported incident most definitely falls into the category of a supply chain attack. Vasile said the attack is similar, yet different to the well-known and costly Kaseya and SolarWinds incidents, abusing the trust customers have to have in their digital suppliers.
Vasile noted that BlueVoyant’s recent research on the media industry found security weaknesses and vulnerabilities across a number of vendors that support the media industry, suggesting that, as an industry, media faces significant cybersecurity challenges. In this case, Vasile said the malicious actor targeted the distribution section of the value chain, which is how content gets to broadcast and streaming services.
“All the actors further down the supply chain, such as news outlets, publishers and their customers, have been impacted,” Vasile said. “There are strong incentives for websites to load JavaScript, which is how reportedly the attack started, from remote sources including for performance and extra functionality. However, any compromise at the third-party level will propagate instantly to all sites using the infected JavaScript code, exposing their customers.”
John Bambenek, principal threat hunter at Netenrich, said he’s seen a little uptick in attacks on media companies right now. Whether it’s transient, or part of the usual ebb and flow of attacks, remains to be seen, said Bambenek.
“The real driver here is the use of vulnerable CMS servers (also popular in media companies) to push traffic as part of traffic delivery systems,” Bambenek said. “They are an important point of the exploit chain typically targeted towards end consumers.”
Proofpoint’s disclosure comes on the heels of last’s week’s incidents at the New York Post and Thomsen Retuers.
SC Media reported last Friday that the website and Twitter account of the N.Y. Post was hacked by an insider, whom the paper subsequently fired. And Thomson Reuters reportedly left at least three of its databases open on the public internet. One of the open instances was 3 terabytes of a public-facing ElasticSearch database that contained sensitive data across the company’s platforms.
Patient care is still being undermined at NHS mental health trusts and social care providers that were hit by a major cyber attack in August, doctors have warned.
Three months after the major attack wiped out NHS systems, patients’ records are missing, safety has been compromised, and medication doses are at risk of being missed amid ongoing “chaos”, i has been told.
Dr Andrew Molodynski, mental health lead at the British Medical Association, said the prolonged systems failure has damaged care because records are “integral to patients’ safety”.
Android users are often advised to get mobile apps from Google Play, the company’s official app marketplace, to minimize the possibility of downloading malware. After all, Google analyzes apps before allowing them on the market. Unfortunately, time after time, we read about malware peddlers finding ways around that vetting process.
“Distribution through droppers on official stores remains one of the most efficient ways for threat actors to reach a wide and unsuspecting audience. Although other distribution methods are also used depending on cybercriminals targets, resources, and motivation, droppers remain one of the best option on price-efforts-quality ratio, competing with SMiShing,” Threat Fabric researchers recently pointed out, after sharing their discovery of several apps on Google Play functioning as droppers for the Sharkbot and Vultur banking trojans.
Evasion techniques of malware droppers on Google Play
These trojanized, functional apps – usually file managers, file recovery tools, or security (2FA) authenticators – are crafted to conceal their malicious nature from Google Play Protect, antivirus solutions, researchers, and users: they provide the advertized functionality, request few common permissions that don’t raise suspicion, and don’t contain overtly malicious code.
More recently, Cleafy researchers shared additional information about the evasion techniques of a Vultur trojan dropper that was included in three apps found on Google Play (RecoverFiles, My Finances Tracker, and Zetter Authenticator).
This dropper, created by the cybercrime crew behind the Brunhilda DaaS (Dropper as a Service), is constantly being improved. The latest version has a small footprint, requests few permission, and uses steganography, file deletion, string obfuscation and anti-emulation techniques to “hide” from emulators, sandboxes, and security solutions.
The Sharkbot dropper, as described by Threat Fabric researchers, asks for an even smaller number of common permissions, and then doesn’t even perform malicious activity if the user is not located in a specific geographic location.
“To avoid using [the potentially suspicious] REQUEST_INSTALL_PACKAGES permission, the dropper opens a fake Google Play store page impersonating [the trojanized app’s] page. It contains fake information about the number of installations and reviews, and urges the victim to perform an update. Shortly after the page is opened, the automatic download starts. Thus, the dropper outsources the download and installation procedure to the browser, avoiding suspicious permissions,” the researchers explained.
“Obviously, such approach requires more actions from the victim, as the browser will show several messages about the downloaded file. However, since victims are sure about the origin of the application, they will highly likely install and run the downloaded Sharkbot payload.”
Similarly, the Brunhilda dropper app displays to the user a persistent update request to download a new application (i.e., the Vultur malware).
“Although in that way, the user has to accept the Android permission to download and install the application from a different source than the official Google Store, this technique allows [threat actors] to not upload the malicious application directly to the official store, making the dropper application undetectable,” Cleafy researchers pointed out.
In Microsoft’s 2022 Digital Defense Report, the company maintains that China’s offensive cyber capabilities have markedly improved, largely thanks to a 2021 cyber security bill. This bill required domestic organizations to report security vulnerabilities to local authorities prior to any other entity. This likely means the Chinese government used the disclosures to hoard vulnerability information. Microsoft said the impacts can already be seen with an incraesd use of zero days in the last year from China-based actors. Overall Microsoft found China stepped up its espionage and information-stealing cyber attacks to counter US attempts to increase its influence across Southeast Asia.
U.S. Attorney for the Southern District of New York, Damian Williams, announced that last year authorities seized over 50,000 bitcoins related to the illicit dark web marketplace Silk Road, worth over $3.36 billion at the time, now worth just over $1 billion. While not disclosed, it was the largest cryptocurrency seizure at the time, although surpassed this year with the 70,000 bitcoin seized from the hack of Bitfinex. The crypto assets were found at an address connected to James Zhong, who pleaded guilty to wire fraud in 2012.
The US Department of Justice seized the domains for the popular Z-Library eBook repository, which offered access to over 11 million books and 84 million articles. The site largely distributed these books without a license from copyright holders. Z-Library recently gained attention on TikTok, prompting an investigation from the United States Trade Representative. Last week TorrentFreak reported TikTok blocked Z-Library related hashtags due to complaints from copyright holders. Z-Library’s Tor address remains available, but informs visitors of server issues which could impact availability.
The Atacama Large Millimeter Array disclosed a cyberattack hit it on October 29th, impacting its computer systems and knocking its website offline. It suspended space observations as a result, although not scientific data or equipment was compromised. It’s unclear when the observatory will return to normal operations. As one of the world’s most powerful observatories, ALMA uses 66 radio telescopes to capture high-quality images of radio waves emitted by distinct astronomical objects. This raises questions about the overall security of the space industry, which contains an extremely limited number of targets with highly critical equipment. Shift 5 CEO Josh Lospinoso said the industry suffers from a lack of full visibility into its operation technology, with little ability to detect intrusions on platform edges.
The New York Times’ sources say that Twitter decided over the weekend to delay rolling out its updated Twitter Blue subscription until November 9th, specifically after the midterm elections in the US. The latest version of Twitter on iOS showed some users a notification about the upgraded $7.99 a month Twitter Blue subscription. Features listed included account verification. Other features “coming soon” offered “half the ads” of free accounts, and the ability to post longer videos. This led some to believe the service had launched and would be available. However Twitter product lead Esther Crawford clarified the new service isn’t live yet, maintaining any messages were a test.
We previously covered the ransomware attack that struck the Audtralian health insurer Medibank. It impacted 3.9 million customers and marked the second major cyberattack in the country after the Optus breach. A ransomware organization called BlogXX took credit for the attack, although some believe this to be a relaunch of the REvil ransomware gang. REvil’s leak site now redirects to the group’s and researcher confirmed its encryptor includes REvil code. Regardless, Medibank maintains that it will not pay its ransom demands, saying it believes there is only a limited chance doing so would prevent customer data from leaking, while increasing risk to other organizations. BlogXX began leaking customer data in an effort to get the organization to pay.
The phishing-as-a-service platform shifted its infrastructure to stay online. Originally it used Cloudflare as its host, but cut off Robin Banks back in July after it became aware of its activity. This resulted in a multi-day disruption while it shifted its infrastructure to the Russian-based DDOS-GUARD. That service never complies with government takedown requests, hosting content for sites associated with QAnon, as well as Hamas and 8chan. With the change in infrastructure, security researchers at IronNet discovered it began offering a new cookie-stealing feature as an add-on to its existing phishing kit. This appears to be part of its toolkit to bypass multi-factor authentication. Ironically when it switched over to DDOS-GUARD for hosting, it also started increasing its own internal security requirements, requiring two-factor authentication from customers to view phished information.
The open-source, decentralized micro-blogging platform Mastodon surpassed one million monthly active users for the first time. Its rise in users seems directly correlated to Elon Musk’s Twitter acquisition. It added 489,000 new users and added 1,124 new servers since October 27th. The service operates on a network of federated self-hosted servers with their own terms, privacy options, and content moderation framework. The federated model means users on one server can generally access content from others. For comparison, in its last earnings report, Twitter reported 237.8 million daily active users.
A new decryptor for the RanHassan ransomware is now available for download. First isolated in May 2022, this family of ransomware seems to primarily target victims in India and Arab-speaking countries.
The tell-tale signs of a RanHassan infection are the presence of ransom notes called ATENTION...ATENTION...ATENTION...ATENTION...ATENTION....hta referencing [dc.dcrypt@tutanota.com](mailto:dc.dcrypt@tutanota.com) and [dc.dcrypt@mailfence.com](mailto:dc.dcrypt@mailfence.com).
How to decrypt ransomed files
Step 1: Download the decryption tool below and save it on the infected device:
Step 2: Run the tool and accept the End User License Agreement.
Step 3: Select a folder to scan for encrypted files or let the tool find all files on the system. In order for the tool to identify the correct keys, you need at least one encrypted file and its unencrypted version.
Step 4: Start the decryption process and let the tool run until all files are decrypted.
Silent execution (via cmdline)
The tool can also be executed silently via a command line. If you need to automate the deployment of the tool inside a large network, you might want to use this feature.
• -help – will provide information on how to run the tool silently (this information will be written in the log file, not on console)
• start – this argument allows the tool to run silently (no GUI)
• -scan-path – this argument specifies the path containing encrypted files
• -full-scan – will enable the Scan entire system option (ignoring -scan-path argument)
• -disable-backup – will disable the file Backup option
• -replace-existing – will enable the Replace previously decrypted files option
• -test-path – specifies a folder containing pairs of clean-encrypted files
Examples:
BDRanHassanDecryptTool.exe start -scan-path:C:\ -> the tool will start with no GUI and scan C:\
BDRanHassanDecryptTool.exe start -full-scan -> the tool will start with no GUI and scan the entire system
BDRanHassanDecryptTool.exe start -full-scan -replace-existing -> the tool will scan the entire system and overwrite present clean files
Acknowledgement
This product includes software developed by the OpenSSL Project, for use in the OpenSSL Toolkit (http://www.openssl.org/)
K7Security Labs have published a technical analysis of the RanHassan (DCDcrypt) here.
Microsoft issued a warning about a rise in the use of publicly revealed zero-day exploits by threat actors in their attacks.
Researchers noted a shortening of the period between the disclosure of a vulnerability and its commoditization and noted the significance of the patch management procedure.
“As cyber threat actors—both nation-state and criminal—become more adept at leveraging these vulnerabilities, we have observed a reduction in the time between the announcement of a vulnerability and the commoditization of that vulnerability. This makes it essential that organizations patch exploits immediately”
Generally, it often takes just 14 days for a vulnerability to be exploited in the wild once it has been made public, but it typically takes 60 days for the exploit code to be published on GitHub.
“While zero-day vulnerability attacks tend to initially target a limited set of organizations, they are quickly adopted into the larger threat actor ecosystem. This kicks off a race for threat actors to exploit the vulnerability as widely as possible before their potential targets install patches”
reads the Digital Defense Report.
The report also says there are increasingly complex critical infrastructure cybersecurity policies in development across regions, sectors, and topic areas.
This activity brings great opportunities and significant challenges. Many nation-state actors have developed capabilities to create exploits from unknown vulnerabilities; China-linked APT groups are particularly proficient in this activity.
“China’s vulnerability reporting regulation went into effect September 2021, marking a first in the world for a government to require the reporting of vulnerabilities into a government authority for review prior to the vulnerability being shared with the product or service owner.” continues the report.
Nation-State Actors
“This new regulation might enable elements in the Chinese government to stockpile reported vulnerabilities toward weaponizing them.”
List of vulnerabilities first developed and deployed by China-linked threat actors in attacks, before being publicly disclosed and spread among other actors in attacks in the wild:
Therefore, as soon as they are made public, Microsoft advises enterprises to prioritize patching zero-day vulnerabilities. It also suggests documenting and inventorying all enterprise hardware and software assets to assess their vulnerability to assaults.
The National Cyber Security Centre (NCSC) has launched a new scheme and is now scanning all Internet-exposed devices hosted in the UK for vulnerabilities. designed to help it better understand how vulnerable UK systems are to cyber-attack, in order to enhance resilience.
The agency’s new internet scanning capability is designed to build a data-driven view of “the vulnerability of the UK.”
It will do this by probing any internet-accessible systems hosted in the country for known vulnerabilities, allowing the NCSC to understand how exposed these assets are and track remediation over time.
“We design our requests to collect the smallest amount of technical information required to validate the presence/version and/or vulnerability of a piece of software. We also design requests to limit the amount of personal data within the response,” the NCSC explained.
“In the unlikely event that we do discover information that is personal or otherwise sensitive, we take steps to remove the data and prevent it from being captured again in the future.”
The agency hopes the data it collects will help it to:
better understand the vulnerability and security of the UK as a whole
advise system owners about their security posture on a day-to-day basis
respond faster to incidents like a widely exploited zero-day vulnerability
In a blog explaining the new capability, outgoing technical director, Ian Levy, sought to reassure readers that the agency, which is part of GCHQ, wasn’t trying to find bugs “for some other, nefarious purpose.”
“The NCSC uses the data we have collected to create an overview of the UK’s exposure to vulnerabilities following their disclosure and track their remediation over time.”
NCSC’s scans are performed using tools hosted in a dedicated cloud-hosted environment from scanner.scanning.service.ncsc.gov.uk and two IP addresses (18.171.7.246 and 35.177.10.231).
The agency says that all vulnerability probes are tested within its own environment to detect any issues before scanning the UK Internet.
“We’re not trying to find vulnerabilities in the UK for some other, nefarious purpose,” NCSC technical director Ian Levy explained.
“We’re beginning with simple scans, and will slowly increase the complexity of the scans, explaining what we’re doing (and why we’re doing it).”
He added that the priority would be transparency, rigorous auditing, minimal scanning activity to reduce the impact on target resources and swift processing of any opt-out requests.
“We’re beginning with simple scans, and will slowly increase the complexity of the scans, explaining what we’re doing (and why we’re doing it),” he explained.
The NCSC released new data this week revealing the significant impact it has had over the past year in making the UK a safer place in which to live and do business.
Its Early Warning service provided users with 34 million alerts about attacks, compromises, vulnerabilities and open ports over the period, it said.
How to opt-out of vulnerability probes
Data collected from these scans includes any data sent back when connecting to services and web servers, such as the full HTTP responses (including headers).
Requests are designed to harvest the minimum amount of info required to check if the scanned asset is affected by a vulnerability.
If any sensitive or personal data is inadvertently collected, the NCSC says it will “take steps to remove the data and prevent it from being captured again in the future.”
British organizations can also opt out of having their servers scanned by the government by emailing a list of IP addresses they want to be excluded at scanning@ncsc.gov.uk.
Note: The three vulnerabilities discussed in this blog were all fixed in Samsung’s March 2021 release. They were fixed as CVE-2021-25337, CVE-2021-25369, CVE-2021-25370. To ensure your Samsung device is up-to-date under settings you can check that your device is running SMR Mar-2021 or later.
As defenders, in-the-wild exploit samples give us important insight into what attackers are really doing. We get the “ground truth” data about the vulnerabilities and exploit techniques they’re using, which then informs our further research and guidance to security teams on what could have the biggest impact or return on investment. To do this, we need to know that the vulnerabilities and exploit samples were found in-the-wild. Over the past few years there’s been tremendous progress in vendor’s transparently disclosing when a vulnerability is known to be exploited in-the-wild: Adobe, Android, Apple, ARM, Chrome, Microsoft, Mozilla, and others are sharing this information via their security release notes.
While we understand that Samsung has yet to annotate any vulnerabilities as in-the-wild, going forward, Samsung has committed to publicly sharing when vulnerabilities may be under limited, targeted exploitation, as part of their release notes.
We hope that, like Samsung, others will join their industry peers in disclosing when there is evidence to suggest that a vulnerability is being exploited in-the-wild in one of their products.
The exploit sample
The Google Threat Analysis Group (TAG) obtained a partial exploit chain for Samsung devices that TAG believes belonged to a commercial surveillance vendor. These exploits were likely discovered in the testing phase. The sample is from late 2020. The chain merited further analysis because it is a 3 vulnerability chain where all 3 vulnerabilities are within Samsung custom components, including a vulnerability in a Java component. This exploit analysis was completed in collaboration with Clement Lecigne from TAG.
The sample used three vulnerabilities, all patched in March 2021 by Samsung:
Arbitrary file read/write via the clipboard provider – CVE-2021-25337
Kernel information leak via sec_log – CVE-2021-25369
Use-after-free the Display Processing Unit (DPU) driver – CVE-2021-25370
The exploit sample targets Samsung phones running kernel 4.14.113 with the Exynos SOC. Samsung phones run one of two types of SOCs depending on where they’re sold. For example the Samsung phones sold in the United States, China, and a few other countries use a Qualcomm SOC and phones sold most other places (ex. Europe and Africa) run an Exynos SOC. The exploit sample relies on both the Mali GPU driver and the DPU driver which are specific to the Exynos Samsung phones.
Examples of Samsung phones that were running kernel 4.14.113 in late 2020 (when this sample was found) include the S10, A50, and A51.
The in-the-wild sample that was obtained is a JNI native library file that would have been loaded as a part of an app. Unfortunately TAG did not obtain the app that would have been used with this library. Getting initial code execution via an application is a path that we’ve seen in other campaigns this year. TAG and Project Zero published detailed analyses of one of these campaigns in June.
Vulnerability #1 – Arbitrary filesystem read and write
The exploit chain used CVE-2021-25337 for an initial arbitrary file read and write. The exploit is running as the untrusted_app SELinux context, but uses the system_server SELinux context to open files that it usually wouldn’t be able to access. This bug was due to a lack of access control in a custom Samsung clipboard provider that runs as the system user.
About Android content providers
In Android, Content Providers manage the storage and system-wide access of different data. Content providers organize their data as tables with columns representing the type of data collected and the rows representing each piece of data. Content providers are required to implement six abstract methods: query, insert, update, delete, getType, and onCreate. All of these methods besides onCreate are called by a client application.
All applications can read from or write to your provider, even if the underlying data is private, because by default your provider does not have permissions set. To change this, set permissions for your provider in your manifest file, using attributes or child elements of the <provider> element. You can set permissions that apply to the entire provider, or to certain tables, or even to certain records, or all three.
The vulnerability
Samsung created a custom clipboard content provider that runs within the system server. The system server is a very privileged process on Android that manages many of the services critical to the functioning of the device, such as the WifiService and TimeZoneDetectorService. The system server runs as the privileged system user (UID 1000, AID_system) and under the system_server SELinux context.
Samsung added a custom clipboard content provider to the system server. This custom clipboard provider is specifically for images. In the com.android.server.semclipboard.SemClipboardProvider class, there are the following variables: DATABASE_NAME = ‘clipboardimage.db’
CREATE_TABLE = ” CREATE TABLE ClipboardImageTable (id INTEGER PRIMARY KEY AUTOINCREMENT, _data TEXT NOT NULL);”;
Unlike content providers that live in “normal” apps and can restrict access via permissions in their manifest as explained above, content providers in the system server are responsible for restricting access in their own code. The system server is a single JAR (services.jar) on the firmware image and doesn’t have a manifest for any permissions to go in. Therefore it’s up to the code within the system server to do its own access checking.
The ClipboardImageTable defines only two columns for the table as seen above: id and _data. The column name _data has a special use in Android content providers. It can be used with the openFileHelper method to open a file at a specified path. Only the URI of the row in the table is passed to openFileHelper and a ParcelFileDescriptor object for the path stored in that row is returned. The ParcelFileDescriptor class then provides the getFd method to get the native file descriptor (fd) for the returned ParcelFileDescriptor.
public Uri insert(Uri uri, ContentValues values) { long row = this.database.insert(TABLE_NAME, “”, values); if (row > 0) { Uri newUri = ContentUris.withAppendedId(CONTENT_URI, row); getContext().getContentResolver().notifyChange(newUri, null); return newUri; } throw new SQLException(“Fail to add a new record into ” + uri); }
The function above is the vulnerable insert() method in com.android.server.semclipboard.SemClipboardProvider. There is no access control included in this function so any app, including the untrusted_app SELinux context, can modify the _data column directly. By calling insert, an app can open files via the system server that it wouldn’t usually be able to open on its own.
The exploit triggered the vulnerability with the following code from an untrusted application on the device. This code returned a raw file descriptor.
Let’s walk through what is happening line by line:
Create a ContentValues object. This holds the key, value pair that the caller wants to insert into a provider’s database table. The key is the column name and the value is the row entry.
Set the ContentValues object: the key is set to “_data” and the value to an arbitrary file path, controlled by the exploit.
Get the URI to access the semclipboardprovider. This is set in the SemClipboardProvider class.
Get the ContentResolver object that allows apps access to ContentProviders.
Call insert on the semclipboardprovider with our key-value pair.
Open the file that was passed in as the value and return the raw file descriptor. openFileDescriptor calls the content provider’s openFile, which in this case simply calls openFileHelper.
The exploit wrote their next stage binary to the directory /data/system/users/0/. The dropped file will have an SELinux context of users_system_data_file. Normal untrusted_app’s don’t have access to open or create users_system_data_file files so in this case they are proxying the open through system_server who can open users_system_data_file. While untrusted_app can’t open users_system_data_file, it can read and write to users_system_data_file. Once the clipboard content provider opens the file and passess the fd to the calling process, the calling process can now read and write to it.
The exploit first uses this fd to write their next stage ELF file onto the file system. The contents for the stage 2 ELF were embedded within the original sample.
This vulnerability is triggered three more times throughout the chain as we’ll see below.
Fixing the vulnerability
To fix the vulnerability, Samsung added access checks to the functions in the SemClipboardProvider. The insert method now checks if the PID of the calling process is UID 1000, meaning that it is already also running with system privileges.
public Uri insert(Uri uri, ContentValues values) { if (Binder.getCallingUid() != 1000) { Log.e(TAG, “Fail to insert image clip uri. blocked the access of package : ” + getContext().getPackageManager().getNameForUid(Binder.getCallingUid())); return null; } long row = this.database.insert(TABLE_NAME, “”, values); if (row > 0) { Uri newUri = ContentUris.withAppendedId(CONTENT_URI, row); getContext().getContentResolver().notifyChange(newUri, null); return newUri; } throw new SQLException(“Fail to add a new record into ” + uri); }
Executing the stage 2 ELF
The exploit has now written its stage 2 binary to the file system, but how do they load it outside of their current app sandbox? Using the Samsung Text to Speech application (SamsungTTS.apk).
The Samsung Text to Speech application (com.samsung.SMT) is a pre-installed system app running on Samsung devices. It is also running as the system UID, though as a slightly less privileged SELinux context, system_app rather than system_server. There has been at least one previously public vulnerability where this app was used to gain code execution as system. What’s different this time though is that the exploit doesn’t need another vulnerability; instead it reuses the stage 1 vulnerability in the clipboard to arbitrarily write files on the file system.
Older versions of the SamsungTTS application stored the file path for their engine in their Settings files. When a service in the application was started, it obtained the path from the Settings file and would load that file path as a native library using the System.load API.
The exploit takes advantage of this by using the stage 1 vulnerability to write its file path to the Settings file and then starting the service which will then load its stage 2 executable file as system UID and system_app SELinux context.
To do this, the exploit uses the stage 1 vulnerability to write the following contents to two different files: /data/user_de/0/com.samsung.SMT/shared_prefs/SamsungTTSSettings.xml and /data/data/com.samsung.SMT/shared_prefs/SamsungTTSSettings.xml. Depending on the version of the phone and application, the SamsungTTS app uses these 2 different paths for its Settings files.
The SMT_LATEST_INSTALLED_ENGINE_PATH is the file path passed to System.load(). To initiate the process of the system loading, the exploit stops and restarts the SamsungTTSService by sending two intents to the application. The SamsungTTSService then initiates the load and the stage 2 ELF begins executing as the system user in the system_app SELinux context.
The exploit sample is from at least November 2020. As of November 2020, some devices had a version of the SamsungTTS app that did this arbitrary file loading while others did not. App versions 3.0.04.14 and before included the arbitrary loading capability. It seems like devices released on Android 10 (Q) were released with the updated version of the SamsungTTS app which did not load an ELF file based on the path in the settings file. For example, the A51 device that launched in late 2019 on Android 10 launched with version 3.0.08.18 of the SamsungTTS app, which does not include the functionality that would load the ELF.
Phones released on Android P and earlier seemed to have a version of the app pre-3.0.08.18 which does load the executable up through December 2020. For example, the SamsungTTS app from this A50 device on the November 2020 security patch level was 3.0.03.22, which did load from the Settings file.
Once the ELF file is loaded via the System.load api, it begins executing. It includes two additional exploits to gain kernel read and write privileges as the root user.
Vulnerability #2 – task_struct and sys_call_table address leak
Once the second stage ELF is running (and as system), the exploit then continued. The second vulnerability (CVE-2021-25369) used by the chain is an information leak to leak the address of the task_struct and sys_call_table. The leaked sys_call_table address is used to defeat KASLR. The addr_limit pointer, which is used later to gain arbitrary kernel read and write, is calculated from the leaked task_struct address.
The vulnerability is in the access permissions of a custom Samsung logging file: /data/log/sec_log.log.
The exploit abused a WARN_ON in order to leak the two kernel addresses and therefore break ASLR. WARN_ON is intended to only be used in situations where a kernel bug is detected because it prints a full backtrace, including stack trace and register values, to the kernel logging buffer, /dev/kmsg.
oid __warn(const char *file, int line, void *caller, unsigned taint, struct pt_regs *regs, struct warn_args *args){ disable_trace_on_warning(); pr_warn(“————[ cut here ]————\n”); if (file) pr_warn(“WARNING: CPU: %d PID: %d at %s:%d %pS\n”, raw_smp_processor_id(), current->pid, file, line, caller); else pr_warn(“WARNING: CPU: %d PID: %d at %pS\n”, raw_smp_processor_id(), current->pid, caller); if (args) vprintk(args->fmt, args->args); if (panic_on_warn) { /* * This thread may hit another WARN() in the panic path. * Resetting this prevents additional WARN() from panicking the * system on this thread. Other threads are blocked by the * panic_mutex in panic(). */ panic_on_warn = 0; panic(“panic_on_warn set …\n”); } print_modules(); dump_stack(); print_oops_end_marker(); /* Just a warning, don’t kill lockdep. */ add_taint(taint, LOCKDEP_STILL_OK);}
On Android, the ability to read from kmsg is scoped to privileged users and contexts. While kmsg is readable by system_server, it is not readable from the system_app context, which means it’s not readable by the exploit.
a51:/ $ ls -alZ /dev/kmsgcrw-rw—- 1 root system u:object_r:kmsg_device:s0 1, 11 2022-10-27 21:48 /dev/kmsg $ sesearch -A -s system_server -t kmsg_device -p read precompiled_sepolicyallow domain dev_type:lnk_file { getattr ioctl lock map open read };allow system_server kmsg_device:chr_file { append getattr ioctl lock map open read write };
Samsung however has added a custom logging feature that copies kmsg to the sec_log. The sec_log is a file found at /data/log/sec_log.log.
The WARN_ON that the exploit triggers is in the Mali GPU graphics driver provided by ARM. ARM replaced the WARN_ON with a call to the more appropriate helper pr_warn in release BX304L01B-SW-99002-r21p0-01rel1 in February 2020. However, the A51 (SM-A515F) and A50 (SM-A505F) still used a vulnerable version of the driver (r19p0) as of January 2021.
/** * kbasep_vinstr_hwcnt_reader_ioctl() – hwcnt reader’s ioctl. * @filp: Non-NULL pointer to file structure. * @cmd: User command. * @arg: Command’s argument. * * Return: 0 on success, else error code. */static long kbasep_vinstr_hwcnt_reader_ioctl( struct file *filp, unsigned int cmd, unsigned long arg){ long rcode; struct kbase_vinstr_client *cli; if (!filp || (_IOC_TYPE(cmd) != KBASE_HWCNT_READER)) return -EINVAL; cli = filp->private_data; if (!cli) return -EINVAL; switch (cmd) { case KBASE_HWCNT_READER_GET_API_VERSION: rcode = put_user(HWCNT_READER_API, (u32 __user *)arg); break; case KBASE_HWCNT_READER_GET_HWVER: rcode = kbasep_vinstr_hwcnt_reader_ioctl_get_hwver( cli, (u32 __user *)arg); break; case KBASE_HWCNT_READER_GET_BUFFER_SIZE: rcode = put_user( (u32)cli->vctx->metadata->dump_buf_bytes, (u32 __user *)arg); break; […] default: WARN_ON(true); rcode = -EINVAL; break; } return rcode;}
Specifically the WARN_ON is in the function kbase_vinstr_hwcnt_reader_ioctl. To trigger, the exploit only needs to call an invalid ioctl number for the HWCNT driver and the WARN_ON will be hit. The exploit makes two ioctl calls: the first is the Mali driver’s HWCNT_READER_SETUP ioctl to initialize the hwcnt driver and be able to call ioctl’s and then to the hwcnt ioctl target with an invalid ioctl number: 0xFE.
In Android, the property ctl.start starts a service that is defined in init. On the targeted Samsung devices, the SELinux policy for who has access to the ctl.start property is much more permissive than AOSP’s policy. Most notably in this exploit’s case, system_app has access to set ctl_start and thus initiate the bugreport.
The bugreport service is defined in /system/etc/init/dumpstate.rc:
service bugreport /system/bin/dumpstate -d -p -B -z \ -o /data/user_de/0/com.android.shell/files/bugreports/bugreport class main disabled oneshot
The bugreport service in dumpstate.rc is a Samsung-specific customization. The AOSP version of dumpstate.rc doesn’t include this service.
The Samsung version of the dumpstate (/system/bin/dumpstate) binary then copies everything from /proc/sec_log to /data/log/sec_log.log as shown in the pseudo-code below. This is the first few lines of the dumpstate() function within the dumpstate binary. The dump_sec_log (symbols included within the binary) function copies everything from the path provided in argument two to the path provided in argument three.
After starting the bugreport service, the exploit uses inotify to monitor for IN_CLOSE_WRITE events in the /data/log/ directory. IN_CLOSE_WRITE triggers when a file that was opened for writing is closed. So this watch will occur when dumpstate is finished writing to sec_log.log.
An example of the sec_log.log file contents generated after hitting the WARN_ON statement is shown below. The exploit combs through the file contents looking for two values on the stack that are at address *b60 and *bc0: the task_struct and the sys_call_table address.
The file /data/log/sec_log.log has the SELinux context dumplog_data_file which is widely accessible to many apps as shown below. The exploit is currently running within the SamsungTTS app which is the system_app SELinux context. While the exploit does not have access to /dev/kmsg due to SELinux access controls, it can access the same contents when they are copied to the sec_log.log which has more permissive access.
There were a few different changes to address this vulnerability:
Modified the dumpstate binary on the device – As of the March 2021 update, dumpstate no longer writes to /data/log/sec_log.log.
Removed the bugreport service from dumpstate.rc.
In addition there were a few changes made earlier in 2020 that when included would prevent this vulnerability in the future:
As mentioned above, in February 2020 ARM had released version r21p0 of the Mali driver which had replaced the WARN_ON with the more appropriate pr_warn which does not log a full backtrace. The March 2021 Samsung firmware included updating from version r19p0 of the Mali driver to r26p0 which used pr_warn instead of WARN_ON.
Vulnerability #3 – Arbitrary kernel read and write
The final vulnerability in the chain (CVE-2021-25370) is a use-after-free of a file struct in the Display and Enhancement Controller (DECON) Samsung driver for the Display Processing Unit (DPU). According to the upstream commit message, DECON is responsible for creating the video signals from pixel data. This vulnerability is used to gain arbitrary kernel read and write access.
Find the PID of android.hardware.graphics.composer
To be able to trigger the vulnerability the exploit needs an fd for the driver in order to send ioctl calls. To find the fd, the exploit has to to iterate through the fd proc directory for the target process. Therefore the exploit first needs to find the PID for the graphics process.
The exploit connects to LogReader which listens at /dev/socket/logdr. When a client connects to LogReader, LogReader writes the log contents back to the client. The exploit then configures LogReader to send it logs for the main log buffer (0), system log buffer (3), and the crash log buffer (4) by writing back to LogReader via the socket:
stream lids=0,3,4
The exploit then monitors the log contents until it sees the words ‘display’ or ‘SDM’. Once it finds a ‘display’ or ‘SDM’ log entry, the exploit then reads the PID from that log entry.
Next the exploit needs to find the full file path for the DECON driver. The full file path can exist in a few different places on the filesystem so to find which one it is on this device, the exploit iterates through the /proc/<PID>/fd/ directory looking for any file path that contains “graphics/fb0”, the DECON driver. It uses readlink to find the file path for each /proc/<PID>/fd/<fd>. The semclipboard vulnerability (vulnerability #1) is then used to get the raw file descriptor for the DECON driver path.
Triggering the Use-After-Free
The vulnerability is in the decon_set_win_config function in the Samsung DECON driver. The vulnerability is a relatively common use-after-free pattern in kernel drivers. First, the driver acquires an fd for a fence. This fd is associated with a file pointer in a sync_file struct, specifically the file member. A “fence” is used for sharing buffers and synchronizing access between drivers and different processes.
/** * struct sync_file – sync file to export to the userspace * @file: file representing this fence * @sync_file_list: membership in global file list * @wq: wait queue for fence signaling * @fence: fence with the fences in the sync_file * @cb: fence callback information */struct sync_file { struct file *file; /** * @user_name: * * Name of the sync file provided by userspace, for merged fences. * Otherwise generated through driver callbacks (in which case the * entire array is 0). */ char user_name[32];#ifdef CONFIG_DEBUG_FS struct list_head sync_file_list;#endif wait_queue_head_t wq; unsigned long flags; struct dma_fence *fence; struct dma_fence_cb cb;};
The driver then calls fd_install on the fd and file pointer, which makes the fd accessible from userspace and transfers ownership of the reference to the fd table. Userspace is able to call close on that fd. If that fd holds the only reference to the file struct, then the file struct is freed. However, the driver continues to use the pointer to that freed file struct.
static int decon_set_win_config(struct decon_device *decon, struct decon_win_config_data *win_data){ int num_of_window = 0; struct decon_reg_data *regs; struct sync_file *sync_file; int i, j, ret = 0; […] num_of_window = decon_get_active_win_count(decon, win_data); if (num_of_window) { win_data->retire_fence = decon_create_fence(decon, &sync_file); if (win_data->retire_fence < 0) goto err_prepare; } else { […] if (num_of_window) { fd_install(win_data->retire_fence, sync_file->file); decon_create_release_fences(decon, win_data, sync_file);#if !defined(CONFIG_SUPPORT_LEGACY_FENCE) regs->retire_fence = dma_fence_get(sync_file->fence);#endif } […] return ret;}
In this case, decon_set_win_config acquires the fd for retire_fence in decon_create_fence.
int decon_create_fence(struct decon_device *decon, struct sync_file **sync_file){ struct dma_fence *fence; int fd = -EMFILE; fence = kzalloc(sizeof(*fence), GFP_KERNEL); if (!fence) return -ENOMEM; dma_fence_init(fence, &decon_fence_ops, &decon->fence.lock, decon->fence.context, atomic_inc_return(&decon->fence.timeline)); *sync_file = sync_file_create(fence); dma_fence_put(fence); if (!(*sync_file)) { decon_err(“%s: failed to create sync file\n”, __func__); return -ENOMEM; } fd = decon_get_valid_fd(); if (fd < 0) { decon_err(“%s: failed to get unused fd\n”, __func__); fput((*sync_file)->file); } return fd;}
The function then calls fd_install(win_data->retire_fence, sync_file->file) which means that userspace can now access the fd. When fd_install is called, another reference is not taken on the file so when userspace calls close(fd), the only reference on the file is dropped and the file struct is freed. The issue is that after calling fd_install the function then calls decon_create_release_fences(decon, win_data, sync_file) with the same sync_file that contains the pointer to the freed file struct.
void decon_create_release_fences(struct decon_device *decon, struct decon_win_config_data *win_data, struct sync_file *sync_file){ int i = 0; for (i = 0; i < decon->dt.max_win; i++) { int state = win_data->config[i].state; int rel_fence = -1; if (state == DECON_WIN_STATE_BUFFER) { rel_fence = decon_get_valid_fd(); if (rel_fence < 0) { decon_err(“%s: failed to get unused fd\n”, __func__); goto err; } fd_install(rel_fence, get_file(sync_file->file)); } win_data->config[i].rel_fence = rel_fence; } return;err: while (i– > 0) { if (win_data->config[i].state == DECON_WIN_STATE_BUFFER) { put_unused_fd(win_data->config[i].rel_fence); win_data->config[i].rel_fence = -1; } } return;}
decon_create_release_fences gets a new fd, but then associates that new fd with the freed file struct, sync_file->file, in the call to fd_install.
When decon_set_win_config returns, retire_fence is the closed fd that points to the freed file struct and rel_fence is the open fd that points to the freed file struct.
Fixing the vulnerability
Samsung fixed this use-after-free in March 2021 as CVE-2021-25370. The fix was to move the call to fd_install in decon_set_win_config to the latest possible point in the function after the call to decon_create_release_fences.
if (num_of_window) {- fd_install(win_data->retire_fence, sync_file->file); decon_create_release_fences(decon, win_data, sync_file);#if !defined(CONFIG_SUPPORT_LEGACY_FENCE) regs->retire_fence = dma_fence_get(sync_file->fence);#endif } decon_hiber_block(decon); mutex_lock(&decon->up.lock); list_add_tail(®s->list, &decon->up.list);+ atomic_inc(&decon->up.remaining_frame); decon->update_regs_list_cnt++;+ win_data->extra.remained_frames = atomic_read(&decon->up.remaining_frame); mutex_unlock(&decon->up.lock); kthread_queue_work(&decon->up.worker, &decon->up.work); + /*+ * The code is moved here because the DPU driver may get a wrong fd+ * through the released file pointer,+ * if the user(HWC) closes the fd and releases the file pointer.+ *+ * Since the user land can use fd from this point/time,+ * it can be guaranteed to use an unreleased file pointer+ * when creating a rel_fence in decon_create_release_fences(…)+ */+ if (num_of_window)+ fd_install(win_data->retire_fence, sync_file->file); mutex_unlock(&decon->lock);
Heap Grooming and Spray
To groom the heap the exploit first opens and closes 30,000+ files using memfd_create. Then, the exploit sprays the heap with fake file structs. On this version of the Samsung kernel, the file struct is 0x140 bytes. In these new, fake file structs, the exploit sets four of the members:
The f_op member is set to the signalfd_op for reasons we will cover below in the “Overwriting the addr_limit” section. kaddr is the address leaked using vulnerability #2 described previously. The addr_limit_ptr was calculated by adding 8 to the task_struct address also leaked using vulnerability #2.
The exploit sprays 25 of these structs across the heap using the MEM_PROFILE_ADD ioctl in the Mali driver.
/** * struct kbase_ioctl_mem_profile_add – Provide profiling information to kernel * @buffer: Pointer to the information * @len: Length * @padding: Padding * * The data provided is accessible through a debugfs file */struct kbase_ioctl_mem_profile_add { __u64 buffer; __u32 len; __u32 padding;}; #define KBASE_ioctl_MEM_PROFILE_ADD \ _IOW(KBASE_ioctl_TYPE, 27, struct kbase_ioctl_mem_profile_add) static int kbase_api_mem_profile_add(struct kbase_context *kctx, struct kbase_ioctl_mem_profile_add *data){ char *buf; int err; if (data->len > KBASE_MEM_PROFILE_MAX_BUF_SIZE) { dev_err(kctx->kbdev->dev, “mem_profile_add: buffer too big\n”); return -EINVAL; } buf = kmalloc(data->len, GFP_KERNEL); if (ZERO_OR_NULL_PTR(buf)) return -ENOMEM; err = copy_from_user(buf, u64_to_user_ptr(data->buffer), data->len); if (err) { kfree(buf); return -EFAULT; } return kbasep_mem_profile_debugfs_insert(kctx, buf, data->len);}
This ioctl takes a pointer to a buffer, the length of the buffer, and padding as arguments. kbase_api_mem_profile_add will allocate a buffer on the kernel heap and then will copy the passed buffer from userspace into the newly allocated kernel buffer.
Finally, kbase_api_mem_profile_add calls kbasep_mem_profile_debugfs_insert. This technique only works when the device is running a kernel with CONFIG_DEBUG_FS enabled. The purpose of the MEM_PROFILE_ADD ioctl is to write a buffer to DebugFS. As of Android 11, DebugFS should not be enabled on production devices. Whenever Android launches new requirements like this, it only applies to devices launched on that new version of Android. Android 11 launched in September 2020 and the exploit was found in November 2020 so it makes sense that the exploit targeted devices Android 10 and before where DebugFS would have been mounted.
For example, on the A51 exynos device (SM-A515F) which launched on Android 10, both CONFIG_DEBUG_FS is enabled and DebugFS is mounted.
Because DebugFS is mounted, the exploit is able to use the MEM_PROFILE_ADD ioctl to groom the heap. If DebugFS wasn’t enabled or mounted, kbasep_mem_profile_debugfs_insert would simply free the newly allocated kernel buffer and return.
By writing the fake file structs as a singular 0x2000 size buffer rather than as 25 individual 0x140 size buffers, the exploit will be writing their fake structs to two whole pages which increases the odds of reallocating over the freed file struct.
The exploit then calls dup2 on the dangling FD’s. The dup2 syscall will open another fd on the same open file structure that the original points to. In this case, the exploit is calling dup2 to verify that they successfully reallocated a fake file structure in the same place as the freed file structure. dup2 will increment the reference count (f_count) in the file structure. In all of our fake file structures, the f_count was set to 0x7F. So if any of them are incremented to 0x80, the exploit knows that it successfully reallocated over the freed file struct.
To determine if any of the file struct’s refcounts were incremented, the exploit iterates through each of the directories under /sys/kernel/debug/mali/mem/ and reads each directory’s mem_profile contents. If it finds the byte 0x80, then it knows that it successfully reallocated the freed struct and that the f_count of the fake file struct was incremented.
Overwriting the addr_limit
Like many previous Android exploits, to gain arbitrary kernel read and write, the exploit overwrites the kernel address limit (addr_limit). The addr_limit defines the address range that the kernel may access when dereferencing userspace pointers. For userspace threads, the addr_limit is usually USER_DS or 0x7FFFFFFFFF. For kernel threads, it’s usually KERNEL_DS or 0xFFFFFFFFFFFFFFFF.
Userspace operations only access addresses below the addr_limit. Therefore, by raising the addr_limit by overwriting it, we will make kernel memory accessible to our unprivileged process. The exploit uses the syscall signalfd with the dangling fd to do this.
signalfd(dangling_fd, 0xFFFFFF8000000000, 8);
According to the man pages, the syscall signalfd is:
signalfd() creates a file descriptor that can be used to accept signals targeted at the caller. This provides an alternative to the use of a signal handler or sigwaitinfo(2), and has the advantage that the file descriptor may be monitored by select(2), poll(2), and epoll(7).
int signalfd(int fd,const sigset_t *mask,int flags);
The exploit called signalfd on the file descriptor that was found to replace the freed one in the previous step. When signalfd is called on an existing file descriptor, only the mask is updated based on the mask passed as the argument, which gives the exploit an 8-byte write to the signmask of the signalfd_ctx struct..
typedef unsigned long sigset_t; struct signalfd_ctx { sigset_t sigmask;};
The file struct includes a field called private_data that is a void *. File structs for signalfd file descriptors store the pointer to the signalfd_ctx struct in the private_data field. As shown above, the signalfd_ctx struct is simply an 8 byte structure that contains the mask.
Let’s walk through how the signalfd source code updates the mask:
SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *, user_mask, size_t, sizemask, int, flags){ sigset_t sigmask; struct signalfd_ctx *ctx; /* Check the SFD_* constants for consistency. */ BUILD_BUG_ON(SFD_CLOEXEC != O_CLOEXEC); BUILD_BUG_ON(SFD_NONBLOCK != O_NONBLOCK); if (flags & ~(SFD_CLOEXEC | SFD_NONBLOCK)) return -EINVAL; if (sizemask != sizeof(sigset_t) || copy_from_user(&sigmask, user_mask, sizeof(sigmask))) return -EINVAL; sigdelsetmask(&sigmask, sigmask(SIGKILL) | sigmask(SIGSTOP)); signotset(&sigmask); // [1] if (ufd == -1) { // [2] ctx = kmalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; ctx->sigmask = sigmask; /* * When we call this, the initialization must be complete, since * anon_inode_getfd() will install the fd. */ ufd = anon_inode_getfd(“[signalfd]”, &signalfd_fops, ctx, O_RDWR | (flags & (O_CLOEXEC | O_NONBLOCK))); if (ufd < 0) kfree(ctx); } else { // [3] struct fd f = fdget(ufd); if (!f.file) return -EBADF; ctx = f.file->private_data; // [4] if (f.file->f_op != &signalfd_fops) { // [5] fdput(f); return -EINVAL; } spin_lock_irq(¤t->sighand->siglock); ctx->sigmask = sigmask; // [6] WRITE! spin_unlock_irq(¤t->sighand->siglock); wake_up(¤t->sighand->signalfd_wqh); fdput(f); } return ufd;}
First the function modifies the mask that was passed in. The mask passed into the function is the signals that should be accepted via the file descriptor, but the sigmask member of the signalfd struct represents the signals that should be blocked. The sigdelsetmask and signotset calls at [1] makes this change. The call to sigdelsetmask ensures that the SIG_KILL and SIG_STOP signals are always blocked so it clears bit 8 (SIG_KILL) and bit 18 (SIG_STOP) in order for them to be set in the next call. Then signotset flips each bit in the mask. The mask that is written is ~(mask_in_arg & 0xFFFFFFFFFFFBFEFF).
The function checks whether or not the file descriptor passed in is -1 at [2]. In this exploit’s case it’s not so we fall into the else block at [3]. At [4] the signalfd_ctx* is set to the private_data pointer.
The signalfd manual page also says that the fd argument “must specify a valid existing signalfd file descriptor”. To verify this, at [5] the syscall checks if the underlying file’s f_op equals the signalfd_ops. This is why the f_op was set to signalfd_ops in the previous section. Finally at [6], the overwrite occurs. The user provided mask is written to the address in private_data. In the exploit’s case, the fake file struct’s private_data was set to the addr_limit pointer. So when the mask is written, we’re actually overwriting the addr_limit.
The exploit calls signalfd with a mask argument of 0xFFFFFF8000000000. So the value ~(0xFFFFFF8000000000 & 0xFFFFFFFFFFFCFEFF) = 0x7FFFFFFFFF, also known as USER_DS. We’ll talk about why they’re overwriting the addr_limit as USER_DS rather than KERNEL_DS in the next section.
Working Around UAO and PAN
“User-Access Override” (UAO) and “Privileged Access Never” (PAN) are two exploit mitigations that are commonly found on modern Android devices. Their kernel configs are CONFIG_ARM64_UAO and CONFIG_ARM64_PAN. Both PAN and UAO are hardware mitigations released on ARMv8 CPUs. PAN protects against the kernel directly accessing user-space memory. UAO works with PAN by allowing unprivileged load and store instructions to act as privileged load and store instructions when the UAO bit is set.
It’s often said that the addr_limit overwrite technique detailed above doesn’t work on devices with UAO and PAN turned on. The commonly used addr_limit overwrite technique was to change the addr_limit to a very high address, like 0xFFFFFFFFFFFFFFFF (KERNEL_DS), and then use a pair of pipes for arbitrary kernel read and write. This is what Jann and I did in our proof-of-concept for CVE-2019-2215 back in 2019. Our kernel_write function is shown below.
void kernel_write(unsigned long kaddr, void *buf, unsigned long len) { errno = 0; if (len > 0x1000) errx(1, “kernel writes over PAGE_SIZE are messy, tried 0x%lx”, len); if (write(kernel_rw_pipe[1], buf, len) != len) err(1, “kernel_write failed to load userspace buffer”); if (read(kernel_rw_pipe[0], (void*)kaddr, len) != len) err(1, “kernel_write failed to overwrite kernel memory”);}
This technique works by first writing the pointer to the buffer of the contents that you’d like written to one end of the pipe. By then calling a read and passing in the kernel address you’d like to write to, those contents are then written to that kernel memory address.
With UAO and PAN enabled, if the addr_limit is set to KERNEL_DS and we attempt to execute this function, the first write call will fail because buf is in user-space memory and PAN prevents the kernel from accessing user space memory.
Let’s say we didn’t set the addr_limit to KERNEL_DS (-1) and instead set it to -2, a high kernel address that’s not KERNEL_DS. PAN wouldn’t be enabled, but neither would UAO. Without UAO enabled, the unprivileged load and store instructions are not able to access the kernel memory.
The way the exploit works around the constraints of UAO and PAN is pretty straightforward: the exploit switches the addr_limit between USER_DS and KERNEL_DS based on whether it needs to access user space or kernel space memory. As shown in the uao_thread_switch function below, UAO is enabled when addr_limit == KERNEL_DS and is disabled when it does not.
/* Restore the UAO state depending on next’s addr_limit */void uao_thread_switch(struct task_struct *next){ if (IS_ENABLED(CONFIG_ARM64_UAO)) { if (task_thread_info(next)->addr_limit == KERNEL_DS) asm(ALTERNATIVE(“nop”, SET_PSTATE_UAO(1), ARM64_HAS_UAO)); else asm(ALTERNATIVE(“nop”, SET_PSTATE_UAO(0), ARM64_HAS_UAO)); }}
The exploit was able to use this technique of toggling the addr_limit between USER_DS and KERNEL_DS because they had such a good primitive from the use-after-free and could reliably and repeatedly write a new value to the addr_limit by calling signalfd. The exploit’s function to write to kernel addresses is shown below:
The function takes three arguments: the kernel address to write to (kaddr), a pointer to the buffer of contents to write (buf), and the length of the buffer (buf_len). buf is in userspace. When the kernel_write function is entered, the addr_limit is currently set to USER_DS. At [1] the exploit writes the buffer pointer to the pipe. A pointer to the USER_DS value is written to the pipe at [2].
The set_addr_limit_to_KERNEL_DS function at [3] sends a signal to tell another process in the exploit to call signalfd with a mask of 0. Because signalfd performs a NOT on the bits provided in the mask in signotset, the value 0xFFFFFFFFFFFFFFFF (KERNEL_DS) is written to the addr_limit.
Now that the addr_limit is set to KERNEL_DS the exploit can access kernel memory. At [4], the exploit reads from the pipe, writing the contents to kaddr. Then at [5] the exploit returns addr_limit back to USER_DS by reading the value from the pipe that was written at [2] and writing it back to the addr_limit. The exploit’s function to read from kernel memory is the mirror image of this function.
I deliberately am not calling this a bypass because UAO and PAN are acting exactly as they were designed to act: preventing the kernel from accessing user-space memory. UAO and PAN were not developed to protect against arbitrary write access to the addr_limit.
Post-exploitation
The exploit now has arbitrary kernel read and write. It then follows the steps as seen in most other Android exploits: overwrite the cred struct for the current process and overwrite the loaded SELinux policy to change the current process’s context to vold. vold is the “Volume Daemon” which is responsible for mounting and unmounting of external storage. vold runs as root and while it’s a userspace service, it’s considered kernel-equivalent as described in the Android documentation on security contexts. Because it’s a highly privileged security context, it makes a prime target for changing the SELinux context to.
As stated at the beginning of this post, the sample obtained was discovered in the preparatory stages of the attack. Unfortunately, it did not include the final payload that would have been deployed with this exploit.
Conclusion
This in-the-wild exploit chain is a great example of different attack surfaces and “shape” than many of the Android exploits we’ve seen in the past. All three vulnerabilities in this chain were in the manufacturer’s custom components rather than in the AOSP platform or the Linux kernel. It’s also interesting to note that 2 out of the 3 vulnerabilities were logic and design vulnerabilities rather than memory safety. Of the 10 other Android in-the-wild 0-days that we’ve tracked since mid-2014, only 2 of those were not memory corruption vulnerabilities.
The first vulnerability in this chain, the arbitrary file read and write, CVE-2021-25337, was the foundation of this chain, used 4 different times and used at least once in each step. The vulnerability was in the Java code of a custom content provider in the system_server. The Java components in Android devices don’t tend to be the most popular targets for security researchers despite it running at such a privileged level. This highlights an area for further research.
Labeling when vulnerabilities are known to be exploited in-the-wild is important both for targeted users and for the security industry. When in-the-wild 0-days are not transparently disclosed, we are not able to use that information to further protect users, using patch analysis and variant analysis, to gain an understanding of what attackers already know.
The analysis of this exploit chain has provided us with new and important insights into how attackers are targeting Android devices. It highlights a need for more research into manufacturer specific components. It shows where we ought to do further variant analysis. It is a good example of how Android exploits can take many different “shapes” and so brainstorming different detection ideas is a worthwhile exercise. But in this case, we’re at least 18 months behind the attackers: they already know which bugs they’re exploiting and so when this information is not shared transparently, it leaves defenders at a further disadvantage.
This transparent disclosure of in-the-wild status is necessary for both the safety and autonomy of targeted users to protect themselves as well as the security industry to work together to best prevent these 0-days in the future.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of the cookies. Cookie & Privacy Policy
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
