In April, it was reported that the eScan antivirus update mechanism was targetted by an APT group to distribute GuptiMiner malware. The malware itself is quite sophisticated, but what was baffling to me was the modality of said attack: delivery of the attack vector through HTTP.
The “Lock” on the Browser
If you had been using a computer for a reasonable period of time, and kept yourself abreast of news about scams, you would know that it is important to check your website’s URL to see if it uses a secure connection. Here is one example of my own website.
Clearly, a cybersecurity professional myself that hosts a blog has to practice what we preach. You see the classic lock we have all been accustomed to indicate a site is a HTTPS site. (S here really means “secure”).
Unfortunately, there are still some websites that still do not enforce HTTPS, which can be a pretty serious issue if you transmit important data, such as credentials. Here is an example of what you can see if a site does not use HTTPS:
Unfortunately, such sites still exist, as they use the HTTP protocol, which lacks encryption that HTTPS uses, known as Transport Layer Security (TLS). Basically, connecting to this site means that those on your same network know what you are surfing, in cleartext. An attacker can certainly also intercept said traffic and change the contents to whatever the attacker desires, since it is in cleartext.
But is HTTP Only Used by the Browser?
Unfortunately, people have associated HTTP and HTTPS with the browser so much that they believe that HTTP and HTTPS is only used by the browser. Other connections happen through other magical protocols. This is not true, as a layman analysis of an attack I will bring you through suggests.
Update Delivery Through… HTTP?
Let us come back to the eScan attack. For curious reasons, I wanted to understand how eScan delivers its antivirus updates. A Google search suggests the existence of a wiki page, which is a good start to go through documentation. But the website curiously doesn’t seem to respond to users as of time of check.
Let us use WebArchive to the rescue. It was possible to determine that at least eScan version 14 still used HTTP for updates. In this version of eScan, the users are allowed to choose between FTP and HTTP. None of these are encrypted protocols.
To confirm that the user may not be aware they are using a non-encrypted protocol, I tried to search for a GUI that the user was likely to use to perform said update.
First, it is clear that the user can perform an update through the GUI provided by eScan. eScan updates are reflected in its own GUI as follows:
Basically, it can be assumed that the user is not aware that they are using HTTP to perform their updates.
Summarising Avast’s Research for the Layman
Avast had discovered and analysed said malware campaign since last year. As per responsible disclosure, eScan antivirus had already been informed of the issue, and the issue was patched prior to the public release of said news.
Going through the research from Avast, the attackers had noted the following:
- One set of targets were potentially vulnerable Windows 7 and Windows Server 2008 machines. Another set of targets were relevant machines that contained private keys to cryptowallets.
- The antivirus update mechanism was targetted through a MitM attack.
- eScan is an Indian antivirus company, and its users are mostly Indian (my own searches returned multiple websites in India requesting for payment in rupees, cementing this point)
But a picture speaks a thousand words.
Here, the attackers managed to hijack the antivirus update process, by redirecting said users to a another URL containing the malicious archive through a MitM (which is unknown to Avast as of time of writing).
The rest of the Avast article is primarily of interest to cybersecurity professionals like me, where it describes how the malware embeds itself in the system, has been improved over the years, and even has capabilities to detect and/or switch off other anti-malware solutions. For those interested, the Avast article is a good read.
Lessons for the Layman
Having friends who know I work in the cybersecurity space, I often get asked questions such as whether Software X is safe to use, or whether they could consider Antivirus Y. Often, the answers I give them are either one of two:
- I don’t use the software, so I don’t know exactly how it works, so I can’t tell you.
- While the software claims to use mechanism M, I cannot confirm this for sure, so I can’t tell you either.
Even for an antivirus software, I had to do some reading to be able to understand why a user using said software could have been vulnerable to a MitM.
But the layman is not helpless. At the least, there are learning lessons.
- Understand how the update mechanism of a piece of software works. Ensure that these updates are provided through an encrypted channel (prevents MitM) and are digitally signed by the vendor (instructions to check the signature are here for certain file types: https://help.deepsecurity.trendmicro.com/aws/crypto-digital-signature.html)
- Read documentation of software used. Sometimes, the documentation literally mentions security issues that ought to have been mitigated.
- Keep abreast of changing cybersecurity standards. Products improve over time, and this also includes their cybersecurity posture. But they may not always be enabled. Be on top of what your own software can do.
- When in doubt (and there are many doubts we’ll have), ask a cybersecurity professional. We’re friendly people!
- [FREE SERVICE]: If you are in the tech sector, it may help to subscribe to your own country’s Computer Emergency Response Team (CERT). For Singapore, click here to subscribe to SingCERT. At the least, it provides you information on threats the authorities are currently watching for, with advisory to deal with various cybersecurity threats the country notices.