Post on 17-Dec-2015
transcript
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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)
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Target selection
• Client side– beyond control of organization– no real security– no logging– ‘clueless’ users
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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)
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackApproach
• Approach:– Stage a Man-In-The-Middle (MITM) attack to
snoop all transactions, possibly altering one.
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackMITM
serverMainframe
routerInternet
clientMITM system
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
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.
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
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.)
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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.
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
stunnel1 stunnel2SSL from/to client
SSL from/to server
plaintext
encrypt decrypt
decrypt encrypt
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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.
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
Purpose of Perl program is to either:
• alter a payment transaction
• add extra payments at the end of the session
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
Man In The Middle system is now ready for ‘action’
Attack starts by infecting the client
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Staging attackstep by step
• 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).
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
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
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Attack breakdown
• No alterations to real server needed
• Completely based on freely available tools
• Virtually undetectable by server
• Legal implications/liability ??
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Attack implications
• Client security is a weakness
• Applicable to a large array of eCommerce solutions
• Aided by ‘bad’ implementations, this is hard to solve
© 2000 – Marc Heuse, Arthur Donkers & Arjan Vos
Attack countermeasures
Few measures available, once you’re in, you’re in:
• Strong application-based verification
• Signed applets ?
• Better programming of applets