Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Restricting Adobe CQ Admin Logins with Trustwave WAFs

One of the many useful features of a web application firewall (WAF) is its ability to add on addition security checks or logic to third party web applications. One common request that my team often receives from WAF customers is that they want to restrict down access to certain portions of their web applications to specified IP addresses or ranges. Oftentimes this type of functionality is not available natively within the application and fortunately it can be added in using a WAF.

Adobe CQ Admin Login - ModSecurity Example

image from www.boylesoftware.comOne such example is for the Adobe Experience Manager (CQ) application. How can an Adobe CQ admin restrict down who is allowed to log into the portal interface as the "admin" user? Well, it just so happens that Adobe's Help portal addressed this very issue here where they showed how this can be achieved using Trustwave's open source ModSecurity WAF!

Screen shot 2013-04-11 at 3.16.32 PM

When a client logs into the Adobe CQ app, this is what the raw HTTP request looks like:

POST /libs/cq/core/content/login.html/j_security_check HTTP/1.1
Host: some_website.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://some_website.com.com/libs/cq/core/content/login.html/j_security_check
Cookie: JSESSIONID=589506ae-50a6-4133-b8db-4af0453f5846
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 83


The example rules shown on the Adobe help website are the following:

<LocationMatch /libs/cq/core/content/login.html/j_security_check>
SecRule REMOTE_ADDR "!@ipMatch" "id:'23000',chain,deny,log"
SecRule ARGS:j_username "admin" "t:lowercase"

These rule will be activated for the /libs/cq/core/content/login.html/j_security_check URL. If the the client IP address is NOT and they are submitting the "admin" username, it will block them. This ruleset works like a charm and will help you to protect your Adobe CQ admin logins from access attempts by untrusted parties.

Adobe CQ Admin Login - WebDefend Example

In addition to our open source WAF ModSecurity, Trustwave also has our award winning, commercial WAF appliance called WebDefend. What I would like to do now is to show how the exact same custom protections can be implemented with WebDefend using our new "User Defined Rules" capabilities.

Adding New Custom Rules

Step 1: Open User Defined Rules Editor in the WebDefend Console

Screen shot 2013-04-11 at 1.53.44 PM

Step 2: Click Add to Define the New Rule Meta-data

Screen shot 2013-04-11 at 1.55.33 PM

Step 3: Create Custom Rule

Screen shot 2013-04-11 at 1.58.10 PM

It is important to note, as we often get questions along these lines, that WebDefend does not currently share any actual code base with ModSecurity. They are two completely separate applications. What we opted to do in this case, however, is to leverage the very popular ModSecurity Rules Language syntax for creating custom rules. For those of you who have been using ModSecurity and have many custom rules, this may come as good news for you as it would ease a transition into using WebDefend in your environment. As you can see from the screenshot above, the SecRules look very similar to the native ModSecurity rules shown from the Adobe site and they function the same. It will deny access to anyone logging into the "admin" account if they are not coming from

Step 4: Activating the Policy Settings

Screen shot 2013-04-11 at 1.58.40 PM

This screen lets you chose how to respond if this custom rule matches. As you can see there are a variety of options. In this example, I am chosing to log only.

Step 5: Save the new Rule Config

Screen shot 2013-04-11 at 1.59.54 PM

On this screen, we see our final custom rule. We then click on the "Save Rules" button to add this to our polices and active it within the sites.

Step 6: Review New Custom Rule in Active Policy

Screen shot 2013-04-11 at 2.02.04 PM

This screenshot shows our new rule activated rule in the policy with all of the information we added in the custom rule editor.

Step 7: Review Alert Details

If any unauthorized client does attempt to log into the "admin" account, then alerts similar to the one below would be generated.

Screen shot 2013-04-11 at 2.24.01 PM

The Analysis tab shows you all of the various events that triggered including our custom rule. If you want to see the actual request made, you can fiew the Request tab data as shown below:

Screen shot 2013-04-11 at 2.24.46 PM

As you can see, the two main request components defines in our custom rule (URL + Param value) are highlighted and this event was triggered because the client IP address was not authorized.


Hopefully this blog post has helped to show you how you can use WAFs to help implement custom protections for commercial 3rd party applications.