Have a keen interest on scanning over 12000 IP's a week for vulnerabilities? Excited about the thought of assessing over 100 web applications for common vulnerabilities? If so, an exciting, as well as demanding, position has become available within the Managed Vulnerability Scanning (MVS) team at SensePost.

Job Title: Vulnerability Management Analyst

Salary Range: Industry standard, commensurate with experience

Location: Johannesburg/Pretoria, South Africa

We are looking for a talented person to join our MVS team to help manage the technology that makes up our Broadview suite and, more importantly, finding vulnerabilities, interpreting the results and manually verifying them. We are after talented people with a broad skill set to join our growing team of consultants. Our BroadView suite of products consists of our extensive vulnerability scanning engine, which looks at both the network-layer and the application layer, as well as our extensive DNS footprinting technologies.

The role of the Vulnerability Management Analyst will possess the following skills:

• Be able to multitask and meet client deadlines. We want a person that thinks 'I can do that!'


• Possess excellent written and oral communication skills. Being able to understand a vulnerability and explain it to business leaders is a must.


• A working knowledge of enterprise vulnerability management products and remedial work flow


• A broad knowledge of most common enterprise technologies and operating systems


• A passion for security and technology

Some additional conditions:

• A post graduate degree or infosec certification would be beneficial, however, showing us you have the passion and skills also helps


• This job requires some after-hours and weekend commitments (we try to keep this to a minimum)


• Bonus points for knowledge of sed, awk and python, ok even ruby.


• PCI-QSA is desired but not required

Impress us with your skills by sending an email to jobs@sensepost.com and lets take it from there.

SensePost is an equal opportunity partner.

As we grow and operate on a number of continents, so does our dependence on a rock-solid IT infrastructure. We are expanding our repertoire to include a greater collection of Linux/Open Source/Windows and OS X products. With this, we are on the look-out for a rock star to wrangle control of our internal networks, external cloud infrastructure and help us us utilise technology in a way to make us even better.

Job Title: IT Network Packet Wrangling Penguin Master

Salary Range: Industry standard, commensurate with experience

Location: Johannesburg/Pretoria, South Africa

Real Responsibilities:

• Managing a growing internal network, both in ZA and UK and increased cloud-based infrastructure


• Championing the adoption of new technologies, ways of working and being incredibly excited about security. Yes, we like that type of person who scoffs at the idea of using a plain-text protocol

As a system / network administrator your daily duties and responsibilities will include:

• Providing day-to-day Desktop, Server and Network administration, including helping plakkers (the name we give to all who work at SensePost) with their devices


• Be capable of using a variety of operating systems


• Ensuring our disaster recovery plan is working as it should


• Being the go to person to all those who require assistance with their IT


• Maintaining and administer the telecommunications system


• Administering the network to ensure that the systems in place run effectively and securely (we are, after all, a security company!)


• A real passion for finding technology led solutions to problems.


• Be excited about Unix firewalls, Cisco routers, wrangling network packets, VPN tunnelling and Wi-Fi


• Able to hold a conversation and smile when mentioning SMTP/HTTP/IMAP/Python

Not essential, but bonus points for:

• Actually getting a linux laptop to use an overhead projector, without resorting to swear words in Spanish and Afrikaans


• Administering a Windows server without complaining, at all, not once, in fact, you actually kinda enjoy it.


• Being really passionate about security and showing it doesn't have to get in the way of working productively.

If the above has got you thinking 'weird, it's like they are talking to me bru!' then we want to hear from you. Send us a carrier pigeon message or send us a mail

Taking inspiration from Vlad's post I've been playing around with alternate means of viewing traffic/data generated by Android apps.

The technique that has given me most joy is memory analysis. Each application on android is run in the Dalvik VM and is allocated it's own heap space. Android being android, free and open, numerous ways of dumping the contents of the application heap exist. There's even a method for it in the android.os.Debug library: android.os.Debug.dumpHprofData(String filename). You can also cause a heap dump by issuing the kill command:

kill -10 <pid number>

But there is an easier way, use the official Android debugging tools... Dalvik Debug Monitor Server (DDMS), -- "provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more." Once DDMS is set up in Eclipse, it's simply a matter of connecting to your emulator, picking the application you want to investigate and then to dump the heap (hprof).

1.) Open DDMS in Eclipse and attach your device/emulator

* Set your DDMS "HPROF action" option to "Open in Eclipse" - this ensures that the dump file gets converted to standard java hprof format and not the Android version of hprof. This allows you to open the hpof file in any java memory viewer.

* To convert a android hprof file to java hprof use the hprof converter found in the android-sdk/platform-tools directory: hprof-conv <infile> <outfile>

2.) Dump hprof data

Once DDMS has done it's magic you'll have a window pop up with the memory contents for your viewing pleasure. You'll immediately see that the applications UI objects and other base classes are in the first part of the file. Scrolling through you will start seeing the values of variables stored in memory. To get to the interesting stuff we can use the command-line.

3.) strings and grep the .hprof file (easy stuff)

To demonstrate the usefulness of memory analysis lets look at two finance orientated apps.

The first application is a mobile wallet application that allows customers to easily pay for services without having to carry cash around. Typically one would do some static analysis of the application and then when it comes to dynamic analysis you would use a proxy such as Mallory or Burp to view the network traffic. In this case it wasn't possible to do this as the application employed certificate pinning and any attempt to man in the middle the connection caused the application to exit with a "no network connection" error.

So what does memory analysis have to do with network traffic? As it turns out, a lot. Below is a sample of the data extracted from memory:

And there we have it, the user login captured along with the username and password in the clear. Through some creative strings and grep we can extract a lot of very detailed information. This includes credit card information, user tokens and products being purchased. Despite not being able to alter data in the network stream, it is still easy to view what data is being sent, all this without worrying about intercepting traffic or decrypting the HTTPS stream.

A second example application examined was a banking app. After spending some time using the app and then doing a dump of the hprof, we used strings and grep (and some known data) we could easily see what is being stored in memory.

strings /tmp/android43208542802109.hprof | grep '92xxxxxx'

Using part of the card number associated with the banking app, we can locate any references to it in memory. And we get a lot of information..

And there we go, a fully "decrypted" JSON response containing lots of interesting information. Grep'ing around yields other interesting values, though I haven't managed to find the login PIN yet (a good thing I guess).

Next step? Find a way to cause a memory dump in the banking app using another app on the phone, extract the necessary values and steal the banking session, profit.

Memory analysis provides an interesting alternate means of finding data within applications, as well as allowing analysts to decipher how the application operates. The benefits are numerous as the application "does all the work" and there is no need to intercept traffic or figure out the decryption routines used.

Appendix:

The remoteAddress field in the response is very interesting as it maps back to a range owned by Merck (one of the largest pharmaceutical companies in the world http://en.wikipedia.org/wiki/Merck_%26_Co.) .. No idea what it's doing in this particular app, but it appears in every session I've looked at.

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.

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.