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. 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. author : author anonymous : anonymous replication-receiver : replication-receiver jdoe@geometrixx.info : jdoe aparker@geometrixx.info : aparker
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 [/ruby] 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. Image 1.4: Server Version Disclosure because of Missing Custom Error Handler /cq/libs/cq/xssprotection/config.xml
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: