Undocumented authentication bypass issue in AEM Package Manager [Blog updated]

Note: This blog post has been updated to include a response from Adobe for accuracy on July 9, 2021.

Updated with response from Adobe: 

We do not have any evidence of public exploitation in the wild that would justify the classification of this issue as a “0-day” vulnerability in Adobe Experience Manager (AEM). 

For clarification, this issue does not impact AEM Cloud Service customers and only potentially impacts AEM on-premise or AEM as a Managed Service if default security configurations are removed. 

As a result, this does not require a CVE from Adobe because AEM has the necessary security controls enabled by default to help protect customers. This out-of-the-box protection is available on supported versions of AEM. 

Adobe recommends AEM customers review access controls for the CRX package manager path: /etc/packages. 

Note: Detectify previously classified this vulnerability as a 0-day. After discussions with the Adobe PSIRT team, it is now classified as an “undocumented security issue” and the blog has been updated to clarify the specific circumstances under which this security issue may occur.

TL;DR Security researchers in the Detectify Crowdsource community, Ai Ho (@j3ssiejjj) and Bao Bui (@Jok3rDb), found an undocumented security issue in Adobe Experience Manager (AEM) that bypassed authentication, and left the application open to information disclosure attacks. If you are a Detectify customer vulnerable to this issue, it will show up as AEM CRX Bypass in your scan results.

Adobe Experience Manager (AEM) is a widely used content management solution for building digital customer experiences, like websites, mobile apps and forms. 

This bug allows attackers to bypass authentication and gain access to Package Manager if the security controls for out-of-box protection are manually removed. Packages enable the importing and exporting of repository content, and the Package Manager can be used for configuring, building, downloading, installing and deleting packages on local AEM installations. This issue allows an unauthorized user to view and download packages. 

Security researchers and Detectify Crowdsource members Ai Ho (@j3ssiejjj) and Bao Bui (@Jok3rDb), discovered the issue.

When a Crowdsource member reports a 0-day, Detectify’s research team works with vendors for responsible disclosure within 45-days of reporting. Learn more about how Detectify handles this process.

How the issue works

This bug occurs when default security controls are manually turned off on the Package Manager content tree, by default /etc/packages. 

The Package Manager is accessed by bypassing dispatcher filter rules. The component responsible for this issue used to be exploited before with one special character. This one uses a new approach by exploiting it with a lot of special characters combined. 

Normal request:

Mitigation

Adobe recommends to mitigate this information disclosure issue by setting strict permissions on Package Manager content tree, by default /etc/packages.

The researchers found that another effective way is to block public access to the CRX console (blocking all access to endpoints: /crx/*)

Report timeline for AEM CRX Bypass

12/09/2020 – Researchers send a report to an impacted organization.

03/15/2021 – Researchers report multi subdomains to another impacted organization.

03/22/2021 – Researchers report the 0-day to Detectify who validates it.

03/25/2021 – Detectify informs Adobe about the undocumented issue. The specific installations that were found to be vulnerable were quickly remediated by switching the default security controls back on.

05/06/2021 – The test module for this security issue goes live for all Detectify customers.

About the researchers

Ai Ho (@j3ssiejj) is a passionate security engineer, developer and Detectify Crowdsource member who enjoys automation. He has been into responsible disclosure and bug bounties for the past two years and now builds his own tools to do it. Check them out on GitHub. 

Bao Bui (@Jok3rDb) is a security researcher on the Detectify Crowdsource platform. He is a former CTF player of Meepwn CTF Team and got into bug bounty about a year ago.

How Detectify handles undocumented security issues

When a researcher shares an undocumented security issue with Detectify, including 0-days, the first step is to evaluate that it is valid. Once confirmed, Detectify contacts the affected vendor on behalf of the researcher so they are aware of the issue. 

The vendor then has 45 days to fix the issue before Detectify releases the security module that will be tested against customers’ web applications. If the vendor fixes the security vulnerability within these 45 days, Detectify releases the security test as soon as possible after the fix. Learn more about how Detectify handles this process.

Detectify customers will know if they’re vulnerable or not

You can follow the guidance provided by Adobe in this blog to verify your AEM installation. Get certainty whether you’re vulnerable to this issue, or any other known security issues used to exploit AEM by checking your web apps with Detectify.

Detectify customers know which vulnerabilities are confirmed as exploitable:

images: this screenshot of the Detectify GUI shows a web app is vulnerable to Routing-based authentication bypass

Detectify is a crowd-based web vulnerability scanner that goes beyond version and signature-testing. The testbed is payload-based and checks for actively exploited web vulnerabilities like Prototype Pollution, OWASP Top 10, undocumented vulns, CORS misconfigurations and more.

Curious to see what Detectify will find in your web apps? Sign up for a 2-week free trial today.

Into ethical hacking and want to join Crowdsource? Learn more on how you can earn recurring rewards while making the Internet safer with Detectify Crowdsource.