ASP.NET HttpHandlers are interesting components of a .NET web application when performing security assessments, mainly due to the fact they are the most exposed part of the application processing client requests in HttpContext level and at the same time, not yet part of the official ASP.NET framework.

As a result, data validation vulnerabilities in custom HttpHandlers can be exploited far easier than issues on the inner layer components. However, they are mostly overlooked during the web application tests for two reasons:

1. They are used by a 3rd party component of a target application and often the auditor wants to focus on the main functions of the application


2. They often are found performing such operations as displaying an icon file or chart from image cache. This is deemed useless during an assessment.

In this post, I'm going to demonstrate a data validation vulnerability in a custom HttpHandler which is used by a number of well known ASP.NET apps such as DotNetNuke CMS and was not fixed by the vendor until 2012/3. We still come across web applications that use this vulnerable component, so thought it useful that we document this vulnerability in the Telerik ASP.NET UI Control, which could allow a remote user to download and remove files from the web server under application's pool permission.

If you are using any of the Telerik components in your application, make sure to replace the "Telerik.Web.UI.dll" with the latest version (about 9MB!).

Vulnerability details:

The Telerik UI control has a web-based charts feature, which stores rendered graphic files in a cache folder for performance reasons. It registers a custom HttpHandler in the web.config file, which processes the following GET request and displays the chart in the client browser:

http://site/ChartImage.axd?useSession=false&imageFormat=image/png&ImageName=[base64 encoded value]

The next step is to decompile the code of the ChartHttpHandler.ProcessRequest(HttpContext), which gives us:

Although, the ImageName query string parameter is encrypted using an AES algorithm to prevent tampering, the encryption key and initialization vector are embedded in the application's assembly (Telerik.Web.UI.dll) and can be used to construct malicious requests to download files from the remote server, as shown in the following figure:

All versions up to and including 2011.2.915.35 are vulnerable. I've created a proof of concept that can be downloaded here . Please note that the target file will be deleted from the web server by the chart image handler after being downloaded from the server, as it considers the requested file as an expired cache entry.

Next time you are on an assessment, don't overlook the mundane and not-so-interesting parts of the application, as they can often provide you with an additional attack surface area.

Brilliant, the client has decided to implement their own CMS and you've found a variable that's vulnerable to SQL injection. Starting up your favourite SQL exploitation tool, you upload a suitable web shell and fire up the browser. In an instant, you control that server, but do you really own the box?

Looking back at the major hacks of the last 18 months, attackers used a variety of techniques to obtain sensitive information. For the RSA hack, social engineering was used, allegedly consisting of a malicious Excel spreadsheet sent from a web master at a recruitment website. Once loaded, Poison Ivy was dropped on the host and the games began. Attackers started recon exercises, pivoting between hosts and finally exfiltrated the data (the rest is well-known and publicised). In the case of HBGary, attackers compromised their systems using a similar approach as the RSA attackers did: target an individual using social engineering using an earlier toehold to expand to a foothold. These types of attackers might have a fancy new name (Advanced Persistent Threats) but at the end of the day, they are using techniques that have been around for a while.

Owning a single host isn't the end of the journey, it's just the start.

At this year's 44Con, students will have the chance to learn how to take their offensive skills to the next level. Think of it as APT-style assessments.

Hacking By Numbers - BlackOps Edition will teach the next stage of the attack: lateral movement within a network, pivoting, and going after business relevant systems and data. Often, the juicier targets are buried deep inside the network, requiring complex tunnelling, evasion so as to not trigger alerts and finally, when you've accessed a target, ways to exfiltrate the data (spreadsheets via Facebook direct message, scp over a DNS tunnel, this can be fun).

The course looks at key areas of post-exploitation, and covers:

• Working with big data on assessments
• The difference between exploiting and owning a system
• OSINT
• Effective ways to tunnel, pivot and exfiltrate data without being noticed
• Owning systems using client-side attacks and social engineering
• Privilege escalation

At the end of the course, students will participate in a final exercise set in a semi-real world environment, where they will need to used what they've learned compromise a target organisation, escalate privileges and tunnel sensitive data out from the network.

This course is aimed at making you think differently. It's offensive security at its best. To join this course, visit our booking page.

While I was evaluating a research idea about a SCADA network router during the past week, I used available tools and resources on the Internet to unpack the device firmware and search for interesting components. During security assessments, you may find interesting embedded devices available on the network. Whilst many don't look at the feasibility of doing firmware analysis, I decided to document the steps I took to analysis my target firmware, so you can take the similar approach in the case of assessing such devices. This could also be a good indication on the feasibility of automating this process (An unfinished project was launched in 2007: http://www.uberwall.org/bin/project/display/85/UWfirmforce).

The following process would be easy for most of you who use *nix systems on a daily bases:

Step 1) Scanning the firmware image

The BinWalk tool is useful for scanning firmware image files to identify embedded file systems and compressed streams inside. It can detect common bootloaders, file systems and compressed archives inside a given firmware image file. Since it works by scanning for signature and magic values, it usually has false positives and the results need to be verified manually.

