Building

m0n0wall as an IPv6 firewall

This is a guest post from Antonios Atlasis

Last October I had a quick look at pfSense 2.1 regarding the IPv6 support that it offers. It was the first stable support of pfSense that offered the capability for IPv6 network connectivity (a few comments about it can be found here). However, I knew that m0n0wall supported IPv6 quite a long time ago and that their developers had incorporated the support of IPv6 features which are not available in pfSense yet, so today I decided to have a look at it too.

Continue reading “m0n0wall as an IPv6 firewall”

Continue reading
Breaking

A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices

(Or How the Smallest Detail Can Make a Difference)

This is a guest post from Antonios Atlasis.

 

As it is well known to the IPv6 enthusiasts, one of the most significant changes that IPv6 brings with it, apart from supporting a really huge address space, is the improved support for Extensions and Options, which is achieved by the usage of IPv6 Extension headers. According to RFC 2460, “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.” So, by adding IPv6 Extension headers, according to the designers of the protocol, flexibility and efficiency in the IP layer is improved.

This can definitely be the case, but apart from it, it has already been shown that by abusing IPv6 Extension headers several security issues may arise (see for example my presentations at  Black Hat Abu Dhabi 2012 and at the IPv6 Security Summit @ Troopers 13). This is why Enno Rey by talking straight to the point at the latest IPv6 Security Summit @ Troopers 14 described the IPv6 Extension headers as a “mess”!

Continue reading “A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices”

Continue reading
Building

Microsoft Windows Update over IPv6 (or not?)

Hello everyone,

I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column. Continue reading “Microsoft Windows Update over IPv6 (or not?)”

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
Building

IPv6 Address Plan Considerations, Part 3: The Plan ;-)

This is the third – and hence presumably last – part of the series of posts on IPv6 address planning (first part can be found here, second one here). It’s split into three main pieces. In the beginning I will lay out some general objectives to be considered when designing an address plan. Then I’ll have a look at potential hierarchy levels and finally I’ll discuss some real-life samples we’ve seen recently.

Continue reading “IPv6 Address Plan Considerations, Part 3: The Plan ;-)”

Continue reading
Breaking

The Role of VGX.DLL in the Context of the Latest IE 0-Day

On Saturday, April 26 Microsoft announced that Internet Explorer version 6 until version 11 is under potential risk against drive-by attacks from malicious websites, regardless of the underlying Microsoft operating system and the associated memory protection features integrated with the operating system. Microsoft has assigned CVE-2014-1776 to this unknown use-after-free vulnerability, which in the worst case could allow remote code execution if a user views a specially crafted website. If an attacker successfully exploits this vulnerability, s/he will gain the same rights and privileges as the current user (once again, activated User Account Control [UAC] helps keeping privileges of the user low).

The recommended mitigating controls from Microsoft, especially unregistering the VGX.DLL library has led to the misunderstanding, that many people thought the vulnerability is located in the VGX.DLL library. That is wrong. Instead, the vulnerability is located in mshtml.dll, mshtml.tlb, Microsoft-windows-ie-htmlrendering.ptxml, and Wow64_microsoft-windows-ie-htmlrendering.ptxml and therefore unregistering of the above library does not globally mitigate the vulnerability. It only mitigates a specific attack vector where Vector Markup Language (VML) is being used during the attack. Continue reading “The Role of VGX.DLL in the Context of the Latest IE 0-Day”

Continue reading
Misc

ASCII Protocol Scheme Generator

As we historically have a strong connection to network technologies (not surprising, given the “NW” in “ERNW” stands for “Networks”), I developed a small script to create RFC-style ASCII representations of protocol schemes. The following listing shows an example created for a fictitious protocol:

 0                   1                   2                   3  
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|             type              |              id               |
+---------------------------------------------------------------+
|     flags     |                   reserved                    |
+---------------------------------------------------------------+
|                            payload                            |
+---------------------------------------------------------------+

 

The command line to create this output is

./ascii_header.py 16-type 16-id 8-flags 24-reserved 32-payload

and of course the script also provides a help message which explains the parameters in detail.

Download: https://www.ernw.de/download/ascii_protocol_scheme_generator.zip

Enjoy and feel free to leave feedback and comments,

Benedikt 🙂

Continue reading
Events

Hackito Ergo Sum 2014

Greetings from Heidelberg to Paris,

and thanks for a great time at HES14! A nice venue (a museum), sweet talks and stacks of spirit carried us through the three day con. It all set off with a keynote byTROOPERs veteran Edmond ‘bigezy’ Rogers, who stuck to a quite simple principle: “People do stupid things” and I guess every single one of you has quite a few examples for that on offer. Next to every speaker referenced that statement at some point during her/his talk. Furthermore we presented an updated version of our talk LTE vs. Darwin, covering our research of security in LTE networks and potential upcoming problems.

For those who missed HES2014, we prepared a short summary of some of the talks that inspired us.

Continue reading “Hackito Ergo Sum 2014”

Continue reading
Breaking

Bruting Android Pins

Hi there,

a few weeks ago I held a talk at UnFUCK, a small University con from students for students. I had decided to give a short talk on “Owning Stuff via USB” aka how to use our TR14 Badge! During the preparations and while building my demos, I tested my new USB RubberDucky. One rather “trivial” demo was actually to use it as a keyboard on an Android phone.

Continue reading “Bruting Android Pins”

Continue reading