Western Digital and Kioxia cut production at two plants in Japan after contamination was discovered in raw materials, which will likely lead to price hikes and further strain on the already-taxed supply chain.
Western Digital and Kioxia are some of the largest producers of flash memory in the industry. Contaminated materials in plants at Yokkaichi and Kitakami have led to limited production of flash memory, which is expected to impact the rest of the industry.
According to a report from Bloomberg, it isn’t clear how extensive the disruption will be. Western Digital reports an expected reduction in its supply by about 6.5 exabytes (6.5 million terabytes). A Wells Fargo analyst says when combined with Kioxia’s loss of production, the number would be about 16 exabytes lost.
Flash memory prices will rise as a result. This will combine with other industry price hikes due to supply shortages.
However, Samsung and Micron may be able to limit industry impact with their own flash memory production. Since flash memory is an industry-standard, the components can be sourced from any company.
Where to buy an SSD?
We’ve lined up some reputable SSD vendors at attractive prices for our readers.
Sponsored Links
Flash memory is used to produce modern solid-state memory used in products like iPhone, iPad, Mac, and Apple Watch. While Samsung is a major producer of these components, a reduction in supply from two other major suppliers will place increased demand on Samsung’s output.
Production affected
Western Digital and Kioxia did not provide an estimate for when production will be restored. The total impact of their loss of production is estimated to be about 10% of the market consumption for a quarter.
Kioxia’s statement did provide some positive insight by pointing out that the product line impacted produced 3D flash, which is newer and more expensive. It estimates that shipments of its conventional 2D NAND flash memory will not be affected.
Newly Declassified Documents Reveal Previously Secret CIA Bulk Collection, Problems With CIA Handling of Americans’ Information
Senators Call for Critically Needed Transparency About CIA Bulk Collection; Documents Declassified at Wyden and Heinrich’s Request
Washington, D.C. – U.S. Senator Ron Wyden, D-Ore., and Sen. Martin Heinrich, D-N.M., both members of the Senate Intelligence Committee, called for new transparency about bulk surveillance conducted by the Central Intelligence Agency, following the release of documents that revealed a secret bulk collection program and problems with how the agency searches and handles Americans’ information.
Wyden and Heinrich requested the declassification of a report by the Privacy and Civil Liberties Oversight Board on a CIA bulk collection program, in a letter sent April 13, 2021. The letter, which was declassified and made public today reveals that “the CIA has secretly conducted its own bulk program,” authorized under Executive Order 12333, rather than the laws passed by Congress.
The letter notes that the program was “entirely outside the statutory framework that Congress and the public believe govern this collection, and without any of the judicial, congressional or even executive branch oversight that comes from [Foreign Intelligence Surveillance Act] collection.”
“FISA gets all the attention because of the periodic congressional reauthorizations and the release of DOJ, ODNI and FISA Court documents,” said Senators Wyden and Heinrich in response to the newly declassified documents.“But what these documents demonstrate is that many of the same concerns that Americans have about their privacy and civil liberties also apply to how the CIA collects and handles information under executive order and outside the FISA law. In particular, these documents reveal serious problems associated with warrantless backdoor searches of Americans, the same issue that has generated bipartisan concern in the FISA context.”
Wyden and Heinrich called for more transparency from the CIA, including what kind of records were collected and the legal framework for the collection. The PCLOB report noted problems with CIA’s handling and searching of Americans’ information under the program.
“While we appreciate the release of the ‘Recommendations from PCLOB Staff’ which highlights problems associated with the handling of Americans’ information, our letter also stressed that the public deserves to know more about the collection of this information. The DNI and the CIA Director have started this process. We intend to continue to urge them to achieve the transparency the American people deserve.”
Apple has released security updates for iOS, iPadOS, macOS, and Safari to address a new WebKit flaw that it said may have been actively exploited in the wild, making it the company’s third zero-day patch since the start of the year.
Tracked as CVE–2022-22620, the issue concerns a use-after-free vulnerability in the WebKit component that powers the Safari web browser and could be exploited by a piece of specially crafted web content to gain arbitrary code execution.
Actively Exploited In The Wild
“Apple is aware of a report that this issue may have been actively exploited,” the company said in a terse statement acknowledging in-the-wild attacks leveraging the flaw.
The iPhone maker credited an anonymous researcher for discovering and reporting the flaw, adding it remediated the issue with improved memory management.
Apple Releases Updates to Patch The Flaw
The updates are available for iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation), macOS devices running Big Sur and macOS Catalina, and also as a standalone update for Safari.
The latest fix brings the tally of zero-day patches issued by Apple for 2022 to three, including CVE-2022-22587 and CVE-2022-22594, that could have been exploited to run arbitrary code and track users’ online activity in the web browser.
Learn how to use Hydra to Brute-force SSH. Hydra is one of the favorite tools in a whitehats toolkit. It is an excellent tool for performing brute force attacks and can be used from a red team perspective to break into systems as well as from a blue team perspective to audit and test ssh passwords against common password lists like rockyou.txt and crackstation wordlists.
Note : This guide is purely for educational purposes. We do not claim liability for any property damages caused with the use of the knowledge gained from this guide.
What is Hydra?
Hydra is an open-source tool that allows us to perform various kinds of brute force attacks using wordlists. It comes by default with all Pentesting Distros like Kali Linux. However, it can also be installed with the apt command as follows:
$ sudoapt installhydra
In case the package is not found, or you run into an error, you can also refer to the Github repo and install it using the specified instructions.
How to Use Hydra?
Hydra offers a lot of functionality which can be easily displayed with :
$ hydra -h
However, in our case we will be dealing with the following four primary flags :
-l -> Specify a username to use during brute force attack
-L -> Specify a wordlist of usernames to be used during the bruteforce attack
-p -> Specify a password to use during brute force attack
-P -> Specify a wordlist of passwords to be used during the bruteforce attack
Brute-force SSH Usernames and Passwords with Hydra
While trying to brute-force ssh credentials there are 3 possible combinations:
Bruteforcing Passwords
Bruteforcing Usernames
Bruteforcing Passwords and Usernames
First things first we would need wordlists for our brute-force attack. You can fetch some well knows wordlists with wordlistctl and once you have your wordlist ready, we can move on !
1. Bruteforcing Passwords
To brute-force ssh passwords with a known username, the syntax is :
$ hydra -l <username> -P <path to wordlist> <IP> ssh
2. Bruteforcing Username
To brute-force ssh usernames with a known password, the syntax is :
$ hydra -L <path to wordlist> -p <password> <IP> ssh
3. Bruteforcing Both Usernames And Passwords
If you do not know both the username and the password, the syntax is as follows:
$ hydra -L <path to username wordlist> -P <path to password wordlist> <IP> ssh
Some Special Flags
Sometimes we have some special conditions and we need to orchestrate our attack according to that. In this section, we will discuss some special flags which helps us to customize our attacks.
1. Change The Number Of Threads
By default, hydra runs 16 threads but we can change the value of the same with the -t flag as such :
$ hydra -l <username> -P <path to wordlist> <IP> -t <number of threads> ssh
2. Change The Port Number
Sometimes, sysadmins change the ssh port number from the default 22 to some other port. Hence, to use a different port number, we use the -s flag as :
Just like we can bruteforce a list of usernames and passwords, we can also brute-force ssh IPs from a list using the -M flag :
$ hydra -l <username> -P <path to wordlist> -M <path to Ip list> ssh
4. Miscellaneous
We can also enable a more verbose output with the -V flag. Also, sometimes the users/sysadmins leave certain obvious passwords that need to be accounted for beyond the scope of our wordlists which can be included with the -e flag. A popular trio that goes with this flag are the letters ‘nsr’, where ‘n’ stands for null and tries to log in without any flag at all, ‘s‘ stands for same, i.e, it uses the username itself as a password while ‘r‘ tries the reversed username as a potential password. The syntax for this should look like this :
Hydra can be a pretty powerful tool when you want to brute-force ssh connections and can be coupled with several other flags to customize your attack. However, this must not be exploited to poke around stuff you are not meant to and the users alone are accountable for their actions.
Guidance comes a day after Joe Biden told US citizens in Ukraine ‘things could go crazy very quickly’
Britons are being advised against all travel to Ukraine and those already in the country are being told to leave while they can.
The action came as Boris Johnson told world leaders he “feared for the security of Europe” over the threat of a Russian invasion of Ukraine.
And the White House on Friday stated its belief that Russian military aggression against its neighbour could begin “any day now” – including during the current Winter Olympics, which are scheduled to end on 20 February.
On Friday evening, the Foreign Office issued updated travel guidance to advise UK citizens “against all travel to Ukraine”.
“British nationals in Ukraine should leave now while commercial means are still available,” the updated advice added.
“Since January 2022, the build-up of Russian forces on Ukraine’s borders has increased the threat of military action.
“Due to this increased threat, the FCDO has taken the decision to further withdraw embassy staff from Kyiv.
“The embassy remains open but will be unable to provide in-person consular assistance. British nationals should leave while commercial options remain.”
The action copies that taken by the US government, who were already advising Americans against travelling to Ukraine due to “the increased threats of Russian military action”.
The State Department is also urging all those US citizens currently in Ukraine to leave the country now.
PM tells allies he ‘fears for security of Europe’
In a virtual meeting on Friday evening, the prime minister spoke with the leaders of the US, Italy, Poland, Romania, France, Germany, the EU, and NATO.
“The prime minister told the group that he feared for the security of Europe in the current circumstances,” a Downing Street spokesperson said.
“He impressed the need for NATO allies to make it absolutely clear that there will be a heavy package of economic sanctions ready to go, should Russia make the devastating and destructive decision to invade Ukraine.
“The prime minister added that President [Vladimir] Putin had to understand that there would be severe penalties that would be extremely damaging to Russia’s economy, and that allies needed to continue with efforts to reinforce and support the Eastern frontiers of NATO.
“He urged the leaders to work together to deliver economic and defensive support to Ukraine.”
But the spokesperson added that world leaders had agreed, if Mr Putin “deescalated”, there would be “another way forward” as they “pledged to redouble diplomatic efforts in the coming days”.
After the virtual meeting between Mr Johnson, US President Joe Biden and other world leaders, White House national security adviser Jake Sullivan said Russia now had enough forces to conduct a major military operation against Ukraine.
An assault could begin “any day now” and “could occur before the Olympics have ended”, Mr Sullivan told a televised briefing as he urged any American still in Ukraine to leave in the next 24-48 hours.
“The risk is high enough and the threat is now immediate enough that prudence demands that it is the time to leave now,” he said.
“We are not saying that a decision has been taken by President Putin.
“What we are saying is that we have a sufficient level of concern based on what we are seeing on the ground, and what our intelligence analysts have picked up, that we are sending this clear message.”
UK-Russia relations ‘above zero’
Earlier in the day, Defence Secretary Ben Wallace had continued those diplomatic efforts as he held talks with his Russian counterpart in Moscow.
Mr Wallace described the discussions as “constructive and frank” and said that relations between Russia and Britain were “above zero” following the first meeting between a UK defence minister and Russia’s Sergei Shoigu since 2013.
Stressing the need for talks to prevent “miscalculation and escalation”, Mr Wallace expressed his hope that Friday’s meeting had contributed to a “better atmosphere” between the two sides.
“When they say to me they are not going to invade Ukraine we will take that seriously but, as I also said, we will look at the actions that accompany it,” the defence secretary said.
Mr Wallace also agreed with a US assessment that a Russian invasion of Ukraine could happen “at any time”, amid the ongoing joint military drills between Russia and Belarus.
“The disposition of the Russian forces that we see – over 100,000 in both Belarus and Ukraine – obviously gives that size of force the ability to do a whole range of actions, including an invasion of a neighbouring country at any time,” he said.
“We obviously have made it very clear in NATO that an invasion would have tragic consequences and we are here, and I’m here today for example, to seek a way of whatever we can to deescalate that tension.
“I heard clearly from the Russian government that they had no intention of invading Ukraine. And I also heard some of their concerns.”
The past three months have been a particularly challenging time for security teams. 2021 rounded off in the most spectacular fashion—if you can call it that—with the discovery of the Log4Shell vulnerability leaving security teams scrambling to identify and fix systems before threat actors could exploit. We’ve written a considerable amount on the issues surrounding Log4Shell, with our previous blogs covering the initial scope following the disclosure, an update on a second vulnerability related to Log4j, and the aftermath of threat actors targeting the bug.
As with any period of upheaval and turmoil, other issues will be missed or otherwise kicked down the priority list. While Log4j is incredibly serious and should be patched with the highest priority, there are several nasty vulnerabilities that can also cause significant disruption in 2022. Don’t panic, though. We’ve got you covered by highlighting these vulnerabilities through the prism of our new vulnerability intelligence solution that’s available in SearchLight. If you haven’t had a chance to glance through this new feature, please take a look at our blog here and our solutions guide, detailing this fantastic product in great detail.
WHY IS VULNERABILITY INTELLIGENCE SO IMPORTANT?
The best place to start this blog is to detail the importance of vulnerability intelligence, which is emerging as one of the key threat intelligence use cases. Vulnerability intelligence allows organizations to reduce the noise of the thousands of active vulnerabilities in circulation and take a risk-based approach in prioritizing the vulnerabilities that matter the most. A risk-based approach is determined by looking at the current threat landscape, which can provide intelligence on the risk posed by each vulnerability. Factors determining this risk can include its exploitability, the scale of devices the vulnerability affects, and interest from malicious actors. Vulnerability intelligence, in the end, exists to provide actionable insights for vulnerability management, allowing organizations to move away from an obsolete approach of attempting to fix everything.
WHICH VULNERABILITIES WERE EXPLOITED IN Q4 2021?
Digital Shadows identified 260 vulnerabilities through referenced intelligence as having been exploited in Q4 2021. Referenced intel can be defined as entries collected by crawlers parsing a range of sources (e.g., Twitter, Git) before assigning tag associations in Searchlight, depending on their content. A breakdown of the 260 vulnerabilities by VulDb 3.0 CVSS score can be seen in the graphic below, with the majority of the exploited vulnerabilities from this period being within the range of CVSS score of 7-8 (high). This emphasizes that while critical vulnerabilities of course need to be addressed in a timely manner, the pinch point for threat actor exploitation is often in the middle range, targeting vulnerabilities that potentially may have been overlooked by security teams; this does however likely reflect the typical bell curve of CVSS scores. Most fall within the range of around 5-7.
Q4 2021 Exploited CVEs identified by reference intel
In an ideal world, all of these vulnerabilities should be patched by security teams as soon as is feasible. If they’re being exploited in the wild, that means that threat actors have developed a method of using the vulnerabilities to solicit various malicious campaigns. If you have exposure to these, it’s only a matter of time before you see misuse on your network related to these bugs.
However, of these 260 associated with active exploitation, which is the priority? After all, taking a risk-based approach will always be the best way to remediate software bugs; fixing everything at once isn’t an option, and not all vulnerabilities present the same risk. In order to fine-tune our investigation, we used our new vulnerability intelligence filter within Searchlight to search for vulnerabilities that were exploited in the wild, known to be embedded in pentest tools, did not require user privileges or user interaction, were remotely exploitable, and had a CVSS score of 7.5 or higher. These tags represent just a fraction of the available filtering options; you can easily tune searches based on your specific organizational requirements.
THE VULNERABILITIES YOU MAY HAVE MISSED OVER LOG4J
In addition to Log4Shell, also included in this smaller pool of 6 vulnerabilities were the ProxyLogon and ProxyShell vulnerabilities that we’ve discussed in great depth before —and which we’ll touch upon later—and three other vulnerabilities that you might not have heard about or otherwise missed during this frantic period.
The one that allows RCE on MSHTML (CVE-2021-40444)
We want to start on CVE-2021-40444, a critical remote code execution (RCE) vulnerability that attackers can exploit to execute any code or commands on a target machine without the owner’s knowledge. This vulnerability impacts MSHTML, a core component in Windows, allowing the OS to render web pages. Although it’s most commonly associated with Internet Explorer, this component is also used in other software, including Skype, Microsoft Outlook, Visual Studio, and others. Spotting the potential impact of this vulnerability, Microsoft swiftly moved to issue a mitigation with an update following September’s Patch Tuesday update.
The bug has garnered significant attention from threat actors since August 2021. Microsoft first identified that threat actors were exploiting CVE-2021-40444 through specially crafted Microsoft Office documents to run malicious code, many of which were used to implant Cobalt Strike beacons onto networks; Cobalt Strike almost always is followed by further exploitation, with the commonly used penetration testing framework used by a diverse range of threat actors and groups. The observed attack vector relied on a malicious ActiveX control that could be loaded by the browser rendering engine using a malicious Office document. These were reportedly delivered via emails impersonating contracts and legal agreements, with the documents hosted on file-sharing sites. The malicious document then retrieves a cabinet (CAB) file that remotely loads the Cobalt Strike beacon loader when executed. An attack chain for this vulnerability can be seen in the graphic below, with Microsoft naming the associated threat actor “DEV-0413”.
Attack chain for activity targeted CVE-2021-40444 August 2021 (Source: Microsoft)
Other exploitation attempts in December 2021 have used a CAB-less version of the attack by using a different compressed file format, a RAR archive. The attack resulted in the distribution of the FormBook malware, a common infostealer first identified in 2016. The attack reportedly can evade the original patch issued by Microsoft, once again highlighting the persistence and agility of threat actors in finding new ways to target vulnerabilities, even after they have been fixed.
One key feature of the exploitation of CVE-2021-40444 that makes this vulnerability so dangerous is a key feature of Microsoft Office in ensuring protection from malicious external documents can easily be bypassed. If an Office document has been downloaded from the Internet or sent as an email attachment, it should contain a bit of extra information in its alternate data stream (ADS). In the case of a downloaded document, it should contain the ‘mark of the web’ (MOTW), which leads to Microsoft Office opening that document in Protected View. Protected View has been confirmed to prevent the automatic execution of this vulnerability.
Humans are, however, naturally curious, and many will ignore these warnings and click to ignore protected view, thus allowing the malicious document to exploit the vulnerability. If an Office document is delivered via a ZIP file—and the Office document is extracted locally onto the disk—the Zone.Identifier may not be present and the exploit will run once the document is opened. The exploit has also been observed to run when a document is previewed in Windows Explorer. It seems pretty obvious advice, but be aware of what you are enabling and always treat documents received from unknown or unverified sources with the highest levels of suspicion.
The one granting GOD-like privileges (CVE-2021-38647 / CVE-2021-38648)
Another series of vulnerabilities that were identified through our triage of exploited vulnerabilities in Q4 is CVE-2021-38647, a RCE vulnerability affecting the Open Management Instrumentation (OMI). This RCE coincides with three other high severity vulnerabilities, CVE-2021-38648, CVE-2021-38645, and CVE-2021-38649, which together have been appropriately named OMIGOD. OMI is an open-source Web-Based Enterprise Management (WBEM) implementation for managing Linux and UNIX systems. Several Azure Virtual Machine (VM) management extensions use OMI to orchestrate configuration management and log collection on Linux VMs. The originating researchers who discovered this vulnerability have compared OMI to Window Management Instrumentation (WMI) that is used in Linux/Unix systems.
OMI is installed in a vast repertoire of Microsoft Azure products, including Azure Automation, Azure Automatic Update and Azure Log Analytics. This factor is also exacerbated since OMI is reportedly installed without the customer’s knowledge. OMI is automatically installed on user’s devices during setup and runs with the highest privileges. As demonstrated by the discussion board query below, many users have been frustrated with the lack of documentation detailing what OMI is and why it’s required.
Discussion board query related to OMI (Source: Wiz)
The originating researchers clarified that OMIGOD allowed external or lower privileged users to execute code on targeted machines or to escalate privileges. Microsoft fixed the bug in September 2021; however, reportedly will still issue vulnerable versions of the OMI agents for new Linux VMs created in Azure. Users looking to update will also be forced to manually update their susceptible Azure systems, as Microsoft has no mechanism available to auto-update vulnerable agents on all impacted Azure Linux machines. Threats known to be targeting OMIGOD include the Mirai botnet, which reportedly closed the 5896 OMI SSL port after gaining persistence on a susceptible device. Mirai’s operators likely conducted this activity to stop the exploit for OMIGOD being open to other threats, which highlights how easy to exploit the bug is.
So just to summarise; OMIGOD is highly exploitable and can provide attackers with significant opportunities, will likely fly under the radar due to the lack of awareness of OMI, and ultimately is extremely difficult for admins to patch. Combining all these factors makes OMIGOD a serious risk that we don’t believe has received the necessary attention it deserves.
The one exploited by China-linked “Iron Husky” (CVE-2021-40449)
Another vulnerability that needs to be discussed is CVE-2021-40449, a privilege escalation vulnerability affecting several versions of Windows Server and client systems and may be used to escalate privileges on an already compromised system. This bug was initially divulged back to the security community in October, with the exploitation of the vulnerability occurring almost immediately following its disclosure. A timeline of the vulnerability lifecycle can be seen on Searchlight portal profile in the graphic below.
Lifecycle of CVE-2021-40449
The bug, which has been incorporated on threat actor pen-testing tools, has been targeted by a China-linked advanced persistent threat (APT) group named “IronHusky,” which has conducted intrusions since 2016. IronHusky reportedly targeted the vulnerability in Win32k.sys, a legitimate file process developed by Microsoft and part of the Graphics Device Interface (GDI). Attackers could use the vulnerability to install a remote access trojan (RAT) named “MysterySnail” which can execute Windows shell commands, gather information about the disks and folders, delete, read and upload files, kill processes, and more. Analysis of MysterySnail allowed researchers to attribute to IronHusky, who has previously conducted a range of cyber espionage operations, likely prioritized geopolitical reasons.
WHICH VULNERABILITIES WERE ASSOCIATED WITH MALWARE OR RANSOMWARE ACTORS?
Digital Shadows identified 87 vulnerabilities associated with ransomware activity which received our intelligence updates from Q4 2021 (a breakdown of this data by year of CVE assignment can be seen in the graphic below). As you’d expect, a significant percentage of these vulnerabilities were disclosed in 2021, highlighting the importance for companies to remediate recent vulnerabilities before cybercriminals have a chance to exploit them. New vulnerabilities will always solicit interest for ransomware groups, and with half of all exploits emerging in the two weeks following disclosure, organizations only have a short amount of time to patch before seeing live attacks in the wild.
However, new vulnerabilities may not necessarily be the most critical to patch for an organization. Many older vulnerabilities also continue to be targeted by cybercriminal groups; What’s the reason for this? Well, many companies still operate with the “if it’s not broken, why fix it” mindset. If organizations continue to leave gaps on their networks from older vulnerabilities, threat actors will continue to exploit them. At the end of the day, most threat actors are opportunistic in nature and would rather go for the low hanging fruit rather than developing expensive and sophisticated tools to exploit the latest, shiniest CVE out there.
Q4 ransomware associated CVEs by year of CVE assignment
The inglorious “ProxyShell” ones (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207)
So, where better to start discussing ransomware-associated CVEs than the ProxyShell bugs initially discovered in July 2021 to quite the fan fair. ProxyShell is the name of an exploit utilizing three chained Microsoft Exchange vulnerabilities (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) that allow unauthenticated, remote code execution on unpatched vulnerable servers. ProxyShell followed the four “Proxylogon” vulnerabilities that were identified in March 2021 (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065), and just to complicate matters further, “ProxyToken” (CVE-2021-33766).
As highlighted in our recent update blog on ransomware activity in Q4 2021, Proxyshell has been targeted by multiple ransomware groups. Of the groups targeting ProxyShell, Conti, the second most active group during this period, was perhaps most notable. Conti exploited Proxyshell as a medium to initially compromise networks. Conti followed a similar attack path to many other actors targeting Proxyshell by uploading web shells used to execute commands, download software, and further compromise the server. Once the threat actors gained complete control of the server, Conti moved to their typical routine of establishing liars of domain admins and endpoints, dumping LSASS to access other admin credentials, and spreading laterally. Persistence is also established by installing remote tools like Cobalt Strike and AnyDesk.
Conti is an enormous threat to business, which has been known to target a wide array of sectors and geographies and can turn over an attack in a rapid amount of time. If you haven’t patched for the Proxyshell vulnerabilities yet, now certainly would be a good time!
The one targeting QNAP Network Attached Storage (CVE-2021-28799)
If you’re an owner of a QNAP Network Attached Storage (NAS) device, you’ll want to tune in for this one. CVE-2021-28799 is an improper authorization vulnerability that affects QNAP NAS running HBS 3 (Hybrid Backup Sync). This bug was identified in April 2021, with exploitation beginning almost immediately. The QLocker ransomware exploited CVE-2021-28799 to access QNAP NAS devices and encrypt their files. The exploitation of this bug has since resumed in Q4 2021, with the “ech0raix” ransomware hitting susceptible QNAP devices in December 2021 and Qlocker returning to the well in January 2022. Other activity targeting QNAP NAS has been detected in late January, which was attributed to the DeadBolt ransomware.
Besides making sure devices are patched with the most recent update, QNAP has issued security advice for securing devices, which includes reducing the attack surface and several steps to harden security. Ensuring that devices are not internet facing is also a crucial step, which can remove the risk from several unsophisticated malware types like DeadBolt.
What older bugs are ransomware groups exploiting?
What about the older bugs we touched upon before? Well, why not go way back in time and start with CVE-2012-0158. This Microsoft Office bug has been in circulation in threat campaigns for many years, allowing threat actors to hijack Microsoft Word or Excel and force these programs to execute malicious code. This ancient bug was identified as within the top four vulnerabilities targeted by ransomware groups in 2020, and its use has continued into 2021. If you want an example of how organizations fail to identify and remediate old yet exploitable bugs, this is probably it.
Another older vulnerability that is also not being addressed by organizations is CVE-2019-7481, an SQL injection vulnerability affecting SonicWall Secure Remote Access (SRA) 4600 devices running firmware versions 8.x and 9.x. Targeting remote services—which heavily include VPN devices —has become a mainstay of cybercriminal and nation-state threat actors due to the increase in the use of such software brought on by the COVID-19 pandemic. Just like COVID-19, increased use of such software is here to stay.
Also worth your attention is CVE-2018-12808, which affects Adobe Acrobat Reader and has been used frequently to deliver ransomware via phishing emails and malicious PDF files. The use of CVE-218-12808 has been associated with the Ryuk ransomware group and their probable successor, Conti, as a method of gaining initial access to targeted companies. In November, you probably saw that the Emotet malware returned from a 10-month hiatus after initially being taken down by a law enforcement operation in January 2021. The developers of Emotet reportedly took this decision to return following pressure being placed on them by operators of Conti. The latter is known to have significantly used Emotet to facilitate initial access to target companies. Malicious Office documents and PDFs are a key part of Emotet malspam distribution, and bugs like those affecting Adobe Acrobat will likely continue within the attack lifecycle of groups like Conti.
The new Emotet infection malspam distribution (source: SANS ISC)
WHICH VULNERABILITIES WERE DISCUSSED IN CRIMINAL LOCATIONS?
Also available on Searchlight’s vulnerability intelligence portal is a filter for ‘discussed on criminal location.’ When used in conjunction with a date range for Q4 2021, 31 CVE’s were identified. This acts as a useful starting point to determine which CVEs are being targeted by threat actors, with common discussions involving exploitation methods, identification of susceptible systems, or other insights. These discussions can dramatically impact a CVE’s risk, and being aware of which CVEs are being discussed is a useful way to stay one step ahead.
Path traversal vulnerability (CVE-2021-41773)
CVE-2021-41773 is apath traversal vulnerability affecting Apache HTTP Server Project and originally identified on 29 Sep 2021, and exploited in the wild before being patched on 05 Oct 2021. This vulnerability only impacts Apache HTTP Server version 2.4.49 with the “require all denied” access control configuration disabled. Successful exploitation would give a remote attacker access to arbitrary files outside the document root on the vulnerable web server. Shodan searches in early October 2021 identified around 112,000 servers susceptible to this bug, which determines the scale of devices that attackers have to work with for this vulnerability.
The CVE quickly generated significant interest from cybercriminal actors on various forums. One threat actor was identified on a prominent cybercriminal forum on 08 Oct 2021, sharing two links to two GitHub submissions of exploits for “Path transversal & RCE Apache server” CVE-2021-41773 and CVE-2021-42013.” The user wrote that these vulnerabilities could be used to run a remote code execution through a path transversal directory or to access sensitive information on Apache HXXP server versions 2.4.49 and 2.4.50.
Cybercriminal forum user discussing exploits for CVE-2021-41773 and CVE-2021-42013 (details redacted)
Responses to this thread continued a theme of interest in targeting this specific vulnerability, with one user replying that “apache RCE exploits are always a good way to get servers”. Other threads related to this vulnerability identified methods of exploiting this bug, discussed issues with identifying the CVE using Shodan, and how certain commands could be used to illuminate susceptible servers. Apache remains the most popular web server across the globe—and as demonstrated by the recent Log4Shell bug—any exploitable CVEs affecting Apache will always generate significant threat actor interest.
File upload vulnerability (CVE-2021-22005)
Another vulnerability that generated interest from cybercriminal actors was CVE-2021-22005, a file upload vulnerability that can be used to execute commands on VMWare’s vCenter Server Appliance; vCenter is a server management solution that helps IT admins manage virtualized hosts and virtual machines in enterprise environments via a single console. Threat actors can exploit CVE-2021-22005 through vCenter Server Appliance connected over port 443 (HTTPS). The attackers would then be able to upload a specially crafted file that would result in the execution of embedded code.
Threat actor interest in this critical severity vulnerability began immediately following its disclosure on 23 Sep 2021, which was likely sparked by an incomplete proof of concept released by a researcher. The researcher claimed that the PoC—which was reportedly based on the workaround and patch that VMWare released—could be used by experienced developers to create a working exploit but would not be sufficient for lesser-skilled actors. However, a working exploit for CVE-2021-22005 was quickly established on 27 September. Cybercriminal discussions of methods to use the working exploit were identified in late December 2021; the two users highlighted in the image below discuss using standard commands to change passwords and add users on susceptible systems.
CYBERCRIMINAL POSTS RELATED TO CVE-2021-22005
The rapid increase in risk associated with this vulnerability adds fuel to the ongoing debate over whether security researchers should publish PoCs before organizations have had time to issue a patch. In June 2021, Github—which is now under the ownership of Microsoft—changed their policy to permit the removal of such items, which would minimize the risk of the exploits being used in live attacks. Microsoft will likely point to examples like CVE-2021-22005 when demonstrating that the public issue of even incomplete PoCs can quickly fall into the hands of malicious actors.
MAKING VULNERABILITY INTELLIGENCE WORK FOR YOU
As we’ve highlighted in this blog, vulnerability intelligence can be an incredible asset for fine-tuning your vulnerability management process. By understanding the context behind individual vulnerabilities, security teams can move away from solely using CVSS scores and instead focus on what matters to your organization. Too many vulnerabilities and far too little time are common sentiments among the security community; at Digital Shadows, we pride ourselves in allowing our clients to reduce the noise and focus on what matters. Taking a risk-based approach is the most effective method of targeting vulnerabilities, which will ultimately have the most significant impact on reducing your overall cyber risk.
With the uprise in AirTag tracking, without consent, here is some useful advice for people that are worried about Apple’s Trackers.
When the AirTag launched in 2021, Apple’s Bluetooth tracker with ultra-wideband was lauded as a step toward the future of augmented reality and a great way to find everyday objects, like your lost TV remote. Cybersecurity experts expressed concern that the tracking device would be exploited by stalkers. As we get closer to AirTag’s one-year anniversary, those warnings appear prescient.
Model Brooks Nader says an AirTag was secretly slipped into her coat during a night out in New York City. In Connecticut, a man was arrested and charged with stalking after police found an AirTag in the victim’s car. Police in multiple states have issued warnings about the potential criminal uses of AirTags.
Newer AirPods have tracking abilities similar to AirTags, but the higher cost of Apple’s earbuds limits their disposability as a tracking device. On February 10, Apple updated its support page for AirTags with additional information and a firm denouncement of using the device to track people. Reporting from 9to5Mac suggests further AirTag updates will be rolled out this year.
Even though Tile and other competitors to the AirTag exist, the vastness of Apple’s ecosystem sets the device apart. If you are concerned that a secret AirTag may be recording your location, these signs may help detect the tracker.
Signs an AirTag Is Tracking You
The type of smartphone you own affects how easily you can discover hidden AirTags. Owners of iPhones running iOS 14.5 or newer should receive a push alert whenever an unknown AirTag is nearby for an extended period of time and away from its owner. Apple’s website does not provide an exact time frame for when this alert is triggered.
When you click on the iPhone alert, you may be given the option to play a sound on the AirTag to help locate the device. Check that you will receive these alerts by going into the Find My app, choose the Me tab in the bottom-right corner, and make sure Item Safety Alerts is green and toggled to the right under Notifications.
Months after the release of the AirTag, Apple launched the Tracker Detect app for Android phones. Unlike the security features available for the iPhone, the Android app does not automatically look for unknown AirTags.
Users must initiate the scan.
According to Eva Galperin, director of cybersecurity at the Electronic Frontier Foundation, the reason for the app’s limited functionality is complicated. “This is actually a limitation of how the Android ecosystem works and how Android apps can work,” she says. “I have called on Apple and Android to work together to incorporate the level of mitigations that Apple provides in iOS into the Android operating system, but this requires a lot of cooperation between two groups who are normally rivals.”
While some guides to finding AirTags recommend using Bluetooth scanners, Galperin does not consider this method to be reliable for tracker searching. “I have tried using various Bluetooth scanners in order to detect AirTags, and they do not work all the time,” she says.
Millions of Americans still do not own a smartphone. Without a device on hand, you must rely on visual and audible clues to find any hidden AirTags. The circular white disc is slightly larger than a quarter. As reported by The New York Times, Ashley Estrada discovered an AirTag lodged under her license plate, and her video documenting the incident was viewed over 20 million times on TikTok.
When the AirTag was first released, the tracker would emit a beeping noise if away from the owner for longer than three days. Apple has since shortened the time to 24 hours or less. Despite the update, you might not want to rely only on sound to detect AirTags. Numerous videos on YouTube offer DIY instructions to disable the speaker, and noiseless versions of the trackers were even listed for a short time on Etsy.
What if I Find One?
The best way to disable an AirTag is to remove the battery. To do this, flip the AirTag so the metallic side with an Apple logo is facing you. Press down on the logo and turn counterclockwise. Now you will be able to remove the cover and pop out that battery.
Apple’s support page for the AirTag suggests reaching out to the police if you believe you are in a dangerous situation. “If you feel your safety is at risk, contact your local law enforcement, who can work with Apple to request information related to the item. You might need to provide the AirTag, AirPods, Find My network accessory, and the device’s serial number.”
One way to figure out the serial number is to hold the top of an iPhone or other near-field-communication-enabled smartphone to the white side of an AirTag. A website with the serial number will pop up. If you feel hesitant about scanning the AirTag or do not have the ability, a serial number is printed on the device beneath the battery.
Who Does This Affect?
In the viral stories shared online and in police reports, women are often the victims of AirTag stalking, but Galperin cautions against framing unwanted tracking as solely an issue for women. “I have been working with victims of tech-enabled abuse for many years,” she says, “and I would say that about two-thirds of the survivors that come to me are women. But a third of them are men. I suspect that number would be higher if there wasn’t such a stigma around being an abuse victim or survivor.”
She emphasized how men, women, and nonbinary people can all be victims of abuse, as well as perpetrators. “When we paint it all with this really broad brush, we make it really hard for victims who don’t fit that mold to come forward,” says Galperin.
In the spring of 2018, we launched the Open Data initiative to provide security teams and researchers with access to research data generated from Project Sonar and Project Heisenberg. Our goal for those projects is to understand how the attack surface is evolving, what exposures are most common or impactful, and how attackers are taking advantage of these opportunities. Ultimately, we want to be able to advocate for necessary remediation actions that will reduce opportunities for attackers and advance security. This is also why we publish extensive research reports highlighting key security learnings and mitigation recommendations.
Our goal for Open Data has been to enable others to participate in these efforts, increasing the positive impact across the community. Open Data was an evolution of our participation in the scans.io project, hosted by the University of Michigan. Our hope was that security professionals would apply the research data to their own environments to reduce their exposure and researchers would use the data to uncover insights to help educate the community on security best practices.
Changing times
Since we first launched Open Data, we’ve been mindful that sharing large amounts of raw data may not maximize value for recipients and lead to the best security outcomes. It is efficient for us, as it can be automated, but we have constantly sought more impactful and productive ways to share the data. Where possible, we’ve developed partnerships with key nonprofit organizations and government entities that share our goals and values around advancing security and reducing exposure. We’ve looked for ways to make the information more accessible for internal security teams.
Fast forward to 2021, and wow, what a few years we’ve had. We’ve faced a global pandemic, which has really brought home our increased reliance on connected technologies, and amplified the need for privacy protections and understanding of digital threats. During the past few years, we have also seen an evolving regulatory environment for data protection. Back in 2018, GDPR was just coming into effect, and everyone was trying to figure out its implications. In 2020, we saw California join the party with the introduction of CCPA. It seems likely we will see more privacy regulations follow.
The surprising thing is not this focus on privacy, which we wholeheartedly support, but rather the inclusion and control of IP addresses as personal data or information. We believe security research supports better security outcomes, which in turn enables better privacy. It’s fundamentally challenging to maintain privacy without understanding and addressing security challenges.
Yet IP addresses make up a significant portion of the data being shared in our security research data. While we believe there is absolutely a legitimate interest in processing this kind of data to advance cybersecurity, we also recognize the need to take appropriate balancing controls to protect privacy and ensure that the processing is “necessary and proportionate” — per the language of Recital 49.
Evolving data sharing
So what does this mean? To date, Open Data included two elements:
A free sign-up service that was subject to light vetting and terms of service, and provides access to current and historical research data
Free access (no account required) to a one-month window of recent data from Project Sonar shared on the Rapid7 website
Beginning today, the latter will no longer be available. For the former, we still want to be able to provide data to help security teams and researchers identify and mitigate exposures. Our goals and values on this have not changed in any way since the inception of Open Data. What has evolved — apart from the regulatory landscape — is our thinking on the best ways to do this.
For Rapid7 customers, we launched Project Doppler, a free tool that provides insight into an organization’s external exposures and attack surface. Digging their own specific information out of our mountain of internet-wide scan data is the use case most Rapid7 customers want, so Doppler makes that much, much easier.
We are working on how we might practically extend Project Doppler more broadly to be available for other internal infosec teams, while still protecting privacy in line with regulatory requirements.
For governments, ISACs, and other nonprofits working on security advocacy to reduce opportunities for attackers, please contact us; we believe we share a mission to advance security and want to continue to support you in this. We will continue to provide free access to the data with appropriate balancing controls (such as geo-filtering) and legal agreements (such as for data retention) in place.
For legitimate public research projects, we have a new submission process so you can request access to the Project Sonar data sets for a limited time and subject to conditions for sharing your findings to advance the public good. Please email research@rapid7.com for more information or to make a submission.
While it was not the primary goal or intention behind the Open Data initiative, we recognize that there are also entities using the data for commercial projects. We are not intentionally trying to hinder this, but per privacy regulations, we need to ensure we have more vetting and controls in place. If you are interested in discussing options for incorporating Project Sonar data into a commercial offering, please contact research@rapid7.com.
More advocacy, better outcomes
While these changes are being triggered by the evolving regulatory landscape, we believe that ultimately they will lead to more productive data sharing and better security outcomes. We’re still not sold on the view that IP addresses should be viewed as personal data, but we recognize the value of a more thoughtful and tailored approach to data sharing that both supports data protection values and also promotes more security advocacy and remediation action.
The French national data protection authority, CNIL, issued a formal notice to managers of an unnamed local website today arguing that its use of Google Analytics is in violation of the European Union’s General Data Protection Regulation, following a similar decision by Austria last month.
The root of the issue stems from the website’s use of Google Analytics, which functions as a tool for managers to track content performance and page visits. CNIL said the tool’s use and transfer of personal data to the U.S. fails to abide by landmark European regulations because the U.S. was deemed to not have equivalent privacy protections.
European regulators including CNIL have been investigating such complaints over the last two years, following a decision by the EU’s top court that invalidated the U.S.’s “Privacy Shield” agreement on data transfers. NOYB, the European Center for Digital Rights, reported 101 complaints in 27 member states of the EU and 3 states in the European Economic Area against data controllers who conduct the transatlantic transfers.
Privacy Shield, which went into effect in August of 2016, was a “self-certification mechanism for companies established in the United States of America,” according to CNIL.
Originally, the Privacy Shield was considered by the European Commission to be a sufficient safeguard for transferring personal data from European entities to the United States. However, in 2020 the adequacy decision was reversed due to no longer meeting standards.
An equivalency test was used to compare European and U.S. regulations which immediately established the U.S.’s failure to protect the data of non-U.S. citizens. European citizens would remain unaware that their data is being used and how it is being used, and they cannot be compensated for any misuse of data, CNIL found.
CNIL concluded that Google Analytics does not provide adequate supervision or regulation, and the risks for French users of the tool are too great.
“Indeed, if Google has adopted additional measures to regulate data transfers within the framework of the Google Analytics functionality, these are not sufficient to exclude the possibility of access by American intelligence services to this data,” CNIL said.
The unnamed site manager has been given a month to update its operations to be in compliance with GDPR. If the tool cannot meet regulations, CNIL suggests transitioning away from the current state of Google Analytics and replacing it with a different tool that does not transmit the data.
The privacy watchdog does not call for a ban of Google Analytics, but rather suggests revisions that follow the guidelines. “Concerning the audience measurement and analysis services of a website, the CNIL recommends that these tools be used only to produce anonymous statistical data, thus allowing an exemption from consent if the data controller ensures that there are no illegal transfers,” the watchdog said.
UPDATE(Feb 9, 2022): Microsoft initially patched this vulnerability without giving me any information or acknowledgement, and as such, at the time of patch release, I thought that the vulnerability was identified as CVE-2022–22718, since it was the only Print Spooler vulnerability in the release without any acknowledgement. I contacted Microsoft for clarification, and the day after the patch release, Institut For Cyber Risk and I was acknowledged for CVE-2022–21999.
In this blog post, we’ll look at a Windows Print Spooler local privilege escalation vulnerability that I found and reported in November 2021. The vulnerability got patched as part of Microsoft’s Patch Tuesday in February 2022. We’ll take a quick tour of the components and inner workings of the Print Spooler, and then we’ll dive into the vulnerability with root cause, code snippets, images and much more. At the end of the blog post, you can also find a link to a functional exploit.
Background
Back in May 2020, Microsoft patched a Windows Print Spooler privilege escalation vulnerability. The vulnerability was assigned CVE-2020–1048, and Microsoft acknowledged Peleg Hadar and Tomer Bar of SafeBreach Labs for reporting the security issue. On the same day of the patch release, Yarden Shafir and Alex Ionescu published a technical write-up of the vulnerability. In essence, a user could write to an arbitrary file by creating a printer port that pointed to a file on disk. After the vulnerability (CVE-2020–1048) had been patched, the Print Spooler would now check if the user had permissions to create or write to the file before adding the port. A week after the release of the patch and blog post, Paolo Stagno (aka VoidSec) privately disclosed a bypass for CVE-2020–1048 to Microsoft. The bypass was patched three months later in August 2020, and Microsoft acknowledged eight independent entities for reporting the vulnerability, which was identified as CVE-2020–1337. The bypass for the vulnerability used a directory junction (symbolic link) to circumvent the security check. Suppose a user created the directory C:\MyFolder\ and configured a printer port to point to the file C:\MyFolder\Port. This operation would be granted, since the user is indeed allowed to create C:\MyFolder\Port. Now, what would happen if the user then turned C:\MyFolder\ into a directory junction that pointed to C:\Windows\System32\ after the port had been created? Well, the Spooler would simply write to the file C:\Windows\System32\Port.
These two vulnerabilities, CVE-2020–1048 and CVE-2020–1337, were patched in May and August 2020, respectively. In September 2020, Microsoft patched a different vulnerability in the Print Spooler. In short, this vulnerability allowed users to create arbitrary and writable directories by configuring the SpoolDirectory attribute on a printer. What was the patch? Almost the same story: After the patch, the Print Spooler would now check if the user had permissions to create the directory before setting the SpoolDirectory property on a printer. Perhaps you can already see where this post is going. Let’s start at the beginning.
Introduction to Spooler Components
The Windows Print Spooler is a built-in component on all Windows workstations and servers, and it is the primary component of the printing interface. The Print Spooler is an executable file that manages the printing process. Management of printing involves retrieving the location of the correct printer driver, loading that driver, spooling high-level function calls into a print job, scheduling the print job for printing, and so on. The Spooler is loaded at system startup and continues to run until the operating system is shut down. The primary components of the Print Spooler are illustrated in the following diagram.
The print application creates a print job by calling Graphics Device Interface (GDI) functions or directly into winspool.drv.
GDI
The Graphics Device Interface (GDI) includes both user-mode and kernel-mode components for graphics support.
winspool.drv
winspool.drv is the client interface into the Spooler. It exports the functions that make up the Spooler’s Win32 API, and provides RPC stubs for accessing the server.
spoolsv.exe
spoolsv.exe is the Spooler’s API server. It is implemented as a service that is started when the operating system is started. This module exports an RPC interface to the server side of the Spooler’s Win32 API. Clients of spoolsv.exe include winspool.drv (locally) and win32spl.dll (remotely). The module implements some API functions, but most function calls are passed to a print provider by means of the router (spoolss.dll).
Router
The router, spoolss.dll, determines which print provider to call, based on a printer name or handle supplied with each function call, and passes the function call to the correct provider.
Print Provider
The print provider that supports the specified print device.
Local Print Provider
The local print provider provides job control and printer management capabilities for all printers that are accessed through the local print provider’s port monitors.
The following diagram provides a view of control flow among the local printer provider’s components, when an application creates a print job.
While this control flow is rather large, we will mostly focus on the local print provider localspl.dll.
Vulnerability
The vulnerability consists of two bypasses for CVE-2020–1030. I highly recommend reading Victor Mata’s blog post on CVE-2020–1030, but I’ll try to cover the important parts as well.
When a user prints a document, a print job is spooled to a predefined location referred to as the “spool directory”. The spool directory is configurable on each printer and it must allow the FILE_ADD_FILE permission to all users.
Permissions of the default spool directory
Individual spool directories are supported by defining the SpoolDirectory value in a printer’s registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\<printer>.
The Print Spooler provides APIs for managing configuration data such as EnumPrinterData, GetPrinterData, SetPrinterData, and DeletePrinterData. Underneath, these functions perform registry operations relative to the printer’s key.
We can modify a printer’s configuration with SetPrinterDataEx. This function requires a printer to be opened with the PRINTER_ACCESS_ADMINISTER access right. If the current user doesn’t have permission to open an existing printer with the PRINTER_ACCESS_ADMINISTER access right, there are two options:
The user can create a new local printer
The user can add a remote printer
By default, users in the INTERACTIVE group have the “Manage Server” permission and can therefore create new local printers, as shown below.
Security of the local print server on Windows desktops
However, it seems that this permission is only granted on Windows desktops, such as Windows 10 and Windows 11. During my testing on Windows servers, this permission was not present. Nonetheless, it was still possible for users without the “Manage Server” permission to add remote printers.
If a user adds a remote printer, the printer will inherit the security properties of the shared printer from the printer server. As such, if the remote printer server allows Everyone to manage the printer, then it’s possible to obtain a handle to the printer with the PRINTER_ACCESS_ADMINISTER access right, and SetPrinterDataEx would update the local registry as usual. A user could therefore create a shared printer on a different server or workstation, and grant Everyone the right to manage the printer. On the victim server, the user could then add the remote printer, which would now be manageable by Everyone. While I haven’t fully tested how this vulnerability behaves on remote printers, it could be a viable option for situations, where the user cannot create or mange a local printer. But please note that while some operations are handled by the local print provider, others are handled by the remote print provider.
When we have opened or created a printer with the PRINTER_ACCESS_ADMINISTER access right, we can configure the SpoolDirectory on it.
When calling SetPrinterDataEx, an RPC request will be sent to the local Print Spooler spoolsv.exe, which will route the request to the local print provider’s implementation in localspl.dll!SplSetPrinterDataEx. The control flow consists of the following events:
1. spoolsv.exe!SetPrinterDataEx routes to SplSetPrinterDataEx in the local print provider localspl.dll
2. localspl.dll!SplSetPrinterDataEx validates permissions before restoring SYSTEM context and modifying the registry via localspl.dll!SplRegSetValue
In the case of setting the SpoolDirectory value, localspl.dll!SplSetPrinterDataEx will verify that the provided directory is valid before updating the registry key. This check was not present before CVE-2020–1030.
localspl.dll!SplSetPrinterDataEx
Given a path to a directory, localspl.dll!IsValidSpoolDirectory will call localspl.dll!AdjustFileName to convert the path into a canonical path. For instance, the canonical path for C:\spooldir\ would be \\?\C:\spooldir\, and if C:\spooldir\ is a symbolic link to C:\Windows\System32\, the canonical path would be \\?\C:\Windows\System32\. Then, localspl.dll!IsValidSpoolDirectory will check if the current user is allowed to open or create the directory with GENERIC_WRITE access right. If the directory was successfully created or opened, the function will make a final check that the number of links to the directory is not greater than 1, as returned by GetFileInformationByHandle.
localspl.dll!IsValidSpoolDirectory
So in order to set the SpoolDirectory, the user must be able to create or open the directory with writable permissions. If the validation succeeds, the print provider will update the printer’s SpoolDirectory registry key. However, the spool directory will not be created by the Print Spooler until it has been reinitialized. This means that we will need to figure out how to restart the Spooler service (we will come back to this part), but it also means that the user only needs to be able to create the directory during the validation when setting the SpoolDirectory registry key — and not when the directory is actually created.
In order to bypass the validation, we can use reparse points (directory junctions in this case). Suppose we create a directory named C:\spooldir\, and we set the SpoolDirectory to C:\spooldir\printers\. The Spooler will check that the user can create the directory printers inside of C:\spooldir\. The validation passes, and the SpoolDirectory gets set to C:\spooldir\printers\. After we have configured the SpoolDirectory, we can convert C:\spooldir\ into a reparse point that points to C:\Windows\System32\. When the Spooler initializes, the directory C:\Windows\System32\printers\ will be created with writable permissions for everyone. If the directory already exists, the Spooler will not set writable permissions on the folder.
As such, we need to find an interesting place to create a directory. One such place is C:\Windows\System32\spool\drivers\x64\, also known as the printer driver directory (on other architectures, it’s not x64). The printer driver directory is particularly interesting, because if we call SetPrinterDataEx with the CopyFiles registry key, the Spooler will automatically load the DLL assigned in the Module value — if the Module file path is allowed.
This event is triggered when pszKeyName begins with the CopyFiles\ string. It initiates a sequence of functions leading to LoadLibrary.
localspl.dll!SplSetPrinterDataEx
The control flow consists of the following events:
1. spoolsv.exe!SetPrinterDataEx routes to SplSetPrinterDataEx in the local print provider localspl.dll
2. localspl.dll!SplSetPrinterDataEx validates permissions before restoring SYSTEM context and modifying the registry via localspl.dll!SplRegSetValue
3. localspl.dll!SplCopyFileEvent is called if pszKeyName argument begins with CopyFiles\ string
4. localspl.dll!SplCopyFileEvent reads the Module value from printer’s CopyFiles registry key and passes the string to localspl.dll!SplLoadLibraryTheCopyFileModule
5. localspl.dll!SplLoadLibraryTheCopyFileModule performs validation on the Module file path
6. If validation passes, localspl.dll!SplLoadLibraryTheCopyFileModule attempts to load the module with LoadLibrary
The validation steps consist of localspl.dll!MakeCanonicalPath and localspl.dll!IsModuleFilePathAllowed. The function localspl.dll!MakeCanonicalPath will take a path and convert it into a canonical path, as described earlier.
localspl.dll!MakeCanonicalPath
localspl.dll!IsModuleFilePathAllowed will validate that the canonical path either resides directly inside of C:\Windows\System32\ or within the printer driver directory. For instance, C:\Windows\System32\payload.dll would be allowed, whereas C:\Windows\System32\Tasks\payload.dll would not. Any path inside of the printer driver directory is allowed, e.g. C:\Windows\System32\spool\drivers\x64\my\path\to\payload.dll is allowed. If we are able to create a DLL in C:\Windows\System32\ or anywhere in the printer driver directory, we can load the DLL into the Spooler service.
localspl.dll!SplLoadLibraryTheCopyFileModule
Now, we know that we can use the SpoolDirectory to create an arbitrary directory with writable permissions for all users, and that we can load any DLL into the Spooler service that resides in either C:\Windows\System32\ or the printer driver directory. There is only one issue though. As mentioned earlier, the spool directory is created during the Spooler initialization. The spool directory is created when localspl.dll!SplCreateSpooler calls localspl.dll!BuildPrinterInfo. Before localspl.dll!BuildPrinterInfo allows Everybody the FILE_ADD_FILE permission, a final check is made to make sure that the directory path does not reside within the printer driver directory.
localspl.dll!BuildPrinterInfo
This means that a security check during the Spooler initialization verifies that the SpoolDirectory value does not point inside of the printer driver directory. If it does, the Spooler will not create the spool directory and simply fallback to the default spool directory. This security check was also implemented in the patch for CVE-2020-1030.
To summarize, in order to load the DLL with localspl.dll!SplLoadLibraryTheCopyFileModule, the DLL must reside inside of the printer driver directory or directly inside of C:\Windows\System32\. To create the writable directory during Spooler initialization, the directory must notreside inside of the printer driver directory. Both localspl.dll!SplLoadLibraryTheCopyFileModule and localspl.dll!BuildPrinterInfo check if the path points inside the printer driver directory. In the first case, we must make sure that the DLL path begins with C:\Windows\System32\spool\drivers\x64\, and in the second case, we must make sure that the directory path does not begin with C:\Windows\System32\spool\drivers\x64\.
During the both checks, the SpoolDirectory is converted to a canonical path, so even if we set the SpoolDirectory to C:\spooldir\printers\ and then convert C:\spooldir\ into a reparse point that points to C:\Windows\System32\spool\drivers\x64\, the canonical path will still become \\?\C:\Windows\System32\spool\drivers\x64\printers\. The check is done by stripping of the first four bytes of the canonical path, i.e. \\?\C:\Windows\System32\spool\drivers\x64\ printers\ becomes C:\Windows\System32\spool\drivers\x64\ printers\, and then checking if the path begins with the printer driver directory C:\Windows\System32\spool\drivers\x64\. And so, here comes the second bug to pass both checks.
If we set the spooler directory to a UNC path, such as \\localhost\C$\spooldir\printers\ (and C:\spooldir\ is a reparse point to C:\Windows\System32\spool\drivers\x64\), the canonical path will become \\?\UNC\localhost\C$\Windows\System32\spool\drivers\x64\printers\, and during comparison, the first four bytes are stripped, so UNC\localhost\C$\Windows\System32\spool\drivers\x64\printers\ is compared to C:\Windows\System32\spool\drivers\x64\ and will no longer match. When the Spooler initializes, the directory \\?\UNC\localhost\C$\Windows\System32\spool\drivers\x64\printers\ will be created with writable permissions. We can now write our DLL into C:\Windows\System32\spool\drivers\x64\printers\payload.dll. We can then trigger the localspl.dll!SplLoadLibraryTheCopyFileModule, but this time, we can just specify the path normally as C:\Windows\System32\spool\drivers\x64\printers\payload.dll.
We now have the primitives to create a writable directory inside of the printer driver directory and to load a DLL within the driver directory into the Spooler service. The only thing left is to restart the Spooler service such that the directory will be created. We could wait for the server to be restarted, but there is a technique to terminate the service and rely on the recovery to restart it. By default, the Spooler service will restart on the first two “crashes”, but not on subsequent failures.
To terminate the service, we can use localspl.dll!SplLoadLibraryTheCopyFileModule to load C:\Windows\System32\AppVTerminator.dll. When loaded into Spooler, the library calls TerminateProcess which subsequently kills the spoolsv.exe process. This event triggers the recovery mechanism in the Service Control Manager which in turn starts a new Spooler process. This technique was explained for CVE-2020-1030 by Victor Mata from Accenture.
Here’s a full exploit in action. The DLL used in this example will create a new local administrator named “admin”. The DLL can also be found in the exploit repository.
SpoolFool in action
The steps for the exploit are the following:
Create a temporary base directory that will be used for our spool directory, which we’ll later turn into a reparse point
Create a new local printer named “Microsoft XPS Document Writer v4”
Set the spool directory of our new printer to be our temporary base directory
Create a reparse point on our temporary base directory to point to the printer driver directory
Force the Spooler to restart to create the directory by loading AppVTerminator.dll into the Spooler
Write DLL into the new directory inside of the printer driver directory
Load the DLL into the Spooler
Remember that it is sufficient to create the driver directory only once in order to load as many DLLs as desired. There’s no need to trigger the exploit multiple times, doing so will most likely end up killing the Spooler service indefinitely until a reboot brings it back up. When the driver directory has been created, it is possible to keep writing and loading DLLs from the directory without restarting the Spooler service. The exploit that can be found at the end of this post will check if the driver directory already exists, and if so, the exploit will skip the creation of the directory and jump straight to writing and loading the DLL. The second run of the exploit can be seen below.
That’s it. Microsoft has officially released a patch. When I initially found out that there was a check during the actual creation of the directory as well, I started looking into other interesting places to create a directory. I found this post by Jonas L from Secret Club, where the Windows Error Reporting Service (WER) is abused to exploit an arbitrary directory creation primitive. However, the technique didn’t seem to work reliably on my Windows 10 machine. The SplLoadLibraryTheCopyFileModule is very reliable however, but assumes that the user can manage a printer, which is already the case for this vulnerability.
Patch Analysis
[Feb 08, 2022]
A quick check with Process Monitor reveals that the SpoolDirectory is no longer created when the Spooler initializes. If the directory does not exist, the Print Spooler falls back to the default spool directory.
To be continued…
Disclosure Timeline
Nov 12, 2021: Reported to Microsoft Security Response Center (MSRC)
Nov 15, 2021: Case opened and assigned
Nov 19, 2021: Review and reproduction
Nov 22, 2021: Microsoft starts developing a patch for the vulnerability
Jan 21, 2022: The patch is ready for release
Feb 08, 2022: Patch is silently released. No acknowledgement or information received from Microsoft
Feb 09, 2022: Microsoft gives acknowledgement to me and Institut For Cyber Risk for CVE-2022-21999
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.
