Wednesday, 27 May 2015

Logjam: All you need to know

Over the past couple of years the industry is regularly presented with SSL/TLS vulnerabilities and each of them has a unique name/buzzword to it. Some of the past buzzwords have are BEAST, FREAK, POODLE, LUCKY THRITEEN & The latest being “Logjam”. In this post we shall explain as to what exactly is Logjam? Is it actually a threat or just another vulnerability jargon? And lastly we shall explain you how to check if you are vulnerable & mitigate the vulnerability.

Logjam –The Vulnerability

The Logjam vulnerability is a TLS vulnerability found in the “Diffie-Hellman-Merkle” cipher. The attack is much similar to the recent FREAK attack in which the client & server are tricked into using a downgraded export cipher. As mentioned above in our case client-servers using 512 Bit -DHM export grade ciphers are vulnerable. So now we need to understand what is an EXPORT GRADE cipher? Technically speaking none of the ciphers are export as during a connection end to end encryption is being used as well as necessary protocols are put into place. But the cryptographic keys that are used into the ciphers are deliberately weakened so that they can be cracked upon later when required. 

In the 90’s government agencies used to sell software to its enemies using such keys (Export grade) which when need they could crack and monitor their enemies. Later in the year 2000 the US government abandoned the use of such ciphers, but by that time they had already flourished into the industry and where used in many products at different levels. So organizations also had to keep providing support for the ciphers. The problem with export grade is that over the years the computational power increased but the key lengths were not increased.

Why “Logjam”?

The DHM algorithm that is exploited by the vulnerability uses mathematical calculations known as discrete logarithms, short for which are “logs”. The attack uses special logs to jam bogus messages into the data to crack the communication, hence the name “Logjam” was derived.

Logjam - What it takes to launch a successful attack?

One of the most important things to exploit this vulnerability is to have or be able to generate exceptional computing power which can be equivalent to government security agencies or the computational power available at big universities. Let us assume that we have the request power available at our disposal, nevertheless still there are many scenarios which need to be in place for this attack to successful:
  • The attackers must select the target beforehand and must be listening to their traffic before performing the attack.
  • It is also necessary for the attacker to be already having established the “Man in the Middle” connection or be able to immediately establish once the targets start talking to each other. For e.g. if the attacker is at a coffee shop and listening to the traffic, if his targets are not yet decided or is still not in a position to establish a “Man in the Middle” connection the possibility of finding the same target again is quite rare.
  • The attacker needs to have pre computed values that the client will be using or need to have exceptional computational power.

Are you “Vulnerable”?

There are various free tools and website which will help you test your servers, browsers etc. against this attack :
Open source software’s such as OpenSSL or Nmap can also be used to detect the vulnerability. The commands for them are:
  • Open SSL:  openssl s_client -connect www.[yourwebsite/server].com:443 -cipher "EDH" | grep "Server Temp Key"
In the above case if the key is less than 2048 than one should consider themselves to be vulnerable as now a days even 1024 bit keys can be cracked. If the connection fails in the above command than it would mean that there is no support for the DHM on the server and you are safe. 
Now another check that is to be done with open SSL is to check if there is support for export grade ciphers disabled:
  • Command : openssl s_client -connect www.example:com:443 -cipher "EXP"
In this case if the connection is successful than it means export grade is enabled and one needs to disable it.
For Nmap users the command would be:
  • Nmap : nmap --script ssl-enum-ciphers -p 443 | grep EXPORT
The researchers who found this vulnerability have come up with a good guide to securely implement the DHM algorithm and defend against the Logjam vulnerability:

Our Take

We understand that you might be vulnerable to Logjam. But we would recommend you not rush into patching this vulnerability. William Murray a well-known information assurance trainer as nicely said in his recent article “Not all vulnerabilities are problems; not all problems are of same size”.  It might be easy for a security agency to crack a 512 or 1024 Bit key but it is also quite expensive for them. When thinking of patching your systems keep in mind the 3rd rule of Adi Shamir “People do not break crypto, they bypass it.” 


Thursday, 21 May 2015

Android Backup Path Traversal Attack

A vulnerability found by Imre Rad and reported almost 10 months ago came to light before a week. All the android devices running versions below 5.0 are vulnerable to the attack that we shall be discussing further.

ADB stands for Android Debug Bridge which is a command line interface used to communicate with your android device. Using ADB one can add files,views files, delete data,give certain system commands etc. One such command that is used widely is the backup command.  With adb backup a complete back up of your android device is created and stored on your computer. And with the adb restore  command user can restore the full backup when needed.

A vulnerability was found in the way debug bridge handles the storage and retrieval process of the backup. In ADB this process is handled by Backup Manager Service, when a backup is created it is stored with .TAR extension.

If the header of the TAR file is modified and given a path of a malicious file. Then when a backup is restored it the original file will be over written and user shall have a malicious file on the device. To have a better understanding an example is:

Original File Header Path:

Original Value

Changed Header:


Malicious Value
In the above example we have added  “../../” and the file path to the original header. 

To restore we need to first pack our .tar file with the following command:
java -jar abe.jar pack [tar filename][backup filename]

Our tar file packed

Now restore the backup with following command:
adb restore [filename]

Backup restore

Backup Restore Message in Device

Now on restoration of backup the malicious file will be loaded on to the system.

However there are certain pre conditions for the exploit to work :
  • The header checksum must match.
  • The partition on which the retrieval is taking place must be mounted as a writeable partition for e.g. /System would not work but /data would work as it is a writeable partition.
  • The files will not overwrite if it owned by root. This is because the process which is restoring is running as the same user as the package and Andriod packages do not run.
  • With the introduction of new system hardening process for ignoring non system agent packages in Andriod Open Source Project (AOSP) 4.3 it is not possible to overwrite the file in later versions. However is the device is running custom ROM or is rooted and running higher versions such as 4.4 or higher than mostly likely it is possible to overwrite the file.
    • All the pre AOSP 4.3 versions are exploitable without any additional conditions. In this case it is possible to overwrite any file or package that is installed on the system.

Make sure that your devices have the latest patches and security policies installed onto them. We would also like to thank Imre & folks at exploit db for presenting us with such a beautiful exploit. If you have any queries feel free to write to us at or simply leave a comment below.