The evil upgrade – attacking software update mechanisms

We saw how we could manipulate packets to replace a downloaded executable with our own naughty payload. Now, we'll look at a nifty variation on this idea: intercepting the HTTP traffic initiated by an application as part of an update check; forging a reply that says yes, your maker has an update for you, tell the user to download it; and then injecting an executable of our choice into the requested download back to the application. 

The update check we're looking at is familiar to most users: when you start up a certain program and, after a few seconds, a window automatically pops up to let you know an update is available. Behind the scenes, the application phones home to do a quick check. It's not much different from the previous injection attack, except this time the application is initiating the communication without user input. But, if it's essentially a variation on the same attack, what makes it special? It's a simple matter of focusing attention on the avenue perceived to be more likely to be attacked, which results in less focus on other avenues. In this context, the industry has focused more energy on securing the user-initiated download. Millions of people open up a search engine and type in download chrome or download media player or other applications on a daily basis. More work has been done to make sure those requests are protected with SSL/TLS. However, the servers set up for applications to phone home looking for updates are very often left running in plain HTTP. They aren't intended for human visitors; they're anticipating a particularly crafted request from a program. While I was researching the preceding attack, I noticed that most of the programs listed in older textbooks as being susceptible to the plain-HTTP injection attacks are today only available through HTTPS with strict transport security enabled. However, I was disturbed by how many programs still do backline updating over plain HTTP.