As the DevOps revolution continues to sweep across the IT landscape, source code repositories have become a prominent resource for most organizations. They provide a centralized place to track, document and collaborate on changes to applications and are a critical component of modern continuous integration/continuous delivery (CI/CD) workflows. The automation of the technology stack necessary to support an application is a key facet of the DevOps model and the Infrastructure as Code (IaC) paradigm has extended the usefulness of DevOps and source code repositories to “traditional” operations and systems administration teams. As such, most source code repositories now contain not just application source code, but configuration files and scripts used with automation tools like Ansible, Puppet, CloudFormation, Terraform, etc.
While the DevOps model and the increased usage of source code repositories have enormous benefits, they also introduce risks. The accidental exposure of secrets in public source code repositories (e.g., GitHub, BitBucket, etc.) is a well-publicized issue. Over the past six months, Protiviti’s Attack and Penetration testing team, while performing open-source intelligence (OSINT) gathering, has identified publicly available secrets for multiple clients, including a Fortune 100 organization. In one instance, valid credentials were exposed on GitHub for over two years. Despite increased awareness of this issue and the various tools and services available to monitor and prevent the public leaking of secrets, it continues to pose a significant risk. Secrets, in most cases, are not only passwords, API keys and other credential material, but also sensitive information about an organization’s applications, infrastructure and operations, which can be incredibly useful to threat actors.
Significant attention should certainly be paid to publicly leaked secrets and information however, organizations should also be aware of the risks posed by internal source code repositories. During recent engagements, Protiviti’s Attack and Penetration testing team has leveraged secrets within internal source code repositories to compromise Active Directory, gain unauthorized access to credit card numbers and personally identifiable information (PII), and escalate privileges within cloud environments. There are two major factors contributing to this trend:
1. The assumption that the internal network is a trusted zone.
Organizations continue to use both an internal and external model when thinking about their technology environments and spend significant information security capital on securing a distinct and well-defined edge between those environments. While perimeter firewalls, proxies, etc. are certainly important, the edge has been blurry for well over a decade, particularly since organizations started heavily relying on virtual private networks (VPNs) to connect with remote workers, vendors, subsidiaries, etc. Now, with the widespread integration of public cloud services and a global pandemic driving a massive increase in the number of remote workers, the traditional edge simply no longer exists. It is dangerous for any organization to assume that an outsider or insider threat will not be able to operate on the internal network or gain access to an unsecured internal resource.
2. Organizations are integrating DevOps but not DevSecOps.
Despite all of the DevOps benefits, it does not address fundamental security issues that plague software development. Beyond insecure coding practices, developers continue to deviate from best practice when handling secrets, by documenting them insecurely or directly including them in application source code, which then gets pushed to source code repositories. The Infrastructure as Code (IaC) paradigm means that network engineers and system administrators must also be cognizant of secrets within scripts and configuration files used with automation tools, as these files typically end up in repositories alongside application source code. Even if divulged secrets are only for development systems or environments, this can still pose a significant risk to the organization. For example, insecure Jenkins installations and other development systems are routinely exploited by Protiviti during penetration testing engagements, often as the first step in achieving highly privileged access to an organization’s internal environment. More often than not, development systems do not receive the same amount of scrutiny as their production counterparts. In a real-world attack, a compromised development environment or CI/CD pipeline could allow a threat actor to install backdoors or perform other malicious modifications that end up in a production application or environment.
Both of these factors relate to the long-standing idea that effective information security is fundamentally about culture, as opposed to just technical operations and processes. While culture cannot be addressed overnight, in the short term, organizations should pay attention to both public and private source code repositories to ensure they do not contain unsecured information which could be leveraged by threat actors. Protiviti’s Attack and Penetration testing team can assist with identifying such secrets and demonstrating the risk of their exposure.
To learn more about Protiviti’s Attack and Penetration capabilities, contact us.
