I was at Syscan again this year as a volunteer.

As usual, all the talks are very interesting. I’ll write about the few that stood out.

The very first talk of the conference had a really interesting title. Car Hacking for Poories by Charlie Miller and Chris Valasek. It is essentially about how they setup a test bench simulating the environment of a car to test against so that people do not have to purchase a brand new car to perform security research. Very interesting stuff.

Anton Sapozhnikov had a really interesting talk about how to recover the password of the user you compromised on a Windows machine without gaining access to admin privileges through flaws in the Windows SSPI implementation.

Dean Carter and Shahn Harris had a really hilarious skit about the various infosec fails. One of them was dressed up as failymonster. Did I mention this took place in a bar?

The first day concluded with good food and plenty of beer.

The next day, Joxean Koret had an amazing talk about Breaking Anti-Virus software. He spoke about how the results of his fuzzing research against anti-virus software revealed plenty of holes in them. This included gems like injecting non-ALSRed DLLs in processes system-wide, downloading updates over HTTP and a particular AV that ran exec() with user supplied inputs. This talk was really the highlight of the conference.

Josh m0nk Thomas had a really good talk about breaking the SnapDragon SoCs through regulating the power sent to it. Really interesting stuff but most of it sadly went over my head.

Alex Ionescu gave a talk filled with technical details about the RPC, LRPC, ALPC and LPC implementations in Windows. He showed us how the various *PC servers can be exploited to heap-spray and DoS a Windows system. Great talk choked full of information.

The final talk of the day was by Snare who talked about exploiting DMA with Thunderbolt. Really nice stuff as well.

All in all, it was a great conference with nice food and lots of beer. The slides are already available if anyone is interested!

Opencart is a open source ecommerce solution built on PHP. It appears to be a rather popular choice.

Vulnerability #1

While looking through the source code, I noticed a vulnerability in the form of bad password hashing for user accounts in at least two files. admin/model/user/user.php and system/library/customer.php.

Here is the offending code from admin/model/user/user.php.

public function editPassword($user_id, $password) {
    $this->db->query("UPDATE `" . DB_PREFIX . "user` SET salt = '" . $this->db->escape($salt = substr(md5(uniqid(rand(), true)), 0, 9)) . "', password = '" . $this->db->escape(sha1($salt . sha1($salt . sha1($password)))) . "', code = '' WHERE user_id = '" . (int)$user_id . "'");
}

Although the password hash is salted, three iterations of SHA1 is most definitely not slow enough to be a good password hash. I have since reported the issue and a fix should hopefully be incoming. This issue is present on the latest version of Opencart as of this post, v1.5.6.1.

As usual, here is a link to a great essay on the topic of password hashing by Thomas Pornin. Use pbkdf2, bcrypt or scrypt and don’t roll your own.

Vulnerability #2

From upload/system/library/encryption.php,

final class Encryption {
    private $key;

    public function __construct($key) {
        $this->key = hash('sha256', $key, true);
    }

    public function encrypt($value) {
        return strtr(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), $value, MCRYPT_MODE_ECB)), '+/=', '-_,');
    }

    public function decrypt($value) {
        return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, hash('sha256', $this->key, true), base64_decode(strtr($value, '-_,', '+/=')), MCRYPT_MODE_ECB));
    }
}

This Encryption class appears to be used in several places in the codebase to encrypt certain values stored in the database. The obvious problem here is that the ECB mode of operation is used. ECB mode is horribly broken because it leaks information about the plaintext. The most famous visual representation of the issue is of course the ECB penguin.

ecb-penguin

A secondary issue is that the code does not apply a MAC on the ciphertext output. This leaves it open to manipulation without a way to verify authenticity. While it isn’t a problem here as far as I can tell given the usage so far, it is generally never a bad idea to apply a cheaply computed MAC like HMAC.

Here is the link to the GitHub issue.

Update So Daniel Kerr closed both my issues calling one of them a “waste of time”. I’m done with looking through Opencart’s source code. I’m very sure that there are other more serious vulnerabilities lurking inside given the lead developer is completely lacking in knowledge and attitude when it comes to security. I strongly suggest that everyone considering using Opencart to steer clear.

As a bonus, here is the crossdomain.xml file present in HEAD of the master branch.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

If it gets into a released version, every single website running Opencart will be open to a Same Origin Policy bypass through a targeted, malicious flash application. Huzzah!

