Adobe CQ Pentesting Guide – Part 1

This post deals with the step-by-step security testing guidelines for Adobe CQ installation.

Adobe CQ is Adobe's new Web Experience Management software portfolio which provides easy-to-use web apps for creating, managing and delivering online experiences to its users. It also supports integration with other Adobe products. CQ provides a unified suite of management tools which includes Web Content Management, Marketing Campaign Management, and Digital Asset Management applications.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

As I was working on a security testing of a project which was based on an Adobe CQ installation, I quickly made a Google dork for identifying CQ applications, ran this dork on Google, and was amazed to see the results. There were more than 100,000 results. And most of them were damn vulnerable. This can be seen in the image 1.1 below.

Image 1.1: Results of Google query (inurl:content/geometrixx)

When I searched for docs to help in testing the security of this app, almost no results popped up except the security checklist for admins. So, despite the popularity of this product, there was a lack of resources for its security testing guides. So I came up with this article which can be taken as a security checklist for Adobe CQ Instances.

If we talk about any CMS as compared to a normal web application, CMS are always complex when it comes to security, as admins are not even aware of all the configurations. In the same manner, Adobe CQ is quite a big CMS and damn complex too. This leads to good amount of security holes in an application, if it is not configured properly. So let's talk about scope of vulnerabilities in Adobe CQ. Well, most of the vulnerabilities in Adobe CQ are more of security misconfigurations, and not of the core. Adobe CQ is very secure in the core. However, if you come across one in a core, then go, grab a CVE-ID. So, our target keeps revolving around identifying any security misconfiguration left open.

So let's start off.

• Check for Default Passwords: Manufacturers of any equipment or application typically use a simple password, such as admin or password on all equipment they ship, in the expectation that users will change the password during configuration. However, due to unawareness of security, users generally forget this and leave the default passwords as they are. Most of the adobe CQ instances which we went through were vulnerable to this issue, where they already lost half the battle. So check for the default passwords. While we identified an author account to be left open in 90 percent of our findings, an admin account was using a default password in three instances. An anonymous account and other three are also very helpful (even if they give read-only access), because they can at least take you to backups, cloud instances, etc. Default passwords for Adobe CQ installs are:
  

  admin : admin
  

  author : author
  

  anonymous : anonymous
  

  replication-receiver : replication-receiver
  

  jdoe@geometrixx.info : jdoe
  

  aparker@geometrixx.info : aparker
  

• Check for default Login Screens: Test for the default login page of the application. Default login screen are one most potential entry points in the application. And this is obviously the best place to check whether the default usernames and passwords are being used or not. These links can be useful, as shown in image 1.2 and image 1.3:
  

• /system/console [Felix Web Console]
  
• /system/admin [CQSE; servlet engine]
  
• /system/sling/cqform/defaultlogin.html
  
• /crx/de/index.jsp OR /crx/ [CRX Web Console]
  
• /etc/packages.html
  
• /content/geometrixx
  
• /libs/cq/core/content/login.html
  
• /libs/cq/core/content/welcome.html

Image 1.2: Default path to the installed packages.

Image 1.3: Default link to Adobe CQ Instance Login page

To further reduce your work, here is one very useful utility in identifying the version of your CQ instance. Below is a Ruby-based script which find outs the version of the CQ instance from the Welcome Screen.

[ruby]

require "rubygems"

require "net/http"

require "uri"

if ARGV.length < 3

puts "cqversion.rb username password http://localhost:4502"

else

username = ARGV[0]

password = ARGV[1]

host = ARGV[2]

uri = URI.parse(host+"/libs/cq/core/content/welcome.html")

http = Net::HTTP.new(uri.host, uri.port)

request = Net::HTTP::Get.new(uri.request_uri)

request.basic_auth username, password

response = http.request(request)

if response.code == "200"

puts /Version [0-9.a-zA-Z ]*/.match(response.body)

else

puts "failed to get version number - http error code: ", response.code

end

end

Link Source: http://ruben42.wordpress.com/2013/10/07/ruby-script-to-determine-the-version-of-a-cqaem-instance/

• Check for anonymous access: The reason why we checked the above links was to find out if we can achieve some read-only access to resources. (and believe me, read-only is not that bad). Check for below mentioned paths:
  
  • /etc/packages (packages stored here)
    
  • /etc/replication (encrypted transport of user passwords.)
    
  • /apps (application resides here)
    

  For reaching these paths, you can get your hands dirty with Google dorks, or you can use spiders.

   

• Check for custom error pages: Put anything like http://example.com/no_valid_page. This must not redirect to the sling login screen. It must go to some custom error page. We have identified such issues very commonly. It can be something like the one shown in image 1.4.
  

  
  

  Image 1.4: Server Version Disclosure because of Missing Custom Error Handler
  

