Events

New Methods for Exploiting ORM Injections in Java Applications (HITB16)

The HITBSecConf or “Hack In The Box” in Amsterdam is a well known security conference in Europe. We also attended this year too, and there were quite some interesting talks at the HITBSecConf16 conference. One of the talks was about “New Methods for Exploiting ORM Injections in Java Applications” by the security researchers Mikhail Egorov and Sergey Soldatov.

Continue reading “New Methods for Exploiting ORM Injections in Java Applications (HITB16)”

Continue reading
Breaking

Classic Web Vulns Found in Google Search Appliance 7.4

Google Search AppliancesHi all,

I’ve recently found some sort of classic web vulnerabilities in the Google Search Appliance (GSA) and as they are now fixed [0][1][2], I’d like to share them with you.

First of all, some infrastructure details about the GSA itself. The GSA is used by companies to apply the Google search algorithms to their internal documents without publishing them to cloud providers. To accomplish this task, the GSA provides multiple interfaces including a search interface, an administrative interface and multiple interfaces to index the organization’s data. Continue reading “Classic Web Vulns Found in Google Search Appliance 7.4”

Continue reading
Breaking

How to test Kerberos authenticated web applications?

First of all: This is not an in-depth Kerberos how-to, nor is this tutorial about the different aspects of web application testing. This tutorial is just to give support in testing Kerberos authenticated web applications. The goal is to hand over the right tools and steps to be able to perform the configuration and be able to test the application.

Continue reading “How to test Kerberos authenticated web applications?”

Continue reading
Events

Web Hacking Special Ops Workshop @ TR16

Trooper!

You passed Hacking 1on1 with flying colors?

You evade web application firewalls as they would be opened doors?

You have successfully exploitated CVE-2015-8769?

Then it’s time for the next challenge! Follow us down the rabbit hole to the not so well known attacks against modern web applications.
Continue reading “Web Hacking Special Ops Workshop @ TR16”

Continue reading
Breaking

XML External Entity (XXE) Injection in Apache Batik Library [CVE-2015-0250]

During one of our latest web application code review projects I came across a vulnerability for which I think it is worth to speak about. It is an injection based attack against XML parsers which uses a rarely required feature called external entity expansion. The XML specification allows XML documents to define entities which reference resources external to the document and parsers typically support this feature by default. If an application parses XML input from untrusted sources and the parsing routine is not properly configured this can be exploited by an attacker with a so called XML external entity (XXE) injection. A successful XXE injection attack could allow an attacker to access the file system, cause a DoS attack or inject script code (e.g. Javascript to perform an XSS attack).
Continue reading “XML External Entity (XXE) Injection in Apache Batik Library [CVE-2015-0250]”

Continue reading
Breaking

Django Image Validation Vulnerability

Hi!

In the course of a recent penetration test, we came across an Image validation vulnerability in Django when using the Python-Imaging-Library (PIL) which we want to explain in this post.

Everybody who doesn’t know what Django and/or the PIL is:
Django is a framework to create web applications with Python (comparable to Rails or Zend). The PIL is a powerful standard python library which provides a toolset to modify, display and verify images of many different formats.

Applications that support the upload of images and validate the file type of those images using the PIL contain an interesting attack vector. For this attack vector, the most interesting image formats are X Bitmap (xbm) and the similar X PixMap (xpm). These two types are text based image files, which contain code to create a monochrome (xbm) or 256 color (xpm) image. In a web server system, these files can be abused to put content (eg. Python/PHP/Code or HTML files) on the server, as long as they pass the image validation process.
This results in the following possible exploitation scenario:

Every system with a Django-Server and PHP-enabled webserver sharing the same document root folder is a possible target for the described, as long as the storage paths for uploaded content are known, accessible and the content and extension of the uploaded files remain untouched (e.g.: no conversion takes place). Those paths can often be guessed as there are several default options.

Uploading python code is also an option, but may only be exploitable in case it is possible to upload to the main folder of the django application (to add malicious functionality). This scenario also requires wide knowledge about the used application, since it is required to find a way to make the application call the code in the uploaded source-files. In addition to this, Django has a very strict policy that forces the administrator to manually add any application to the Django-Server configuration. Even if the upload of a new django app succeeds, it will not be executed by the server, because it is not added to the configuration file yet. For this example, we thus resorted to the scenario with a PHP-enabled server.
To illustrate this scenario, I’m using the django-avatar app on an Xubuntu machine. First of all, a minimal configuration of django-avatar and apache was set up, running in the same document root folder, enabling us to upload avatars for a specific user using the avatar application.
Notice the following default values of django-avatar that enable us to actually exploit this scenario:

HASH_FILENAMES = False
HASH_USERDIRNAMES = False
ALLOWED_FILE_EXTS = None