U-Boot bootloader (yes, it's German :-)) signature was identified at offset 262144 and the uImage header information, such as creation date, CPU type, etc appears to be valid. This bootloader was followed by a gzip compressed stream, which probably is the zImage kernel and a squashfs file system at offset 1522004. We will attempt to extract this file system in the next step. The following are common bootloaders that are used in embedded devices with ARM CPU:

Blob bootloader Bootldr Redboot U-Boot ABLE bootloader

The bootloader's task is to load the kernel image at the correct address and pass initial parameters to it. So in most cases we are not interested in analysing the bootloader itself, but in the root file system.

Step 2) Extracting file systems

First, I extracted the uImage content at offset 262144 by using dd command and then used uboot-mkimage (packages.debian.org/uboot-mkimage) to test if it's a valid uImage file and to discover more information about it:

The image format was valid and it contained two other file system images with 1MB and 2MB sizes, which probably are kernel zImage and root file systems (RAMdisk). If you check the uImage file format, you will notice a 64 bytes long header. There is a “multi-file” image list that contains each image size in bytes and this list is terminated by a 32bit zero. So, I would need to skip 64+2*4+4=76 bytes from start of the uImage file to get to the first Image content that would be kernel zImage:

The file command could not detect kernel image or squshfs in the extracted file systems; this might be due to lack of squashfs (with LZMA compression) in my Ubuntu kernel. I proceed by using Firmware Mod Kit which contains a set of programs to decompress various file system images including squashfs-LZMA. After trying the various unsquashfs version 3.x scripts, I was able extract the rootfs image files successfully:

Step 3) Searching the root file system

Once the root file system files were extracted, we can file and strings search tools to look for interesting files and patterns such as RSA private key files, password and configuration files, SQL database files, SQL query string and etc. In my case, I was looking for RSA certificate or private key files and found the following: (a database of private keys in embedded devices was published in 2011 but it's not actively maintained, you can access it at http://code.google.com/p/littleblackbox/)

One can write shell scripts to automate the file system search process.

Step 4) Running and debugging the Executables

The Qemu emulator supports multiple CPU architectures including ARM, MIPS, PowerPC, etc and can be used to run and debug the interesting executable extracted from the firmware image on your system for dynamic analysis purposes. You would need to build the Qemu with —static and —enable-debug options. The following figure demonstrates how to run the web server (httpd) that was extracted from my target firmware using chroot and Qemu:

As you can see from the above screenshot, the web server was working fine, but was not able to display the bootloader version, because it couldn't read this value from the NVRAM (not volatile RAM) normally mounted by the kernel in a real device (there is an interesting post here about resolving the NVRAM access errors while emulating embedded device executables). Some of the executables, like the remote management agent example below, could have more severe problems running under emulator.

For troubleshooting such cases, or monitoring an emulated process while fuzzing it, we would need to attach a debugger to it. This can be achieved by using —g switch in Qemu and using a debugger out of the emulator process or even on a remote windows machine. I used IDA pro remote GDB debugging tool as shown in the figures below:

Once successfully attached to the remote emulated process, IDA pro can be used to simply trace the execution of the process, placing breakpoints or running IDA scripts.

Often overlooked during assessments, firmware analysis of devices can yield results and often do when we target them at SensePost. Our methodology includes the above steps and we recommend yours does too.

By the year 2015 sub-Saharan Africa will have more people with mobile network access than with access to electricity at home.

This remarkable fact from a 2011 MobileMonday report [1] came to mind again as I read an article just yesterday about the introduction of Mobile Money in the UK: By the start of next year, every bank customer in the country may have the ability to transfer cash between bank accounts, using an app on their mobile phone. [2]

I originally came across the MobileMonday report while researching the question of mobility and security in Africa for a conference I was asked to present at [3]. In this presentation I examine the global growth and impact of the so-called mobile revolution and then its relevance to Africa, before looking at some of the potential security implications this revolution will have.

The bit about the mobile revolution is easy: According to the Economist there will be 10 billion mobile devices connected to the Internet by 2020, and the number of mobile devices will surpass the number of PCs and laptops by this year already. The mobile-only Internet population will grow 56-fold from 14 million at the end of 2010 to 788 million by the end of 2015. Consumerization - the trend for new information technology to emerge first in the consumer market and then spread into business organizations, resulting in the convergence of the IT and consumer electronics industries - implies that the end-user is defining the roadmap for these technologies as manufacturers, networks and businesses scramble desperately to absorb their impact.

Africa, languishing behind in so many other respects, is right there on the rushing face of this new wave, as my initial quote illustrates. In fact the kind of mobile payment technology referred to in the BBC article is already quite prevalent in our home markets in Africa and we're frequently engaged to test mobile application security in various forms. In my presentation for example, I make reference to m-Pesa - the mobile payments system launched in Kenya and now mimicked in South Africa also. Six million people in Kenya use m-Pesa, and more than 5% of that country's annual GDP is moved to and fro directly from mobile to mobile. There are nearly five times the number of m-Pesa outlets than the total number of PostBank branches, post offices, bank branches, and automated teller machines (ATMs) in the country combined.

