CVE-2022-26134 - Critical severity unauthenticated remote code execution vulnerability
Asked by Oliver Lam:

Hi there,

I would like to know if there are any other mitigations to prevent exploitation if we cannot disable our instances?

Thank you,

Oliver


Answers:
author: David Grizzell
body: Based on the current information, it appears this is limited to on premise versions of Confluence only (server and data center).


author: Robert Tang
body: To monitor the confluence security advisory page for this CVE specifically other than manually checking the page regularly, you can enable alert as per Atlassian suggestion.  

*If you did not receive an email for this advisory and wish to receive such emails in the future, please go to <https://my.atlassian.com/email> and subscribe to Alerts emails.*


author: Pedro Felgueiras
body: Also 7.13.7 is available to download but not listed on the site

<https://product-downloads.atlassian.com/software/confluence/downloads/atlassian-confluence-7.13.7-x64.bin>


author: Robert Tang
body: FYI, we've moved Confluence behind our VPN as a temp workaround. This may or may not be an option for you.


author: David Grizzell
body: This is a pretty serious vulnerability with no advanced warning, mitigation, or fix version. Some additional guidance or details on the exploit would be helpful.


author: Frank Hess
body: Mitigations are added to <https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html>


author: agenttank
body: if anyone is interested, I created a modsecurity rule for this:

SecRule REQUEST_URI\|REQUEST_BODY\|REQUEST_URI\|ARGS "@rx \\$\\{" "phase:2,id:5003000,log,t:none,deny,msg:'CVE-2022-26134 mitigation'"

creates problems with synchrony though and who knows what else, so we blocked external access to confluence - maybe it would be enough to only look at REQUEST_URI?

a WAF rule only "may reduce your risk" according to atlassian.

Apache Code-Block for the \<virtualhost\> of Confluence:

\<VirtualHost\>  
...  
\<Location /\>

Require ip 192.168.0.0/16 10.0.0.0/8 172.16.0.0/12 127.0.0.1  
\</Location\>  
...  
\</VirtualHost\>


author: David Grizzell
body: [@Robert Tang](/t5/user/viewprofilepage/user-id/4956907) that's the best course of action. We are an Atlassian Partner and have worked with our clients to do the same over the last few hours if they have a Confluence instance exposed to the internet. The best we can do right now.


author: SC
body: We're also behind a firewall, but are the 3rd party plugins installed managed by the UPM vulnerable and would that potentially cause another layer of vulnerability to examine?


author: Mathy
body: For nginx, this will filter in the path component of the URL, probably put it in your server block.

```
location ~ "\$\{" {
    deny all;
    return 404;
}
```

This will filter in the parameters component of the URL, **pay attention though**, it needs to be placed inside your main / location block where you do the proxy_pass redirect.

```

if ( $args ~ "\$\{" ) { return 404; }
?
```

That should filter all requests, but as [@agenttank](/t5/user/viewprofilepage/user-id/4200936) mentioned below, he noticed issues with synchrony (I didn't get reports of issues yet).


author: Andr? K_
body: or how to block URL's with "${" with NGINX


author: Robert Tang
body: Apart from turning it off, move confluence to be only accessible behind VPN if that's possible.  

Other compensating controls could be asking your SOC to do additional security monitoring on the confluence server to look for suspicious activities.   

If you have a WAF (e.g. CloudFlare), managed rules through heuristics might be able to detect potential attacks. Although unconfirmed.

Last might be geo IP blocking to block access from high risk countries if possible. Although not the most effective.


author: Mike Clarke
body: Hi,  

What's the best way to track progress on this vulnerability?  
All I can see from Atlassian is a one-off statement that can't be Watched or commented on  

<https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html>


author: Matthew Ciantar
body: Hi Chris,

Thanks for your response. Is there a simple PoC to confirm we are vulnerable? The ones I tested (from Rapid7 blog) return a 403.

Thanks,

Matthew.


author: Christian Reichert (resolution)
body: Hi Matthew,

yes, you are. SSO/SAML within confluence is not suitable mitigation.

You can reduce your risk when you use pre-authentication on something like a Loadbalancer/ALB - but that only means the reduction and "unauthenticated" to an "authenticated" attack.  

Best solution is to follow the mitigation/fix steps in the Security advisory.

Cheers,  
Chris

P.S. Full disclosure, I work for [resolution, a marketplace vendor.](https://marketplace.atlassian.com/vendors/1210947/resolution-reichert-network-solutions-gmbh)


author: Matthew Ciantar
body: Hi,

If we are using SSO/SAML, are we still vulnerable to this?

Thanks,

Matthew.


author: Richard Jones
body: it will just be our users.


author: Dylan Syme
body: none at all.


author: Dylan Syme
body: depends who has access to the vpn


author: Dylan Syme
body: is there any good reason /confluence/noop.jsp should be externally accessible?

certainly not a catch-all as they could put it where they like, but attackers seem to dumping webshell there. blocking that URL could at least stop some automated exploits.


author: Richard Jones
body: Is it safe to say that we're covered from this vulnerability as long as we're accessing Confluence via VPN?


author: Frank Alvarado
body: For my understanding, the vulnerability description states that this is an unauthenticated attack. What impact, if any, would disabling anonymous access to confluence have on this vulnerability? would it preclude an attacker from being able to exploit this vulnerability?


author: Matt Baillargeon
body: Just followed the mitigation/workaround steps for the jar files and everything works fine. Just saw Atlassian published an official update that addresses this vulnerability. Going to be a fun night of patching :(


author: Matt Baillargeon
body: Was just about to post this. Curious if anyone has completed these steps yet. We are about to follow these steps during business hours.


author: Alyson Whitaker
body: Question: What if Confluence is behind an SSO like Okta? Early testing, we are finding any calls are getting a 302 redirect - so essentially being blocked by SSO auth.


Tags: confluence-data-center

confluence-server

cve-2022-26134

security

server