Hashing for filenames and userdirnames is disabled by default which makes it easy to determine the path where uploaded content is stored. But even if these options are enabled, it is still possible to access the file- and username directory by just using the corresponding MD5 hashes (no salt is applied).
The most important setting is ALLOWED_FILE_EXTS, which allows every PIL validated image to be uploaded when set to None. Setting this parameter to comma separated strings will lead to exclusively accepting the given extensions [e.g. (“jpg”, “gif”,) leads to only accepting “.jpg” and “.gif ”-files].

To start the exploitation and upload an actual image, we have to login and then browse to the /avatar/add sub-URL, showing the following website:

Simple Avatar Test Page

It is a simple upload page which allows setting avatars. The avatar is not being displayed, since it is not set yet.
We are now uploading a simple xbm file (script.php) with the following content:

#define test_width 1
#define test_height 1
#static unsigned char iamge_bits[] = {};
<script type=”text/javascript”>document.body.innerHTML = “”;</script>
<?php
echo PHP_VERSION;
?>

Lines starting with a # are comments in xbm definitions. The part after line 3 is the Javascript to empty the page and the PHP-payload, which we use to execute arbitrary PHP code on the server. The actual image is not defined, but PIL will still recognize this file as a valid image, since it contains all the relevant syntax for a valid xbm image and ends with a ;. What comes after line 3 is just ignored by the PIL parser, since it is irrelevant to the image. So the PIL will verify the image and will allow the app to save the image in the avatar directory, where an additional resized version of the image is being generated and saved. The original file will be stored in the directory without any changes to filename, extension and content (except for a hashed filename, if enabled).

After uploading the file, a new avatar is created for the user which appears on disk and in the django admin panel:

ava_admin

Given the apache server is running in the same directory, we now have our own php file on the server and can access all php functions. In our PoC we see the cleaned website with the additional PHP-Version information:

ava_folder_apache

This process can be further exploited, since django-avatar will not overwrite files (instead create a renamed version of the same file: test.jpg and test_1.jpg) and stores old avatars when operating in default settings. Instead of uploading a harmless script to display the server version it is possible to upload a full php webshell and then further exploit the underlying webserver.

The django developers explicitly warn (see “Where should this code live?”) administrators to not run a classic server system (e.g. Apache) in the same directory as the django-server, meaning the overall chance of exploitation is low. Additionally exploitation is only possible if files are stored with their original extension, since the PHP-server will interpret the files depending on their file extension.
Even though this is not a vulnerability in the Django framework (it actually is a kind of a specific scenario), we still need to put more attention to this possible design pitfall, when using powerful libraries like the PIL. We further recommend the following best practices when developing Django applications or any upload-enabled web applications:

•    Restrict (image-)file formats
•    Do not store the original file on the disk, but instead convert every file to a specific format and only store the converted files.
•    Delete unused data
•    Set default values as safe as possible (people are lazy and tend to leave things that run untouched)

With this said: Happy coding and until next time! 🙂

Niklaus & Benedikt

Continue reading
Breaking

Cross-Site Request Forgery with Cross-Origin Resource Sharing

During one of our last projects in a large environment we encountered an interesting flaw. Although it was not possible to exploit it in this particular context, it’s worth to be mentioned here. The finding was about Cross-Site Request Forgery, a quite well-known attack that forces a user to execute unintended actions within the authenticated context of a web application. With a little help of social engineering (like sending a link via email, chat, embedded code in documents, etc…) an attacker may force the user to execute actions of the attacker’s choice.
Continue reading “Cross-Site Request Forgery with Cross-Origin Resource Sharing”

Continue reading
Breaking

The Web Application Firewall Story continues

Some days ago another advisory related to a web application firewall (WAF) product was published. This time the product Airlock by Ergon was affected by a vulnerability that combines Encoding and NULL Byte attacks to circumvent the pattern based detection engine. We have described these attacks in detail in our newsletter “Web Application Firewall Security and The Swiss Army Knife for Web Application Firewalls” because they belong to a well known category of attacks against WAFs.

The product is commonly used in the swiss banking industry to ensure PCI DSS compliance and serves as another proof that WAFs can’t protect web applications from skilled attackers as already stated by me in an earlier post that you can find here. Beside these “5 myths of web application firewalls” we can also look at WAFs based on the typical attack vectors against web applications:

These attack vectors are described in detail in the famous “Web Application Hackers Handbook” and if you’re doing web application assessments they belong to the mandatory test methodology. Based on our WAF research we have compiled a little nice diagram that reflects the technical capabilities of WAFs to protect against these attack vectors:

As you can see especially authorization (user A can access data of user B) attacks and also logic flaws can not be addressed by WAFs because they can not be detected by pattern matching and even by whitelisting approaches. By the way when testing banking web applications one of the most relevant questions to answer is “can customer A see account information of customer B” :-). This raises the question “Why is the banking industry using WAFs to protect their customers data instead of fixing vulnerabilities in their applications or in general ensuring the quality?”. And again, finally we end up realizing that implementing a Security Development Lifecycle (SDL) would fulfill our “security needs” in a more effective way, but this time just from an attackers point of view.

Have a great day
Michael

Continue reading