Creating, Detecting and Preventing Malicious Ansible Packages

Infrastructure as Code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure, such as networks, virtual machines, load balancers, and connection topologies. It gained widespread adoption due to its ability to standardize and automate infrastructure provisioning and management, foster collaboration and reproducibility, enhance infrastructure governance and auditing, facilitate rapid infrastructure modifications and deployments, and enable cost optimization and resource management.

The implementation of this paradigm was made possible through various vendors, such as Ansible, Chef, and Puppet. There were repositories for each vendor (respectively Ansible Galaxy, Chef Supermarket, and Puppet Forge) that allowed developers to easily find, download, share, and use pre-made sets of instructions tailored to specific tasks. For instance, deploying an Nginx web server could be achieved through the use of a Nginx role.

Security Concerns in IaC Adoption

The widespread adoption of external resources for IaC raised concerns about the potential security risks associated with relying on these pre-packaged components without thorough scrutiny. The lack of due diligence in examining their source code left systems vulnerable to actors who could inject malicious payloads capable of granting them unauthorized access to an entire infrastructure.

This research sought to establish whether payloads within IaC packages were fundamentally possible. The possible security mechanisms available for detecting payloads (such as third-party SAST scanners and antivirus scanners) were evaluated. Based on these outcomes, further research was conducted to determine whether payloads could be observed within a range of existing community packages in Ansible Galaxy. Ways to prevent such malicious packages are also discussed.