Grey bar Blue bar
Share this:

Fri, 13 Jun 2014

Release the hounds! Snoopy 2.0

theHounds
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 README.md 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:
TechnologyHardwareRange
Wi-FiAWUS 036H100m
BluetoothUbertooth50m
ZigBeeDigi Xbee1km to 80kms
GSMRTL2832U SDR35kms
RFIDRFidler15cm
NFCACR122U10cm


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.

Installation


It should be as simple as:
git clone https://github.com/sensepost/snoopy-ng.git
cd snoopy-ng
bash ./install.sh

Usage


Run Snoopy with the command 'snoopy', and accept the License Agreement. We'd recommend you refer to the README.md 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:


Server:

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

Client:
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 README.md 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 (glenn@sensepost.com / research@sensepost.com) if you'd like to engage with us.

Wed, 12 Feb 2014

RAT-a-tat-tat

Hey all,


So following on from my talk (slides, video) I am releasing the NMAP service probes and the Poison Ivy NSE script as well as the DarkComet config extractor.



An example of finding and extracting Camellia key from live Poison Ivy C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi --script=poison-ivy.nse <ip_address/range)
Finding Poison Ivy, DarkComet and/or Xtreme RAT C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi <ip_range>


If you have any questions, please contact research@sensepost.com
Cheers

Wed, 8 Jan 2014

Botconf 2013


Botconf'13, the "First botnet fighting conference" took place in Nantes, France from 5-6 December 2013. Botconf aimed to bring together the anti-botnet community, including law enforcement, ISPs and researchers. To this end the conference was a huge success, especially since a lot of networking occurred over the lunch and tea breaks as well as the numerous social events organised by Botconf.


I was fortunate enough to attend as a speaker and to present a small part of my Masters research. The talk focused the use of Spatial Statistics to detect Fast-Flux botnet Command and Control (C2) domains based on the geographic location of the C2 servers. This research aimed to find novel techniques that would allow for accurate and lightweight classifiers to detect Fast-Flux domains. Using DNS query responses it was possible to identify Fast-Flux domains based on values such as the TTL, number of A records and different ASNs. In an attempt to increase the accuracy of this classifier, additional analysis was performed and it was observed that Fast-Flux domains tended to have numerous C2 servers widely dispersed geographically. Through the use of the statistical methods employed in plant and animal dispersion statistics, namely Moran's I and Geary's C, new classifiers were created. It was shown that these classifiers could detect Fast-Flux domains with up to a 97% accuracy, maintaining a False Positive rate of only 3.25% and a True Positive rate of 99%. Furthermore, it was shown that the use of these classifiers would not significantly impact current network performance and would not require changes to current network architecture.


The paper for the talk is available here: Paper.pdf
The presentation is available here: Presentation.pdf
I'll update this post with a link to the presentation video once it is available.


The scripts used to conduct the research are available on github and are in the process of being updated (being made human readable): https://github.com/staaldraad/fastfluxanalysis


The following blogs provide a comprehensive round-up of the conference including summaries of the talks:


http://bl0g.cedricpernet.net/post/2013/12/12/Botconf-2013-A-real-success
http://blog.rootshell.be/2013/12/06/botconf-2013-wrap-up-day-1/
http://www.virusbtn.com/blog/2013/12_10.xml
http://www.lexsi-leblog.fr/cert/botconf-la-sweet-orange-conference.html


Fri, 6 Sep 2013

Offence oriented defence

We recently gave a talk at the ITWeb Security Summit entitled "Offense Oriented Defence". The talk was targeted at defenders and auditors, rather then hackers (the con is oriented that way), although it's odd that I feel the need to apologise for that ;)


The talks primary point, was that by understanding how attackers attack, more innovative defences can be imagined. The corollary was that common defences, in the form of "best practise" introduce commonality that is more easily exploited, or at least degrade over time as attackers adapt. Finally, many of these "security basics" are honestly hard, and we can't place the reliance on them we'd hoped. But our approach doesn't seem to want to acknowledge the problem, and much like an AA meeting, it's time we recognise the problem.


If you had to look at the average security strategy or budget items, you often end up with a list containing a couple of these:


  • Compliance/GRC - building policies, auditing against them, responding to audits

  • Risk Management - enumerating and ranking all the info sec risks, prioritising them, and justifying spend to mitigate

  • Best Practises - strengthening passwords, pushing patches, configuration management, etc.

  • Technology - cue buzzwords - UTM, WAF, DLP, DAM, SIEM, IPS, AV

  • Staff - everyone needed to get the above stuff done: compliance specialists, risk specialist, security managers, device ops managers


But, the truth is many of these items don't actually block attacks, or the few that do, don't really counter the common bypassed used to side-step them. For example:


  • It's really hard to link risk-based priorities to meaningful technical priorities.

  • Compliance drives a "teach the test" approach with little incentive to create contradictory measurements.

  • Then how can we have a bunch of things called "best practise" when we can't honestly say we know how to defend. Even then, some BPs are practically impossible to achieve in anything but a point in time. And the main point of this talk; common practises have common bypasses.


The current place we seem to be in is akin to having everyone build a wall. Attackers get to evaluate the wall, figure out how to get over it, and add to their capability (i.e. get a longer rope). But once they have a longer rope, they can use it over and over again, and against more than one wall. So attackers, who are quite good at sharing, get to keep building their tool chain, while all defenders can do it to keep building a higher wall, and maintaining the increasingly untenable structure. By understanding how attackers attack, we can break out of this and try more innovative approaches.


The talk is illustrated with four broad examples: Passwords, Patches, Anti-Virus and DMZs. For each, the belief around specific configurations is discussed, and how those don't stand up to how attackers actually attack. For example, the way AV's believed to work doesn't seem to correspond with how easy they are to bypass, or the common configuration of standard password controls such as lockout, don't seem to take into account horizontal brute-force attacks.


The point I want to make here is somewhat subtle; if you walk away thinking I've described new attacks, then you've missed it, if you think I'm recommending "the basics" then you've missed it. Truthfully, maybe it's just that I didn't make it very well ... decide for yourself, here are the slides:

Mon, 19 Aug 2013

BlackHat Conference: Z-Wave Security

We are publishing the research paper and tool for our BlackHat 2013 USA talk on the Z-Wave proprietary wireless protocol security. The paper introduces our Z-Wave packet interception and injection toolkit (Z-Force) that was used to analyze the security layer of Z-Wave protocol stack and discover the implementation details of the frame encryption, data origin authentication and key establishment process. We developed the Z-Force module to perform security tests against the implementation of the Z-Wave security layer in encrypted home automation devices such as a door locks. The paper describes the details of a critical vulnerability discovered in a Z-Wave door lock that could enable an attacker to remotely take full control of the target device without knowledge of the network encryption key. The Z-Force download archive contains the GUI program and two radio firmware files for the receiver and transmitter TI CC1110 boards.
This research will also be presented at 44Con 2013 in London next month, followed by the release of Z-Force source code and US frequency support (908.4 MHz) in the firmware.


Link to conference page and paper: http://research.sensepost.com/conferences/2013/bh_zwave
Link to Z-Force project and download page: http://research.sensepost.com/tools/embedded/zforce