• Check for OSGI Configuration: You can find out whether the OSGI Configuration has been done or not. For this, make these two GET requests to the server:
  
  • http://yourwebsite/somepage?wcmmode=edit
    
  • http://yourwebsite/somepage?debug=layout
    

  If there is some change in the page, it means that the OSGI configuration is not implemented, which can be exploited by an attacker. More about OSGI: http://www.osgi.org.

• Check for WebDav: Metasploit contains an auxiliary module for this, named webdav_scanner. You can use this this module for testing that webdav is disabled or not. Options which need and do not need to be filled can be seen in the below image 1.5.
  

  
  Image 1.5: Options for webdav_scanner Metasploit module.

• Check for XSS: Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. This security vulnerability can be exploited by malicious web users to bypass access controls.

  CQ applies the principle of filtering all user-supplied content upon output. Either the XSS filter is on, or admin has not configured it. So test XSS as you generally test for in any web applications. You can also check for XSS config file (if left open). One such example of this config file can be seen in the image 1.6 below.

  /cq/libs/cq/xssprotection/config.xml

  

Image 1.6: Default access and path to config.xml file.

• Check for ClickJacking: ClickJacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. The attacker basically loads the site in an iframe, which is invisible, and puts some other things on the page which are visible. Then he would put some bait to the victim, so that he clicks on that particular object on the page and thus submits the request through the invisible frame.
  

  For checking ClickJacking, first intercept any request from the server and find out if the site is using any X-Frame header. If not, then make a simple html page at your local system with following piece of line:
  

  <iframe src="http://example.com">
  

  If the site loads within an iframe, this seems to be an issue. If it does not load, it means the site is not vulnerable to ClickJacking. If the site loads, it would look something like the image 1.7 shown below. Why I laid emphasis on testing in an iframe is because, apart from the X-frame header countermeasure, there is another technique called frame-busting, which can be used to protect the site from loading in an iframe.
  

  

Image 1.7: Proof of concept for ClickJacking vulnerability.

• Check Access to Cloud Service Information: When a CQ instance is integrated with an Adobe marketing cloud, cloud service configurations are used. This must not be publically accessible as their default permissions are "read" for everyone. If this is happening, you are lucky and try to gather as much information you can. You can get some idea from the image 1.8 below.
  

  

Image 1.8: Access to Cloud Service Information

• Check if Minify has been disabled or not: Minify is implemented in Adobe CQ for removing white characters and crlf characters (i.e. %0d and %0a).

  CRLF stands for Carriage Return and Line Feed, which if allowed will enable an attacker to perform HTTP Response Splitting, with which he can perform a set of malicious attacks, like poisoning of the client's Web cache, cookies, XSS, temporary or permanent defacement of web pages, and even information theft. An example of a CRLF attack may look like:

  http://www.yoursite.com/abcd.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3EXYZ%20MALICIOUS%20CONTENT%3C/html%3E
  

  When a victim opens this link, he will be presented with a page with XYZ MALICIOUS CONTENT. A typical CRLF post request would look like the one shown in image 1.9

  

Image 1.9: Typical request for CRLF attack.

• Check for CSRF: Adobe CQ, if left with default settings is vulnerable to CSRF, i.e. Cross Site Request Forgery. CSRF is an attack in which attacker forces an end user to execute malicious actions on a web application in which victim is currently authenticated. With a very small amount of social engineering, an attacker can fool the victim to click on a link which has a malicious form. This form is loaded automatically as the page opens, and submits some malicious POST requests on the victim's behalf (because he was already assigned a session). If the CSRF is successful, a whole account can be compromised by simply updating the email ID or any other user identity. In case the victim is admin, a whole app can be compromised instead.
  

  Now even if default settings are changed, CQ has only a Referer filter service for protecting users from CSRF. It will allow admin to filter:
  

  Which http methods should be filtered?
  

  Empty referrer header can be blocked.
  

  White list of servers can be made to be allowed.
  

  

  FREE role-guided training plans

  Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

  Download Now

  This means that even if the Referer-based filter is implemented, you should play around with passing a different Referer and check if this is properly implemented.
  

So we can conclude that Adobe CQ core is very stable and much vulnerability has not been identified within the core itself. However, most of the sites using this application are vulnerable to Security Misconfigurations, which are very often left open by admins. If you are testing any Adobe CQ application, make sure you go through this checklist at least once. Apart from this, Adobe CQ uses APIs, which are also vulnerable to attacks. We will discuss those attacks in Adobe CQ Pen-testing Guide – Part II.