Grey bar Blue bar
Share this:

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

Sat, 1 Jun 2013

Honey, I’m home!! - Hacking Z-Wave & other Black Hat news

You've probably never thought of this, but the home automation market in the US was worth approximately $3.2 billion in 2010 and is expected to exceed $5.5 billion in 2016.


Under the hood, the Zigbee and Z-wave wireless communication protocols are the most common used RF technology in home automation systems. Zigbee is based on an open specification (IEEE 802.15.4) and has been the subject of several academic and practical security researches. Z-wave is a proprietary wireless protocol that works in the Industrial, Scientific and Medical radio band (ISM). It transmits on the 868.42 MHz (Europe) and 908.42MHz (United States) frequencies designed for low-bandwidth data communications in embedded devices such as security sensors, alarms and home automation control panels.


Unlike Zigbee, almost no public security research has been done on the Z-Wave protocol except once during a DefCon 2011 talk when the presenter pointed to the possibility of capturing the AES key exchange ... until now. Our Black Hat USA 2013 talk explores the question of Z-Wave protocol security and show how the Z-Wave protocol can be subjected to attacks.


The talk is being presented by Behrang Fouladi a Principal Security Researcher at SensePost, with some help on the hardware side from our friend Sahand Ghanoun. Behrang is one of our most senior and most respected analysts. He loves poetry, movies with Owen Wilson, snowboarding and long walks on the beach. Wait - no - that's me. Behrang's the guy who lives in London and has a Masters from Royal Holloway. He's also the guy who figured how to clone the SecureID software token.


Amazingly, this is the 11th time we've presented at Black Hat Las Vegas. We try and keep track of our talks and papers at conferences on our research services site, but for your reading convenience, here's a summary of our Black Hat talks over the last decade:



2002: Setiri : Advances in trojan technology (Roelof Temmingh)


Setiri was the first publicized trojan to implement the concept of using a web browser to communicate with its controller and caused a stir when we presented it in 2002. We were also very pleased when it got referenced by in a 2004 book by Ed Skoudis.


2003: Putting the tea back into cyber terrorism (Charl van der Walt, Roelof Temmingh and Haroon Meer)


A paper about targeted, effective, automated attacks that could be used in countrywide cyber terrorism. A worm that targets internal networks was also discussed as an example of such an attack. In some ways, the thinking in this talk eventually lead to the creation of Maltego.


2004: When the tables turn (Charl van der Walt, Roelof Temmingh and Haroon Meer)


This paper presented some of the earliest ideas on offensive strike-back as a network defence methodology, which later found their way into Neil Wyler's 2005 book "Aggressive Network Self-Defence".


2005: Assessment automation (Roelof Temmingh)


Our thinking around pentest automation, and in particular footprinting and link analyses was further expanded upon. Here we also released the first version of our automated footprinting tool - "Bidiblah".


2006: A tail of two proxies (Roelof Temmingh and Haroon Meer)


In this talk we literally did introduce two proxy tools. The first was "Suru', our HTTP MITM proxy and a then-contender to the @stake Web Proxy. Although Suru has long since been bypassed by excellent tools like "Burp Proxy" it introduced a number of exciting new concepts, including trivial fuzzing, token correlation and background directory brute-forcing. Further improvements included timing analysis and indexable directory checks. These were not available in other commercial proxies at the time, hence our need to write our own.


Another pioneering MITM proxy - WebScarab from OWASP - also shifted thinking at the time. It was originally written by Rogan Dawes, our very own pentest team leader.


The second proxy we introduced operated at the TCP layer, leveraging off the very excellent Scappy packet manipulation program. We never took that any further, however.


2007: It's all about timing (Haroon Meer and Marco Slaviero)


This was one of my favourite SensePost talks. It kicked off a series of research projects concentrating on timing-based inference attacks against all kinds of technologies and introduced a weaponized timing-based data exfiltration attack in the form of our Squeeza SQL Injection exploitation tool (you probably have to be South African to get the joke). This was also the first talk in which we Invented Our Own Acronym.


2008: Pushing a camel through the eye of a needle (Haroon Meer, Marco Slaviero & Glenn Wilkinson)


In this talk we expanded on our ideas of using timing as a vector for data extraction in so-called 'hostile' environments. We also introduced our 'reDuh' TCP-over-HTTP tunnelling tool. reDuh is a tool that can be used to create a TCP circuit through validly formed HTTP requests. Essentially this means that if we can upload a JSP/PHP/ASP page onto a compromised server, we can connect to hosts behind that server trivially. We also demonstrated how reDuh could be implemented under OLE right inside a compromised SQL 2005 server, even without 'sa' privileges.


2009: Clobbering the cloud (Haroon Meer, Marco Slaviero and Nicholas Arvanitis)


Yup, we did cloud before cloud was cool. This was a presentation about security in the cloud. Cloud security issues such as privacy, monoculture and vendor lock-in are discussed. The cloud offerings from Amazon, Salesforce and Apple as well as their security were examined. We got an email from Steve "Woz" Wozniak, we quoted Dan Geer and we had a photo of Dino Daizovi. We built an HTTP brute-forcer on Force.com and (best of all) we hacked Apple using an iPhone.


2010: Cache on delivery (Marco Slaviero)


This was a presentation about mining information from memcached. We introduced go-derper.rb, a tool we developed for hacking memcached servers and gave a few examples, including a sexy hack of bps.org. It seemed like people weren't getting our point at first, but later the penny dropped and we've to-date had almost 50,000 hits on the presentation on Slideshare.


2011: Sour pickles (Marco Slaviero)


Python's Pickle module provides a known capability for running arbitrary Python functions and, by extension, permitting remote code execution; however there is no public Pickle exploitation guide and published exploits are simple examples only. In this paper we described the Pickle environment, outline hurdles facing a shellcoder and provide guidelines for writing Pickle shellcode. A brief survey of public Python code was undertaken to establish the prevalence of the vulnerability, and a shellcode generator and Pickle mangler were written. Output from the paper included helpful guidelines and templates for shellcode writing, tools for Pickle hacking and a shellcode library.We also wrote a very fancy paper about it all...


We never presented at Black Hat USA in 2012, although we did do some very cool work in that year.


For this year's show we'll back on the podium with Behrang's talk, as well an entire suite of excellent training courses. To meet the likes of Behrang and the rest of our team please consider one of our courses. We need all the support we can get and we're pretty convinced you won't be disappointed.


See you in Vegas!