Mallory Proxy

Recently I tried my hands on conducting security tests for client side active content like Flash, ActiveX  & Java Applet based applications. My usual tools like Paros Proxy, Burp Suite etc failed right away. They cannot intercept binary protocol traffic (i.e. Applets client-server communication typically make use of Java Object Serialization and not your standard HTTP).

Burp has a plugin Belch which actually can intercept binary protocols like Applets but I wanted some thing more powerful and extensible which I could use for different types of protocols and something which hopefully will be extended with more features and options over time.

After long hours of Googling and reading, I came across Mallory (Alice Mallory, Bob – Remember?) from Intrepidusgroup.

My initial reaction was – “Its too complicated” and yes it is when compared to Burp or Paros setup. But I had to try it out and so I did!.

In this post, I will explain how to setup Mallory using the VMWare images to intercept/alter traffic. You can download the VMWare images from Mallory website.

1. Network Interfaces setup

2. Updating Mallory & Setup

3. Starting Mallory and Intercepting traffic

In this example, there will be 2 VMware machines (You can use Mallory VMWare image for both) as following

1. First VMWare will act as victim’s machine. It will have its default gateway setup to second VMWare machine IP address. We will refer to this machine as “Alice’s machine”

2. Second VMWare server will actually run Mallory and intercept traffic. It is configured with 2 network interfaces. One which will receive traffic from victim’s machine and the second interface that will forward it onto its destination i.e. internet. We will refer to this as “Mallory’s machine”

1. Network Interfaces setup

Here is how the network file looks for Alice’s machine

auto lo
iface lo inet loopback
auto eth1
iface eth1 inet static
address 1892.168.157.130
netmask 255.255.255.0
network 192.168.157.0
broadcast 192.168.157.255
# Gateway is set to Mallory’s machine IP address
gateway 192.168.157.129

You also need to add a DNS/Name server entry to /etc/resolv.conf file in order for Alice’s machine to be able to resolve DNS entries. Google’s public DNS would do the job

8.8.8.8

And here is the interfaces file configuration for Mallory’s machine

# The loopback network interface
auto lo
iface lo inet loopback

# This NIC will be forwarding traffic onto its destination
auto eth2
iface eth2 inet dhcp

# This NIC will be receiving traffic from victim’s machine
auto eth3
iface eth3 inet static
address 192.168.157.129
netmask 255.255.255.0
network 192.168.157.0
broadcast 192.168.157.255

2. Updating Mallory & Setup

You have to perform these steps only on Mallory’s machine.

1. Follow the steps using the Mallory Minimal Guide until the meeting GUI dependencies section.

2. Download & Run the Mallory Update Script which should update the Mallory scripts

This completes the configuration. You can try pinging Mallory from Alice’s machine to make sure they can see each other.

3. Starting Mallory and Intercepting traffic

1. Open a new terminal (Ctrl+Alt+T)

2. Browse to /home/mallory/mallory/current/src

2. Run sudo python mallory.py

3. If your logs look like the ones in below screenshot, Mallory has started properly

mallory

1. Open a new terminal (Ctrl+Alt+T)

2. Browse to /home/mallory/mallory/current/src

3. Run sudo python launchguy.py and you should see the below screen

launchgui

4. At the screenshot above, you have to select which interface will be used for MiTM purposes and which will be used for forwarding traffic onto its destination

Select eth3 for MitM and eth2 for outbound interface (this is how we had configured our interfaces in step 1. Don’t click Apply Configuration yet!

5. The rules (defined under the Rules Tab) determine what type of traffic to be intercepted. By default there is a rule “Debug All” and I recommend you start with this default rule. If you can’t find it, go ahead and define one as per the screenshot below and click Apply Configuration

defaultRule

6. Go to Streams tab and click Intercept

intercept

8. All set! open Firefox on Alice’s machine and visit Google.com and you should see the traffic entries in the Streams tab

traffic

Ideally at this point try accessing your Flash or Applet, FTP or any other protocol that has some sort of client-server communication and you will be able to see the traffic.

Going through Mallory’s setup process is well worth the effort. I am hoping that it will be developed further.

Java Applet Security

Since I started my career as a programmer, I always struggled getting my head around what Java applets can & cannot access on the local machine. I read many articles about them but always felt I had to try them for my self.

This is my first post & will cover what applets can access when

1. They are not signed

2. They are signed with self signed certificate

3. They are signed with trusted certificate

4. Why signed Applets get all or nothing access permission

5. Windows 7 and XP

So here we go!

1. They are not signed

Applets that are not signed runs within Java sandbox and have limited access. They cannot read, create or delete local files or execute processes. An AccessControlException will occur if the applet tries to access the local file system

java.security.AccessControlException: access denied (“java.io.FilePermission” “C:\Documents and Settings\Administrator\Desktop\New Text Document.txt” “read”)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkRead(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at javaapplication4.NewJApplet.readFile(NewJApplet.java:60)
at javaapplication4.NewJApplet.init(NewJApplet.java:37)

However if you are executing the Applet on the same machine as the web server, it is fully trusted and is treated as signed applet.

2. They are signed with self signed certificate
Applets that are signed using Self signed certificates (not from a trusted source like Verisign) will display a warning to the user that the publisher of the Applet is unknown and running it will grant the Applet unrestricted access.
SelfSigned Applet
If the user checks the “I accept the risk…” and click Run, the Applet now can access the local file system, execute processes etc.
A nice feature of the warning popup screen is that though each certificate has a Common name (DN), its not displayed for self signed certificates against the publisher label. This is due to the fact that the certificate is not trusted and hence the common name cannot be trusted to be accurate as well. A self signed certificate create with a Common name as “Microsoft Corporation” or “Apple Inc” might actually have the user think its actually signed and published a trusted entity.
The publisher is only displayed if the certificate is trusted.
3. They are signed with trusted certificate
A trusted Applet still shows a warning message to the user but a different and little less scary one (Notice the yellow warning Icon is missing)
signed applet
A trusted certificate to Java basically means that the Root certificate (along with its chain) is loaded to cacerts file in jre/lib/security  folder. Private CAs can be loaded manually using the Keytool as well.
A signed certificate from a trusted source also gets full access to local file system.

4. Why signed Applets get all or nothing access permission

So the next logical question to ask is how to trust a signed Applet but yet grant it only limited permissions. The answer is java.policy file. But I will cover it in a separate dedicated post

5. Windows 7 and XP

Since the trust and integrity level at which the Internet Explorer process runs in Windows 7 compared to Windows XP is lower, a signed Applet actually cannot access the whole file system (and it has nothing to do with Java or being signed). For example a signed Applet in Windows XP can write to C:/ drive while in Window 7, it cannot.

So basically in layman words, Windows 7 provides more protection against a malicious Applet compared to Windows XP (and that is generally true for other stuff as well).

Edited on 19 December ,2012
Oracle has made major changes to allow users control the level of security for Applets – including an option to totally disable Applets. More details Here