Vulnerabilities in Mobile Security software (including ESET)

[rugk 397]

The Fraunhofer Institute for Secure Information Technology (SIT) published a research paper where they explain many different vulnerabilities they found in mobile security/antivirus software.

They found vulnerabilities in products from Kaspersky, ESET, Avira, McAfee and Clean Master Security. Most vulnerabilities are already fixed in the latest version of the products.

 

So of course we focus on ESET here...

 

 

The ESET Mobile Security & Antivirus application contains implementation flaws which can be abused by an attacker. The application contains an incorrect SSL certificate validation, which  can be abused by an attacker for eavesdropping or manipulating the communication. Furthermore, an attacker can steal the ESET license information or the user and password for the license. The Mobile Security scanner also implements an encryption scheme, which is violating Kerkhoffs’s  principle (hide the key, not the algorithm). The implemented crypto scheme is vulnerable to chosen cipher  text attacks and could be easily broken. Encrypted information can be decrypted to plaintext. We wrote a  short proof of concept script attached at the end of this document.  The crypto scheme is implemented within the native code layer. It should be verified if the scheme is  utilized in other ESET products.  If this is the case, please fix it also there.

 

So they found two vulnerabilities: failed SSL/TLS verification and a broken encryption.

Looking at the details in the PDF is interesting. They overwrote the Androids default SSL verification, which many anyone can easily intercept SSL secured traffic:

 

In the current implementation this method [for verifying SSL/TLS] is empty, which means it does not validate the correctness of the server certificate nor the whole certificate chain.

 

This is a widespread issue on Android app developers, but I thought at least ESET would get it right...

 

And then we have the license username/passwords. Basically this is more or less and old issue and we had (and AFAIK still have) it in desktop products of ESET too.

To summarize the linked topic: The username/password were send in plain-text only BASE64 encoded (Base64 is easily reversible and provides no security).

 

So in EMS they changed this a bit:

• At first they seem to use SSL/TLS now. But as said before, it was implemented incorrectly and therefore did not provide any protection.
• But they implemented an "encryption" for the username/passwords.

So what does the Fraunhofer Institute SIT say about this encryption?

 

In our analysis we did not completely reverse engineer the applied encryption scheme for the license information, but we used chosen cipher text attacks in order to break it. The encryption is done by XOR the input value with a key generated by a random stream. In order to retrieve the key we utilized, for instance a username consisting of 25 times “a”. After that the application encrypted the username and the application with BASE64. We decoded the BASE64 String and XORed
the byte array (50 byte) with 25 times of “a” (each 2ndbyte) and we got a key with the length of 25 bytes. We attached a proof of concept script,which will decrypt the LicenseUsername and LicensePassword up to the length of 25 characters. In the same way it would also be possible to generate longer keys but it depends of the length of username and password. Most people choose shorter ones.

 

So about the last sentence one fact has to be added: ESETs licenses passwords and usernames are generated automatically and users cannot use a longer password even if they would like to do so.

But generally this "encryption" is useless anyway, because

 

The given encryption/obfuscation, behind the BASE64 encoding, of the credential information does not provide enhanced protection in this attack scenario, because the attacker does not need to decrypt it to authenticate. He retransmits the sniffed (partial) XML information in his own context and gets authenticated.

So IMHO the SSL/TLS flaw is much more serious than the second encryption flaw as username/passwords of ESET licenses can "only" be used to hijack this license and e.g. register additional devices using the license of the victim. However the TLS issue is really a basic flaw and I strongly suppose it also affects the username/passwords of ESET Anti-Theft e.g. when you connected your Android device with it.

Also when anti-theft is triggered users photos, location and more things are uploaded - using an SSL/TLS connection. If that's not secured it can easily be intercepted.

So there are still some open questions:

1. Are these vulnerabilities already fixed in EMS? If so what is the latest (VSD or product) version affected by this issues?
2. When the SSL/TLS verification is properly done, I highly suggest another thing: You should really implement key pinning to protect the SSL/TLS connection.
3. Is this "encryption"-approach of ESET license username/passwords also done in other ESET products? If so is it already fixed/replaced by a proper SSL/TLS connection there?

 

BTW: It is also interesting to read through the whole PDF and look at the flaws of other security products. There are SSL/TLS flaws, XSS scripting and remote code execution vulnerabilities.

Edited June 2, 2016 by rugk

[rugk 397]

So the German ESET department tweetet about this. Basically they confirm that the SSL vulnerability is fixed now.

 

Analysed version: 3.2.4

Fixed version: 3.2.60 (published in March 2016)

[rugk 397]

Just as a reminder: I have still no information about the "encryption"-issue. So my questions asked in the first post are still not completely answered.