© 2000 – marc heuse, arthur donkers & arjan vos web hacking a real life case

© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos

Web Hackinga real life case


Web hackinga real life case

• Names and addresses have been changed to protect the innocent• eCommerce application

Will show you that:• “We use SSL” is just not enough• Client side is most vulnerable• Reliable eCommerce needs more than just a computer (e.g. token)


Environment

• Banking application using– SSL (server side only)– Java applet for actual transactions

• Users have:– Username and password– plus TAN code

• Users can:– retrieve bankstatements– transfer money


Architecture

serverMainframe

routerInternet

client


Target selection

• Server is reasonably secure– router filters out all unwanted traffic– no direct connection to mainframe– applet uses its own SSL connection via server

(proxy)– log review, therefore traceability


Target selection

• Client side– beyond control of organization– no real security– no logging– ‘clueless’ users


Staging attackpreparation

• Preparation– Investigation into browser vulnerabilities, use Netscape

as target– Investigation into Back Orifice and Netbus– setting up test environment:

• SSLeay (free SSL software, now superseded by OpenSSL)• Linux server with (SSL enabled) Apache• W95 or WNT workstation with Netscape


Staging attackpreparation

• Netscape vulnerability in handling certificate datebase– Netscape stores its (web and server) certificates in a file

called cert7.db

• Netscape does not detect tampering with this database (e.g. overwriting by an external program)


Staging attackApproach

• Approach:– Stage a Man-In-The-Middle (MITM) attack to

snoop all transactions, possibly altering one.


Staging attackMITM

serverMainframe

routerInternet

clientMITM system


Staging attackMITM

• MITM must:– act as the real server (www.reseau.nl) for client– act as a real client for server

• MITM will:– work for both for https and applet– intercept user authentication– internally decrypt, alter and re-encrypt transactions


Staging attackstep by step

• Do the following:– Create an SSL server certificate for MITM server, using the fake

name (www.reseau.nl)– Install this server certificate on test server (e.g. Linux and Apache)– Visit test server with Netscape, and permanently accept (fake) server

certificate

• and get:– cert7.db file with fake server certificate



• Do the following– Install fake server certificate on MITM system

– Copy all HTML pages from real server to MITM server (not really necessary, but it makes it easier to alter links)

• and get:– an alterable copy of the real server



• Do the following:– Visit real server to obtain Java applet (applet was offered

‘non-cacheable’, but when active, it was stored as a file in $TMP directory)

– copy Java applet from $TMP to a safe place

• and get:– Java applet as a (non-compressed) JAR file



• Do the following:– Under Linux, using jar from the jdk, extract all files from the

applet JAR file– decompile the main class file (binary) back into Java code, using

JODE or Miranda. Apply to other files when necessary

• and get:– readable (and recompileable) Java source, including SSL

handling



Java source code contains one subroutine for verifying server certificate. This subroutine returns TRUE for a correct certificate and FALSE for an incorrect certificate.

Digital fingerprint of server certificate is hardcoded into applet.



This subroutine is only called once, and therefore server identity is authenticated only once, using hardcoded fingerprint.

No further authentication checks are performed (IP address etc.)



• Do this:– alter check routine to always return TRUE– compile altered source and store into JAR file– offer this ‘promiscuous’ applet via webtree on MITM server

(alter one HTML page for this)

• and get:– an applet that accepts any server certificate


Staging attacksidestep

Recompiling applet is cumbersome

Alternative:– use a binary editor to alter hardcoded fingerprint stored in

applet, and change it to the fingerprint of our fake certificate

– advantage: QuickNDirty

– disadvantage: only accepts our fake certificate, and still needs decompiling to analyze the handling of SSL.



Need to build a proxy for https traffic and applet traffic, but how ?

Use stunnel ! A free SSL encrypt or decrypt proxy, available in source (C)

‘Connect’ two stunnel proxies front to back



stunnel1 stunnel2SSL from/to client

SSL from/to server

plaintext

encrypt decrypt

decrypt encrypt



• tunnel1 acts as a server, using fake server certificate

• tunnel2 acts as a client to real server (www.reseau.nl)

• normal https traffic is handled by SSL enabled Apache server, also using fake certificate



• Do this:– Feed plaintext between tunnel1 and tunnel2 to a program

(written in Perl). This program will log all traffic to a log file for further analysis

• and get:– information on datastream exchanged between applet and

server. This turned out to be 3270 terminal traffic



• Do this– use 3270 Perl modules to separate the mask from the real

data in the plaintext

• and get:– the exact location where authentication information is

stored. This location is then stored in this Perl program so authentication information can be retrieved.



Purpose of Perl program is to either:

• alter a payment transaction

• add extra payments at the end of the session



Man In The Middle system is now ready for ‘action’

Attack starts by infecting the client



• Do the following:– prepare Netbus (NT) or BO (W59) payload (e.g. a

Pamela Anderson screensaver ;)– send this to victim

• and get:– unlimited access to victim’s machine



• Do the following (using unlimited access):– overwrite current cert7.db file with our version that

contains the accepted fake server certificate

• and get:– browser that will connect to our MITM server, under

the faked name (www.reseau.nl) without prompting the user to accept this new certificate



• Do the following (using unlimited access):– create or edit a host file on user machine that will map the real

name (www.reseau.nl) to the IP address of our MITM server• NT: \WINNT\system32\drivers\etc\hosts.txt

• and get:– browser that will connect to our MITM server, under the

faked name (www.reseau.nl).


Staging attacksidestep

Alternative to hostfile is to compromise the primary (or secundary) nameserver that serves the name www.reseau.nl

This can be done via cache poisoning or buffer overflow

disadvantage is that this can be detected on server (or ISP) side


Attack breakdown

The following will happen when user wants to visit www.reseau.nl:• www.reseau.nl will be resolved to MITM IP address• browser will connect, via https, to Apache server on MITM machine• browser will accept fake server certificate• browser will load altered Java applet, served up by MITM server• Applet will connect to MITM server tunnel1• Applet will accept fake certificate without warning• tunnel2 on MITM server will connect to real server• Perl module alters transactions or add transactions during session• session is closed


Attack breakdown

• No alterations to real server needed

• Completely based on freely available tools

• Virtually undetectable by server

• Legal implications/liability ??


Attack implications

• Client security is a weakness

• Applicable to a large array of eCommerce solutions

• Aided by ‘bad’ implementations, this is hard to solve


Attack countermeasures

Few measures available, once you’re in, you’re in:

• Strong application-based verification

• Signed applets ?

• Better programming of applets


Coffee Break???

© 2000 – marc heuse, arthur donkers & arjan vos web hacking a real life case

Documents

server mitm

real server slide

marc heuse

arthur donkers arjan

test server

fake server certificate

server certificates

ssl server certificate