SIK-2016-011


Title:

Unprotected and Unauthenticated HTTP-Connection Malwarebytes App

Report ID

SIK-2016-011

Summary:

The Malwarebytes application contains implementation flaws which can be abused by a man in the middle attack or local attacker. The update traffic at install time or requested by user is handled by an unprotected and unauthenticated http connection. A man-in-the-middle attacker, controlling a WI-FI access point can modify the request/responses of the communication or redirect the traffic to another server providing manipulated files. The files are encrypted with symmetric keys, stored locally in the application. Another weakness is a faulty SSL implementation (certificate check).

Details:

Unprotected Update

The update mechanism via http has no authentication and integrity protection. A man-in-the-middle attacker can change or manipulate the traffic. The signature file is protected by a static key (“TI028Z%th5Y’uX4>dQz|26ULy+.z5$;w)YG2G8ac!9\“{T!W*lp92k@CltD29+(W”) hardcoded in the application and compressed with gzip algorithm. The zlib compressed phishing signatures File is encrypted with the md5 sum of the static key (“xf4kfh9dlk483jmfbn5ujf8dj46m7i8fj4mf96adfh543”). An attacker who extracts the key can manipulate the update files.

Furthermore the encryption algorithm RC4 is an algorithm which should not be used any more.

Faulty SSL Implementation

In the class ara (bytecode name because of class name obfuscation) the checkServerTrusted method is overwritten and does not verify the SSL certificate chain in a correct manner.

...
public void checkServerTrusted(X509Certificate[] chain, String s){
int v1 = chain.length;
for(int v0 = 0; v0 < v1; ++v0) {
 chain[v0].checkValidity();
 }
}
...

The method only verifies the validity Date of the certificate chain (Date valid before and after). (see: http://developer.android.com/intl/es/reference/java/security/cert/X509Certificate.html#checkValidity%28%29). This means a mitm attacker can use each type of self-signed certificate with a valid date to eavesdrop or manipulate the SSL connection.

Depending on the target of the attacker he can abuse the vulnerabilities for different purpose. The crypto flaw can be abused for manipulating and downgrading the detection engine.

The faulty SSL implementation allows eavesdropping or manipulating the transferred data.

Workaround

Avoid public or unknown Wi-Fi hotspots (access points) or use them only through a trusted VPN connection.

Suggested Mitigation

Proposals of a vendor fix can be done using different approaches: (1) transfer the file(s) using a protected SSL (HTTPS) connection and/or (2) establish a correct signature process of the update files/ downloaded files to prevent modification of the files. Avoid unsecure local crypto key storage in the application. The
unprotected symmetric approach must be removed from the application.

Using SSL communication, the TrustManager implementation should not overwrite the checkServer method. The Android operating system is implicitly doing correct certificate validation. If it is required to overwrite the certificate check, this should be done in a correct manner.

Timeline

  • 2016-02-11 Vulnerability Discovered
  • 2016-02-15 Vulnerability Reported
  • 2016-03-01 Vulnerability Fixed