Java Bytecode Injection
When assessing the security posture of a Java thick application we can usually process the code through a decompiler (such as Jad) and have a proper look at the code. It may be the case that we need to bypass the SSL checks but that is usually it.
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.
Popularity: 1% [?]
Beware of JBoss’ “SecureIdentityLoginModule”
From JBoss' Community Wiki EncryptingDataSourcePasswords page:
The
org.jboss.resource.security.SecureIdentityLoginModulefromjboss-jca.jarcan be used to encrypt database passwords rather than using clear text passwords in the DataSource configuration. [...]
Which in principle, is a great thing. The problem being that usually database credentials end up being placed in the web application configuration file in clear text. However:
[...] It uses a hard-coded password to encrypt/decrypt the DataSource password.
Bottom line, anyone using the SecureIdentityLoginModule to encrypt their password in the configuration file is doing it with a Blowfish algorithm and well known key. So if during an engagement you find a configuration snippet similar to the one below:
<policy> [...] <!-- Example usage of the SecureIdentityLoginModule --> <application-policy name="EncryptDBPassword"> <authentication> <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required"> <module-option name="username">sa</module-option> <module-option name="password">5dfc52b51bd35553df8592078de921bc</module-option> <module-option name="managedConnectionFactoryName">[...]</module-option> </login-module> </authentication> </application-policy> [...] </policy>
You should be able to reverse the encryption and get the credentials in clear text. JBoss.java can help you with this, it is now available in usefulfor's repository at GitHub.
Popularity: 2% [?]
DEFCON 17: a late write up
This year's DEFCON was quite amazing, apparently 10k people showed up in the Riviera for it. This is a late write up because everybody knows already about the fake ATM and the RFID reader near the Wall of Sheep, on the other hand, not everybody knows about other things that also took place. By the way, this is how the back side of one of the ATMs at the conference looked like:
The truth is that you would need 2 or 3 duplicates to get to do all the stuff that you want to do. There are just too many talks, contests and random stuff going on that it is not possible to cover it all. Anyway, below is a breakdown of the talks I managed to get in.
Popularity: 2% [?]
Bypassing Java thick client SSL checks
x509 certificate generation
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.
Popularity: 3% [?]
dradis v2.0 – flexibility unleashed
It has been a long time since the last formal release of dradis (remember the dradis v1.2 one-click installer?). But that does not mean we have been doing nothing in the mean time 
We have been working as hard as one can work: over 487 commits since then (check the stats), we went to DEFCON 16 where a pre-release of the new dradis v2.0 was showcased... But finally we are here, there is a new release ready for you to try and get addicted to!
Lots of new features: new web interface (+10 neatness, +20 usability), new internal architecture (+30 flexibility), new built-in modules (+10 usefulness)...
Popularity: 10% [?]
DeepSec 2008
DeepSec 2008 took place in Vienna in November. For a period of two days attendees enjoyed a good set of talks, a good atmosphere and had the chance to talk to different people from different security backgrounds.
I was invited to present my 'Behind Enemy lines' research, which mainly focused on different attack techniques that are currently affecting a large number of administrative web interfaces.
The slides of this presentation can be found here: [1]
More information about this research can be found in the following white paper: [3] [4]
Popularity: 7% [?]
lucent firewall ruleset parser
Recently I had to go through the ruleset of a Lucent firewall, and the truth is that the export format of the rules is everything but easy to read.
The information is split into three files:
- rules file: Contains the rules, each one takes about 72 lines (rules have many properties, each property is written in a separate line). Rules match source hosts with destination hosts and services, no surprise there, but the value of any of this three key fields can be an alias.
- hosts file: in this file the aliases for host groups are defined.
- services file: service groups are defined here.
So the challenge here is: how do we merge this three files into something meaningful?
I know that purists can do this with a bash one-liner that uses grep, awk and sed, but ruby is my weapon of choice, so I created the lucent_metaparser.rb script. It basically takes the three files and applies some regular expressions to extract the information and store it into data structures and then outputs the rules in format that is easy to go through. Here is an example:-
1047: (CH43) 10.0.1.12 ---(both)--- RF400 [permit https - change 43] - enabled | pass CH43: tcp/443/* () 10.0.1.12 RF400: 192.168.1.140-192.168.1.145;192.252.1.155;192.252.1.120; 1048: (tcp/80) RF132 ---(both)--- PK012 [web traffic to the dmz - change 74] - enabled | pass tcp/80 RF132: 172.0.1.38-172.0.1.226 (external reverse proxies) PK012: 10.15.2.1;10.15.2.2; (internal servers)
I know that it is not perfect and there is room for improvement, but the idea is that the script can be used as a starting point for the review process, and hopefully this will save us some time in the future 
Popularity: 8% [?]
DEFCON 16 – Las Vegas 2008
hack-fu by Matt Hillman
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:
Popularity: 11% [?]
SSID Script Injection
The administrative web interfaces for many wireless access points (APs) provide users with ‘Neighbourhood Wireless Scan’ functionality. This functionality scans for all accessible APs and displays the details of any APs which are identified. However, examination of these administrative interfaces revealed that a large number of them do not properly sanitise the parameters that are passed to them from any accessible APs.
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.
Popularity: 24% [?]
DHCP Script Injection
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.
Popularity: 17% [?]