Expand my Community achievements bar.

Help required to avoid the bypassing of access control restrictions

Avatar

Level 1

Hi team!

During the recent bug bounty, We identified that hackers can bypass the AEM dispatcher rules and can access the jcr:node data and other sensitive information.
Below are the few patterns/urls bypassing the authentication and lead to access the sensitive data

https://www-qa1.salesforce.com/etc.clientlibs/dam/clientlibs/assetinsights/pagetracker.js/.%7D./.%7D...
http://answers.salesforce.com/etc.clientlibs/dam/clientlibs/assetinsights/pagetracker.js/.%7D./.%7D....

http://answers.salesforce.com/etc.clientlibs/dam/clientlibs/assetinsights/pagetracker.js//.%7D./.%7D...
http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js/jcr:content/%5b.%5b./%5B.%5b./%5b... (fixed in prod. Added just for reference)

We added a few rules at dispatcher rules to disallow these kinds of path traversals as below.

RewriteCond %{REQUEST_URI} ^(.*)\/[.%5B](?i).*
RewriteRule .+ "-" [R=404,L]'


RewriteCond %{REQUEST_URI} ^(.*)\/[.%7D](?i).*
RewriteRule .+ "-" [R=404,L]'


Query/Help required: Please let me know any other known patterns which bypass the dispatcher rules and cause the serious/dangerous path traversal and data leakage. We will handle them at dispatcher level.

Question: How do %7D, %5B bypass the dispatcher rules and cause the data leakage? Please help us to understand the internal logic behind these unicodes chars.
1 Reply

Avatar

Employee

That really depends on your filter set. 
Essentially they are using encoded characters to manipulate the request:
- %5B is an encoded [
- %7D is an encoded }
If you look in your dispatcher.log you'll see which filter rule allows that request through.  See what it allows and then you can start to understand why it allows it
You can block these kinds of requests by not allowing suffixes on request that don't need them at all.  For example here is a filter rule that will allow that type of request but not allow the encoded characters suffixes:
Request: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js
```
/03000 {
  /type "allow"
  /method "GET"
  /path "/etc/segmentation/*"
  /url "/etc/segmentation/*.js*"
  /extension "js"
  /selectors "segment"
  /suffix ""
}
```
This rule will allow the request through but because the suffix matcher is blank they can't smuggle stuff at the end of the request and have it work.

 

If you look at the original request and use something like cyberchef to decode it you'll see the pivot attack
original: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js/jcr:content/%5b.%5b./%5B.%5b./%5b...
decoded: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js/jcr:content/[.[./[.[./[.[./[.[./c...
because the encoded brackets are ignore it consolidates to:

and as you might know /../ is a traversal to go up a directory.  It's trying to go to:
 
I hope that makes sense but essentially use as many matches (i.e. /method, /suffix,/extension, /url, /path, /selectors) as possible in your dispatcher allow rules.  if you add a matcher with a blank value that means it won't allow the extras to exist and block the request.  General rule of thumb is be as specific as you possibly can.
page footer