Archive for the JAVA Category

New Zero-Day Java Exploit

Posted in JAVA, Malware with tags , , on January 13, 2013 by keizer

After Julia Wolf, Darien Kindlund, and James Bennett from FireEye, in their post: Happy New Year from new Java Zero-day, observed that a Java security bypass zero-day vulnerability (CVE-2013-0422) has been actively exploited in the wild starting Jan. 2. They have been able to reproduce the attack in-house with the latest Java 7 update (Java 7 update 10) on Windows.

Some initial landing pages are actually hosted on a popular file-sharing website. Eventually the landing pages redirect to several different domains hosting exploits and malware.

The malware will download an executable file from a remote server and execute it by exploiting the vulnerability. Though the malware is designed for Windows only, the vulnerability can also be exploited across different browsers and OS platforms.


The malware payload is ransomware, commonly known as Tobfy. It retrieves a template from the Web, in this case:
hxxp://<random> — and creates a full screen window demanding payment using some kind of social engineering scheme to scare the victim. Additionally, it disables Windows Safe Mode by deleting values under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot, and it terminates processes like “taskmgr.exe,” “msconfig.exe,” “regedit.exe,” and “cmd.exe” in order to deter the victim from trying to find or disable the malware. Strings such as:
\\xneo\\lock\\Release\\lock.pdb and “Conteneur ActiveX” were found in memory and helped make identification easier.

One more noteworthy finding is that the URLs used to download the template and make callbacks are stored XOR encoded and must be decoded before use. However, it appears the author forgot to call the decode function in the callback thread. This means that the malware is unable to communicate with the attacker. The malware is supposed to make an HTTP request for:
hxxp://<random>, but instead requests the invalid URL
hxxp://<random>`utr/qiq. What makes this error even worse for victims is that this callback thread determines whether the victim has paid the fee and is responsible for removing the ransomware from the system. It seems even paying up will do no good in this case!






Posted in Application, Encryption, JAVA on January 26, 2012 by keizer


Hashing – Using SALT properly

Technically, the salt should be unique. The point of the salt is to be individual for each hashed password. The best way to do it is using a random selection with an unpredictable random generator, preferably within a salt space large enough to make collisions improbable (two instances using the same salt value).

Well, sometime it is tempting to try to create a salt from some data which is “presumably unique”, such as the user ID, but it is WRONG! here is why:

1. If you use for example the user ID, an attacker can just pre create a tables for user IDs 1 to 9999 – since a user ID is unique only per system but not worldwide.

2. The same applies to the username: there is one “root” per Unix system, but there are many roots in the world – a rainbow table for “root” could be applied to millions of systems and thus probably have been generated already. Worse yet, there are also many “bob”s and “john”s, and their passwords could be quite weak.

3. Sometimes, users change their password. For each new password, a new salt must be selected – otherwise, an attacker obtained the hash of the old password and the hash of the new could try to attack both simultaneously.

Here is an example for how to use salt:


public byte[] getHash(String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-256”);
return digest.digest(password.getBytes(“UTF-8”));

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don’t really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
The stored password looks like this : Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

and the implementations should be as follows:


public byte[] getHash(int iterationNb, String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-1”);
byte[] input = digest.digest(password.getBytes(“UTF-8”));
for (int i = 0; i < iterationNb; i++) {
input = digest.digest(input);
return input;

Thanks also to: OWASP