In-Depth
Malware Attacks the Software Update Process
How performing a software update can hijack your system.
by Itzik Kotler
Imagine that you're sitting in an airport, waiting at the gate for your flight to board. There's free Wi-Fi high-speed Internet access in the terminal and you're taking this opportunity to go on with reading your documents and answering e-mails. The laptop is up and running and in minutes you're logged-in to your company's VPN (virtual private network). Meanwhile in the background, your favorite video player application has detected that there is network connectivity and it also takes the opportunity to do its periodic check for a newer version available for download.
Software updates are a great way for software vendors to bring their customers the latest experience of their bug-free, security-patched, and new feature-armed software, but depending on where you execute the update and how much effort the software vendor invested in its update process, it could also be a great way to catch a malware.
In the past, software updates were distributed over floppy disks and CDs. Today, most vendors publish their updates on their Web sites and program their applications to access and download the update either automatically or with user approval.
The risk in a software update via network connection is that an attacker can intercept the requests or updates via “man-in-the-middle” attacks and send malware instead, exploiting the expected check for new updates and download mechanism to introduce a new route for malwares and rootkits. This vulnerability also affects mobile phone and PDA applications that enable updating.
Chronicle of Vulnerability
There are network environments that are more prone to man-in-the-middle attacks than others. For example, unencrypted public Wi-Fi access points (such as in airports and coffee shops) are insecure, enabling an attacker within a few yards to monitor and inject traffic. Other techniques that could be used for subverting a software update are DNS cache poisoning vulnerabilities and the old ARP spoofing attack over Ethernet, to name a few.
There is no standard for software update processes, so every software vendor implements it in his application as he sees fit. A software update is vulnerable if it does not employ a digital signature scheme. That is because without one it's nearly impossible for the application to authenticate or verify the integrity of the update response or download.
The two most common and popular types of implementations of a software update use the HTTP protocol for communication and downloading. However, the HTTP protocol does not provide any digital signature scheme option and so the majority of the software updates are, in fact, vulnerable to this attack.
The first implementation type has two phases. First, the application accesses a document in which it expects to find a list of all available or relevant versions along with a download link. More often than not this document is an XML file or a similar document type that can be static or generated by a PHP or similar script. In the latter case, the application starts by passing its own version and other details such as operating system as URI parameters to it. If there is a version entry in the document that is higher than the currently installed version of the application, it would go to the second phase and begin downloading the update from the specified link.
In this implementation there are two failure points. The first failure point is that an attacker could forge a version entry with an imaginary version. This would get all the versions including the latest to perform an update and download a malware. The second failure point is that an attacker could stick to the real version's releases and "redirect" the download link to malware.
The second implementation type is much simpler and straightforward. The application is programmed to download from a pre-defined URL an executable binary, such as SETUP.EXE, and run it. This executable would determine at runtime whether an update is required, and if so it would proceed further to download the rest of the files. In such implementations, the failure point is obvious and stands out -- the attacker can redirect the download request to another site which contains a malware called SETUP.EXE which would be executed on the victims' machine.
Nothing should be left to chance. An attack tool program can completely automate this, using a compiled database of request-response samples for different software update processes. It would monitor network environment and once detected a request of a known update it would automatically generate a response with malicious malware link. If an attempt to download is detected, the attack tool could redirect the request to a malware hosting site instead. Requests redirection is an acceptable and legitimate action that is supported by the HTTP protocol as part of its load-balancing features set.
A Break with Tradition
This vulnerability is not traditional software vulnerability, as it does not exploit a specific software instance but rather the software as a platform to gain remote-code-execution and disk access. It only requires exposure to a network environment that enables man-in-the-middle attacks and a software update process that can be tampered with.
It is possible to engineer the first airborne computer worm, considering successful software-update exploitation on unencrypted public Wi-Fi as a case study. The requirements are a Wi-Fi adapter and an attack tool -- a program that can identify software update communication and respond correctly. The victim also must have a Wi-Fi adapter (to connect to the network) and an application that performs an insecure software update. Once exploited, the malware is running on the victim's computer and containing the attack tool code in it. From this point, the victim's computer can begin attacking others in this or any other network environment in the same way it has been attacked in the first place.
Disabling or preventing the software update feature is merely a temporary solution to this vulnerability. There are good reasons to keep software up to date, such as preventing known security vulnerabilities and stability bugs from affecting your system. The real solution is to invest in the software update process and increase its transparency, having software vendors and developers adopt and use public key cryptography in the update process.
A copy of the public key in the application could be used as a digital signature to verify whether the requests' response and download is signed, making the software update process secure even if it takes place in a network environment that is prone to man-in-the-middle attacks because an attacker has no reasonable way of getting the vendors' private key and sign his malware.
The next time you join an unencrypted public Wi-Fi access point or any other risky networks environments, practice caution and avoid software updates. Ask your software vendors whether they provide secure software update. It's better to be safe than sorry.
Itzik Kotler is security operation center team leader for Radware (www.radware.com). You can contact the author at itzikk@radware.com.