When developer teams use a central place for sharing their applications or libraries of code, they open themselves to the risk that attackers might get in. And once in, malware can be implanted and distributed with ease.
First Published 25th January 2019
Where are you keeping your packets?
4 min read | Reflare Research Team
Late last week, an older, currently less popular, yet still widely used repository for PHP packets called PEAR was apparently breached by unknown attackers. After gaining access, the attackers replaced a central part of the archive with malware. This means that users of the PEAR packet manager who tried to install or update packages during this period in time were likely infected.
The PEAR project has since taken the drastic step of taking its service offline while investigations into the attack continue.
Why is this critical?
PEAR is an old and widely used packet manager for PHP. While most new projects elect to manage their packets using a software called 'composer' instead, a lot of older software relies on PEAR. This means that the breach and subsequent going offline of the service leaves these projects without automated ways of updating packets. This in turn can become a security concern when a vulnerability in one of the packets is discovered.
Another equally important aspect is the use of automation. Due to the increasingly popular paradigm of cloud computing, many developers chose to automate the installation and updating of dependencies instead of manually installing them. This allows code to be quickly moved between different machines or scaled across several machines. It also prevents issues with unknown dependencies from getting overlooked.
However, this automatic approach to packet maintenance also means that for the most part no human interaction is required when packets are updated using packet managers. Subsequently, for many developers and administrators, determining if their systems interacted with PEAR during the time of the attack can prove challenging. Furthermore, if the attack had gone unnoticed, potentially tens of thousands of servers may have become infected during routine update activities. This risk is likely why the PEAR team decided to take servers offline altogether.
The risks of central targets
As we have discussed in previous briefings, cyber security is always a relative trade-off. The higher the value of a target becomes to an attacker, the higher the security measures have to be to keep it safe - up to the point where it is questionable if extremely high-value targets can be secured at all. Centralized packet repositories represent extremely high-value targets. While they don’t hold large incentives for attackers themselves, they can offer access to thousands or even millions of projects with commercial or ideological value.
While most packet repositories are important enough to attract top talent during their heyday which keeps them secure, older, smaller or failing packet managers can quickly turn into an extreme liability. With developers moving between jobs and often poor documentation of legacy projects, many organizations are completely unaware that their custom software communicates with such repositories on a regular basis.
What can I do to protect myself?
Make sure that all projects that automatically install and update packets are under active development. This includes most applications deployed into cloud infrastructure and many traditional applications. Old and unsupported projects should be taken offline. If you are currently using an old or declining packet management system for a project, consider switching to a more active option.
Lastly, large organizations with dozens of projects are advised to set up local mirrors of packet repositories and have them actively monitored. This creates an additional layer of defence should the original repositories become compromised.