Closer to home in South Africa, it is estimated that the number of people with mobile phones outstrips the number of people with fixed-line Internet connections by a factor of ten! And this impacts our clients and their businesses directly: Approximately 44% of urban cellphone users in South Africa now make use of mobile banking services. The reasoning is clear: Where fixed infrastructure is poor mobile will dominate, and where the mobile dominates mobile services will soon follow. Mobile banking, mobile wallets, mobile TV and mobile social networking and mobile strong-authentication systems are all already prevalent here in South Africa and are already bringing with them the expected new array of security challenges. Understanding this is one of the reasons our customers come to us.

In my presentation I describe the Mobile Threat Model as having three key facets:

• Security: The challenge of ensuring Confidentiality, Integrity and Authenticity for the data and transactions on the device;
• Privacy: The implications of mobility (and especially convergence) for citizens and their rights to talk, move, think and act unobserved; and
• Control: The challenge presented by the mobile revolution to governments fighting crime, gangsterism and terrorism.

All of these issues are real and complex, but I'm restricting myself to the security question here. I encourage readers to peruse the presentation itself for a full breakdown of the Threat Model because for this article I think it suffices to consider just the conclusion of my presentation, and it's this:

The technical security issues we discover on mobile devices and mobile applications today are really no different from what we've been finding in other environments for years. There are some interesting new variations and interesting new attack vectors, but it's really just a new flavor of the same thing. But there are four attributes of the modern mobile landscape that combine to present us with an entirely new challenge:

Firstly, mobiles are highly connected. The mobile phone is permanently on some IP network and by extension permanently on the Internet. However, it's also connected via GSM and CDMA; it's connected with your PC via USB, your Bluetooth headset and your GPS, and soon it will be connected with other devices in your vicinity via NFC. Never before in our history have communications been so converged, and all via the wallet-sized device in your pocket right now!

Secondly, the mobile device is deeply integrated. On or through this platform is everything anyone would ever want to know about you: Your location, your phone calls, your messages, your personal data, your photos, your location, your location history and your entire social network. Indeed, in an increasing number of technical paradigms, your mobile device is you! Moreover, the device has the ability to collect, store and transmit everything you say, see and hear, and everywhere you go!

Thirdly, as I've pointed out, mobile devices are incredibly widely distributed. Basically, everyone has one or soon will. And, we're rapidly steering towards a homogenous environment defined by IOS and Google's Android. Imagine the effect this has on the value of an exploit or attack vector. Finally, the mobile landscape is still being very, very poorly managed. Except for the Apple AppStore, and recent advances by Google to manage the Android market, there is extremely little by way of standardization, automated patching or central management to be seen. Most devices, once deployed, will stay in commission for years to come and so security mistakes being made now are likely to become a nightmare for us in the future.

Thus, the technical issues well known from years of security testing in traditional environments are destined to prevail in mobile, and we're already seeing this in the environments we've tested. This reality, combined with how connected, integrated, distributed and poorly managed these platforms are, suggests that careless decisions today could cost us very dearly in the future...

[1] Mobile Africa Report 2011, Regional Hubs of Excellence and Innovation by Dr Madanmohan Rao, Research Project Director, MobileMonday March 2011

[2] http://www.bbc.co.uk/news/business-17115946

[3] http://prezi.com/as-szhrug5zr/examining-the-impact-of-the-adoption-of-mobile-devices-throughout-africa-and-the-subsequent-rise-of-security-related-risks-sensepost-information-security/

School's never out for the Pro!

We're proud to announce that we are now offering our highly successful penetration testing training courses to the UK market from 2012.

SensePost has been providing penetration testing training courses to corporates and governments across the globe, and at prestige security events such as Black Hat and OWASP for over a decade. Initially, three courses in London for 2012 have been organised:

HBN Extended Edition (4 days) — 13-17, February 2012

HBN W^3 Edition (3 days) — 14-16 March 2012

HBN Unplugged (2 days) — 18-19 April 2012

The first course, HBN Extended Edition is set at an introductory level for technical people without experience in the world of hacking or penetration testing. It presents attendees with the background information, technical skill and basic concepts that are required to get started in this field.

The second course, HBN W^3 Edition, is a highly practical, intermediate web application hacking course for those with some experience in security assessment and penetration testing. The course provides a refresher of HTTP and associated technologies before commencing with more advanced level attacks ranging from assessment techniques of traditional web applications, to newer technologies such as AJAX, rich client media and HTML 5.

Finally, the third course, HBN Unplugged Edition, is an entry-level wireless/ wi-fi security training course. With a strong focus on results, the course outlines three broad offensive scenarios for wi-fi hacking and then presents students with the background knowledge, methodologies, tools and thinking skills required to successfully breach security in each of those scenarios.

All the courses are suitable for those responsible for penetration testing and security assessments including Information Security Officers, System and Network Administrators, Security Consultants and Government agents.

We've been running these courses successfully for years, and in response to the high demand from our UK clients, who are increasingly looking to improve their in-house skills and capabilities in penetration testing we are now offering them in the UK. With so few companies delivering effective security courses for those responsible for penetration testing and security assessments we knew there was a gap in the marketplace plus a real need.

You can click here for more information, or contact us for direct support.