brainXploit 7: Vulnerability hunt

[kristoffersantiago 36]

Join us in the hunt for the code's vulnerability (vulnerabilities?) and let us know how to fix it to win a Penetration Testing Student training course in the Barebone Edition!

 

brainXploit Rules: https://community.elearnsecurity.com/topic/3505-brainxploit/

[iv.rodriguez 2]

HMAC check has a timing attack vulnerability.

There is no "constant time" check on the integrity of the message. An attacker can incrementally check for the right MAC. ¯\_(ツ)_/¯

[Nomad 1]

temp_var = 0

for (int i=0; i<32; i++)

  {

	if (data[i+hmacOffsetIndex]!=hmac[i])

		temp_var = temp_var + 1

  }

if (temp_var != 0)

	return false;

return true;

or something like this

[andrea.geroldi 0]

you don't check for hmacKey lenght

 

[osama.ibrahim.89 0]

There is no check for the length of the data array. The code just assumes its 64 bytes. 

So an attacker can inject a 32 byte encrypted message with its correct hash. And then append more bytes of some malicious code. The function will pass the message as valid, because the first 64 bytes fulfill the criteria of the function and the rest of the bytes will be processed. 

[verdini.office 6]

Ciao a tutti, hola ,Hello everyone in my opinion if(data.......<=32) isn't correct. It could causean attack Buffer Over Flow?

Maybe is it correct if(data....<32 ) ?

 

Best regards

[Tiago 4]

Like the others said, the length of the HMAC hash sent is not checked, only the data. The way I see it, the attacker always need to send at least 33 bytes (because if it's 32 it will hit the first IF condition).

The code seems to be Java, so it will not cause a buffer overflow. It will just crash with a Index Out of Bounds exception on the For loop.

[roberto.pastorino 1]

On 11/17/2016 at 4:17 PM, iv.rodriguez said:

HMAC check has a timing attack vulnerability.

There is no "constant time" check on the integrity of the message. An attacker can incrementally check for the right MAC. ¯\_(ツ)_/¯

This. There is also an assumption that data received will always be of 64 bytes... 

I'm not a programmer so I'm not sure this won't end on something awful but based on https://codahale.com/a-lesson-in-timing-attacks/   code should be

private bool validateReceivedEncryptedData(byte[] data, byte[] hmacKey)

{

    //check for null arguments

    if ((data ==null) || (hmacKey ==null))

        throw new ArgumentNullException();

    //the first (lenght-32) bytes of data represent the encrypted message

    //the final 32 bytes represent the SHA2 HMAC of the encrypted message

    //data should be of message+hmac = 64 bytes

    if ((data.lenght != 32) && (hmacKey.Lenght != 32))

        throw new ArgumentException();

    //we compute the SHA2 HMAC for the first (lenght-32) bytes of the data

    HMACSHA256 hmacAlg = new HMACSHA256(hmacKey);

    byte[]hmac = hmacAlg.ComputeHash(data,0,data.Lenght-32);

    //test the computed HMAC against the HMAC included with the data

    int hmacOffsetIndex = data.Lenght - 32;

    //we compare lenght of original and computed HMAC

    if (hmacOffsetIndex.Length != hmac.Length) {

        return false;

    }

    int result = 0;

    //we use bitwise inclusive OR and assignment operator to bypass timing vulnerability

    for (int i = 0; i < hmacOffsetIndex.Length; i++) {

      result |= hmacOffsetIndex[i] ^ hmac[i];

    }

    return result == 0;

}

 

[ereda 1]

The attacker can take advantage of timing attack by comparing a forged hmac by the real hmac and analyzing the time until he get a response for the first byte then the second until he gets each byte right. 

it can be fixed by adding random time delay before returning false. 

[ciro_ascione 0]

if data.lenght > 32 and data.lenght-32>32 bypass all logic and return true.

The first step in this code should be set a return variable ti false.

 

[kristoffersantiago 36]

Hey @iv.rodriguez, @Nomad, @andrea.geroldi, @osama.ibrahim.89, @verdini.office, @Tiago, @roberto.pastorino, @ereda, @ciro_ascione! Thanks for your answers! You're all getting invites to the Penetration Testing Student training course in the Barebone Edition.  I'll get in touch with you through direct messaging to get your email addresses.

[Nomad 1]

This is a problem when a site keep passwords in plain text. If everything is perfect ex. constant network speed, constant CPU usage, other stuff you - theoretical - can guess the password letter by letter

in this case with this vulnerability you will know with few micro/nano seconds that hmac is wrong.. and can get the real hmac, so what? if was md5 hash maybe, but maybe you could create another message with the same hash, (i know that md5 is not any more collision resistant - with some resources can create 2 binary file with same hash). SHA256 is collision resistant from what i know