Recently I had the pleasure to join the PowerOfCommunity conference in Seoul. Florian and Felix attended the conference in the past and enjoyed it a lot, so I took the opportunity to join this year. From what I had heard the conference is highly technical, offensive security and community focused (surprise 😉 ). Boy did they deliver!
Located in a hotel next to a nice park and close to the famous Gangnam district in Seoul we came together to feel the power of community. The conference was planned for two days and offered two tracks per day. Several key talks were presented for everyone. Continue reading “PoC Con Seoul 2016”
Past month we (which is me and a group of other ERNW students, supported by some of the “old” guys — I hope my team lead won’t yell at me for this 😉 ) attended the Haxpo and Hack in the Box in Amsterdam. Starting from 28. May, we had three days at this great conference (HITB) and exposition (Haxpo). The two events took place in the former building of the stock exchange in Amsterdam, called: “Beurs van Berlage”. Upon entering the building for the first time we were given details on where our booth was and where the talks would take place — setting up our booth and planning the shifts was just another thing to do before exploring the Haxpo area:
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:
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:
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:
After uploading the file, a new avatar is created for the user which appears on disk and in the django admin panel:
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:
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! 🙂
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: