The Good and the Evil of Auto-Updaters

7 March 2015

This week I had a lot of delightful discussions with software developers during some security assessments.

Software development in very dynamic sectors thrives of rapid deployment of new functions and bug fixes. In particular in large IT organizations, the classic software rollout concept based on software packaging and distribution is often too slow to meet the needs of this users.

Often, developers try to solve this deployment challenge with auto-updaters. For the initial rollout classic software packaging and distribution is used. Once a bug fix or new function is regression tested a new version is build and pushed to the update server.

At every program startup the auto-updater checks the update server. If a newer program version is available the auto-updater installs them on the user’s computer and starts the new version.

This is a very charming concept. Users and developers love it, because it is fast and reliable. And help desk staff loves it because it ensures, that all users work with the same version.

Unfortunately auto-updaters are popular targets for attackers. For example, in the Home Depot data breach, which became public in November 2014, cyber criminals attacked the company’s software deployment system and deployed custom-built malware to point-of-sales devices.

It is very important that developers become aware of those attack vectors. Update servers, build servers, source control systems are very valuable targets for attackers. The mass rollout of malicious software is easy if an attacker gets access to a build or update server. And anti-malware or task virtualization software is largely useless because the attack is initiated by the end-user.

Spring is near

Spring is near

In my opinion it is very important that organizations secure their software development infrastructure and development processes, accompanied by regular security awareness trainings for developers. If possible enforce the Separation-of-Duties principle for all critical processes.

This is also true for the very popular PowerShell scripts which simplify the job of administrators. If an attacker injects some code in scripts which are used for administration of a company’s servers … Don’t panic!

That’s it for this week. Have a good weekend.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s