I am now hosting this blog on Github Pages.

I had been hosting this blog on a Linode VPS for the past year. Linode offers great machines and service for the price and I can strongly recommend them to anyone looking for a VPS. In the end though, a VPS is complete overkill for a simple blog especially after I made the switch from Wordpress to a completely static Jekyll blog. So I decided to move away from Linode to save money and maintenance effort.

Why Github Pages? I was initially considering switching to Amazon S3 with the free CloudFlare CDN plan. However, Github Pages seemed much easier because I already use Github to version control my blog and I did not want to bother with setting up a AWS account.

Setting up the blog itself on Github Pages was a very simple task. Github has great documentation on how to do it. It mostly involved creating and pushing the generated HTML pages to a Github repository and modifying the DNS configurations.

Here’s to blogging more often this year!

A new attack against RSA has been made known this week. Details about it can be found in the paper RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis. One notable name amongst the co-authors of the paper is Adi Shamir, who was one of the three that published the algorithm.

This attack is a type of side-channel attack against RSA. A side channel attack is an attack that targets the implementation of a cryptosystem instead of targeting the algorithm. RSA has been broken by many side channel attacks in the past. The most famous of which is probably the timing attack described by Paul C. Kocher in his paper Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and Other Systems.

This attack works by taking advantage of the fact that a computer emits different sounds when perforing different tasks. With this, it is possible to recover information about the RSA key used during the process of encryption or decryption. Genkin, Shamir and Tromer demonstrated that when the same plaintext is encrypted with different RSA keys, it is possible to discern which key was used in the encryption process. This is a form of key distinguishing attack.

This concept is not new. In fact, it is the topic of Tromer’s PhD thesis Hardware-Based Cryptanalysis published in 2007. What is new about this paper is that the researchers demonstrated an actual attack that is able to distinguish between RSA keys, instead of just the theoratical possibility. What is even more surprising is that the researchers were able to pull off the attack using mobile phones which demonstrates that the attack does not require specialized recording equipment to pull off.

Should you be worried? The attack was demonstrated in lab conditions. It might be a little harder to pull off in real life scenarios where there will presumably be much more background noise to mask the sounds. The actual attack was demonstrated on GnuPG. Updating to the latest version of GnuPG 1.4.x will fix this particular problem. Better still, use the GnuPG 2.x branch which employs RSA blinding that should protect against such side-channel attacks.

While this attack might not be practical as of now, it is very interesting still because many cryptosystems suffer from what are basically implementation problems. Once again, don’t roll your own cryptography!

The topic of this blog post is about using a password for both encryption and authentication.

This is a pretty common scenario. Picture for example an online password manager. A user registers an account specifiying a username and a password. This password serves two purpose. Firstly, it is used for authentication. The password is sent to a server and compared against a hash stored in the database. If the hash matches, the user is authenticated. Secondly, the password is used to derive an encryption key used to encrypt the passwords the user stores in the password manager.

As it turns out, hashing algorithms that are highly recommended for password hashing such as bcrypt, scrypt or pbkdf2 can also be used as key derivation functions. However, the same value cannot be used as both an encryption key and a password hash. This is because the password hash has to be stored on your server. If an attacker manages to compromise your server, he can simply use the password hash to decrypt all the data belonging to the specific user. This rather defeats the purpose of encrypting the data with keys derived from an individual’s password.

Here is a rather common solution to use in this scenario. You can substitute pbkdf2 for any good algorithms like scrypt

  1. Generate two salts s1 and s2 and store them in plaintext.
  2. Generate a random key k using a cryptographically secure random number generator. This means using CryptGenRandom in Windows-based systems or /dev/urandom in Linux-based systems.
  3. Compute pbkdf2(password, s1). This value will be the password hash you store to authenticate users.
  4. Compute pbkdf2(password, s2) xor k. Store this value in your database.
  5. Use k as the encryption key for your data.

When you want to decrypt data, compute pbkdf2(password, s2) and xor it with the value you store in your database to obtain k.

What is the advantage of this scheme? By not directly deriving the encryption key from the password, this allows you to change passwords without re-encrypting all your data. This is very useful in a scenario where your database is compromised. Simply compute the value of k and xor is with the new pbkdf2(password, salt) value.

Thanks for reading, cheers!