August Vuln of the Month: CVE-2022-26138
Share with Your Network
Since ‘80s rewinds are all the rage these days (lookin’ at you, Kate Bush!), it seems only fitting that August’s Vuln of the Month offers a throwback to that timeless 1983 cyber classic War Games, in which the fate of the world rests on a backdoor password. So here we are, nearly 40 years later, and once more a backdoor is getting all the attention.
This month’s vuln, CVE-2022-26138, affects an Atlassian user support app for Confluence server. The Questions for Confluence app (ver. 2.7.x and 3.0.x) includes a hardcoded backdoor password that works with an automatically generated user account. An attacker need only log in via that account and enter the password. Once in, they have access to all the content within that company’s instance of the app—which could offer an opportunity to view internal issues, export data, and conjure up ways to further do damage. Making this especially risky is that the password has been publicized on Twitter—ostensibly as a slap at Atlassian for having a hardwired backdoor password in the first place. So, it wasn’t long before this vuln was exploited in the wild.
Our research shows that CVE-2022-26138 meets many of the criteria we look for in a vulnerability that could be exploited, including:
- Access complexity: Low
- Potential attack surface: Broad
- Exploitable remotely: Yes
- Authentication/privilege requirements: None
- Potential impact on availability: Partial
- Exploit code published: Yes
- Active exploits observed: Yes
For affected organizations, CVE-2022-26138 is an extraordinarily high-risk vuln. Its Kenna Risk Score is 100, the highest possible risk score a CVE can earn. Of all the CVEs scored to date by Kenna, just 0.21% have earned a score this high. At the time of this writing, CVSS was still analyzing this CVE. We expect it will receive relatively high CVSS scores once that analysis is complete.
Why CVE-2022-30190 matters
More than 8,000 organizations have the Questions for Confluence app installed. Upon installation, the app creates a Confluence user account named disabledsystemuser, which admins can use to move data between the app and the Confluence Cloud service. When users log into this account via the hardcoded password, they can view and edit all non-restricted pages within Confluence.
Atlassian has been clear about the potential risk: “A remote, unauthenticated attacker with knowledge of the hardcoded password could exploit this to log into Confluence and access any pages the confluence-users group has access to. It is important to remediate this vulnerability on affected systems immediately.”
Bottom line
Confluence users must address this ASAP, because exploiting this vuln is simply too easy for bad actors aiming to act badly. This hardwired password gives them a golden ticket (another throwback reference!) to knock around a Confluence instance and potentially grab data, intel and more. And since the password has already been tweeted, virtually everyone is playing catch-up.
Mitigation status
Mitigation may not be as straightforward as you might think. Even when Confluence installations don’t actively have the app installed, they may still be vulnerable. And those thinking they should just uninstall the app to remediate the vuln may want to think again: the disabledsystemuser account can still reside on the system, even if the app itself does not.
Instead, Atlassian advises administrators to determine if they’re vulnerable by searching for accounts that meet the following criteria:
- User: disabledsystemuser
- Username: disabledsystemuser
- Email: dontdeletethisuser@email.com
In response to this vulnerability, Cisco Talos released Snort rules 60280 and 60281 to detect any exploitation attempts. This is not the first Confluence vulnerability Talos has alerted users to recently. In June, Talos discovered a proof of concept for a zero-day vulnerability in the Confluence Data Center and Server, identified as CVE-2022-26134. In that case, attackers used the vulnerability to deliver the BEHINDER implant and China Chopper webshell.
Atlassian’s recommended fix is to either update to a safe version or to disable or remove the disabledsystemuser account. The company has published a couple resources to help out: First, there’s a FAQ for CVE-2022-26138. Second, Atlassian also published an article that instructs administrators on how to determine the most recent login for each user–a key step in figuring out whether an exploit may have occurred or been attempted. Atlassian recommends checking the last authentication time for disabledsystemuser. A null result suggests the account exists on the system, but no one has yet signed in using it. The commands also show any recent login attempts that were successful or unsuccessful. With luck, you’ll be able remove or disable that user account before someone else gets to it first.
And then you can get back to watching War Games, which features one of my all-time favorite movie lines: “I wouldn’t trust this overgrown pile of microchips any further than I can throw it.” I hear ya, friend. I hear ya.
Watch this space for regular Vuln of the Month spotlights, which appear on the second Tuesday of each month. Meanwhile, if you find yourself chasing new and emerging vulns but never quite catching up, learn more about how Kenna Security can help you focus on your highest-risk vulnerabilities, rather than headlines, thanks in part to our vulnerability intelligence powered by machine learning.
