Message-ID: <4E7A4A2E.3030706@crysys.hu>
Date: Wed, 21 Sep 2011 22:33:50 +0200
From: BENCSATH Boldizsar <boldi@...sys.hu>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: secureURL 2.0 design flaws

CrySyS Lab Security Advisory - secureURL.php design flaws

Affected Software: secureURL 2.0 by Nguyen Quoc Bao
URL e.g.
http://www.phpclasses.org/package/2556-PHP-Encrypt-the-parameters-passed-in-link-URLs.html

Product description:
secureURL encrypts URL parameters and additionally protects it by
checksum, thus an attacker
cannot see the 'real' GET parameters of the website and disables
malcious parties to fabricate
modified URL parameters. The checksum protection is optional.


Vulnerability: Design flaws make it possible to find out hash of the
secret used for URL
generation. The problem enables malicious parties to calculate checksum
over fabricated URL
parameters. The design flaws render the system ineffective against
attacks and gives
only false sense of security.           

Found by: BME CrySyS Lab, B. Bencsath, L. Buttyan, G. Pek; www.crysys.hu

1. Problem description

1.1. Decryption attack by known cleartext-ciphertext pairs

secureURL.php encryption mechanism for URL parameters uses simple XOR
operation for
protecting URLs. The key used for the XOR is the md5 sum of the user
defined key.
The parameters are passed in Base64 format.

In function crypt($text,$key):

$key = md5($key);
...
($crypt .= chr(ord($text[$i]) ^ ord($key[$j]));

The usage of XOR makes the system prone to basic attacks. Let's consider
a known crypt URL.
The attacker can educated guess or by other means (access to source
code, other side channels) can
find the cleartext parameter pair for the known crypt URL thus a known
cleartext-ciphertext pair is
available to him or her. Because of the properties of the XOR operation,
the attacker can easily
calculate the values of the key buffer (the value of the md5 sum of the
key).  
$key[$i]= chr(ord($crypt[$i])) ^ chr(ord($text[$i]);
Of course, the original key cannot be recovered by this, but any other
URL can be decrypted by this
information.

1.2. Attacks against checksum protection if hash of the secet is known

In 1.1. the attacker can identify the hash of the key, but not the hash
itself.
However, due to the another design flaw, the information about the hash
of the key is enough
to falsify or fabircate URL parameters.

The corresponding PHP code for the operation in function hash($text) is:
return dechex(crc32(md5($text) . md5($this->key)));

If md5(key) is known, and it is from attack 1.1, then the attacker can
construct
proper "hash" for any fabricated URL in this step without knowing the
original key itself.

1.3. How long URL is needed for attack 1.1?

The XOR uses only the hex string representation of the MD5 hash of the
string, therefore it is
32 characters long but each character represents only a nibble (4 bits)
of the hash. Therefore,
for obtaining all the bits of the key at least 32-byte long
cleartext-ciphertext pair is needed.
If the URL is longer than 32 bytes, then the encryption reuses the same
key string.

1.4. What if parts of the key is missing

It can happen, that parts of the known cleartext-ciphertext pair is
missing as the attacker does not
have anough information on that (e.g. last 2 bytes or such).
Considering that the attacker cannot guess some bits, but the checksum
function is in use,
the attacker can go for a brute-force search for the missing bits. The
search ends if the resulting
checksum is correct for the  case and the server accepts it. By this
technique, the missing bits can
 be found and used up onwards.

2. Fix

To fix the solution, a redesign should be done. Instead of XOR and
CRC32, cryptographycally secure
functions should be used  (AES, SHA-256), and design should consider
attacks. A variety of schemes
are availale in related books. The MD should not be based on the same
key as the encryption. They
can be originated from the same secret, but with  proper technique. For
hash, a shortening of HMAC
scheme can be considered. The key should not be the same  that is used
for encryption.

3. History

The problem was discovered during security analysis of a real-life
system. The author is notifyied
simultenaously with this advisory.

-- 
Boldizsar BENCSATH 
Laboratory of Cryptography and Systems Security
http://www.crysys.hu/
Budapest University of Technology and Economics
Tel: +36 1 463 3422; Fax: +36 1 463 3263; 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists