IT Security: Kaspersky antivirus exposed users to traffic-interception attacks

Share This

The certificate validation mechanism relied on weak 32-bit signatures that were susceptible to collisions, researcher found

Security vendor Kaspersky Lab has updated its antivirus products to fix an issue that exposed users to traffic interception attacks.

The problem was found by Google vulnerability researcher Tavis Ormandy in the SSL/TLS traffic inspection feature that Kaspersky Anti-Virus uses to detect potential threats hidden inside encrypted connections.

Like other endpoint security products, Kaspersky Anti-Virus installs a self-signed root CA certificate on computers and uses it to issue “leaf“, or interception, certificates for all HTTPS-enabled websites accessed by users. This allows the product to decrypt and then re-encrypt connections between local browsers and remote servers.

Ormandy found that whenever the product generates an interception certificate it calculates a 32-bit key based on the serial number of the original certificate presented by the website and caches this relationship. This allows the product to present the cached leaf certificate when the user visits the same website again instead of regenerating it.

The problem, according to Ormandy, is that a 32-bit key is very weak and an attacker could easily craft a certificate that matches the same key, creating a collision.

He described a possible attack as follows: “Mallory wants to intercept mail.google.com traffic, for which the 32-bit key is 0xdeadbeef. Mallory sends you the real leaf certificate for mail.google.com, which Kaspersky validates and then generates its own certificate and key for. On the next connection, Mallory sends you a colliding valid certificate with key 0xdeadbeef, for any commonName (let’s say attacker.com). Now mallory redirects DNS for mail.google.com to attacker.com, Kaspersky starts using their cached certificate and the attacker has complete control of mail.google.com.”

This implies that the attacker — Mallory in Ormandy’s example — has a man-in-the-middle position on the network that allows him to redirect the user accessing mail.google.com via DNS to a rogue server under his control. That server hosts and presents a certificate for a domain called attacker.com.

Under normal circumstances the browser should display a certificate error, because the certificate for attacker.com does not match the mail.google.com domain accessed by the client. However, since the browser will actually see the interception certificate generated by Kaspersky Anti-Virus for mail.google.com, and not the original one, it will establish the connection without any error.

The 32-bit key is so weak that certificate collisions would also occur naturally during normal browsing. For example, Ormandy found that the valid certificate used by news.ycombinator.com has the same 32-bit key calculated by Kaspersky Anti-Virus as the certificate for autodiscover.manchesterct.gov.

According to the researcher, Kaspersky Lab pointed out that there is an additional check being performed on the domain name in addition to the 32-bit key. This makes attacks harder, but not impossible.

“We were able to come up with alternative attacks that still worked and Kaspersky resolved it quickly“, Ormandy said in an advisory made public Wednesday. The company fixed the issue on Dec. 28, he said.

Security vendors justify their SSL/TLS interception practices through a legitimate need to protect users from all threats, including those served over HTTPS. However, their implementations have often resulted in security issues. That’s because performing certificate validation correctly is not easy and is something that browser vendors themselves have perfected over many years.