Compromised credentials are a tried-and-true tactic for hackers looking to gain access to secured systems, including personal accounts, corporate networks, SaaS applications and even development environments. After all, why should hackers attempt to bypass the security controls of an organization when they can simply log-in with valid credentials they obtained through phishing, social engineering, a password dump or simply purchased off the darkweb?
While the use of compromised credentials is probably as old as the use of credentials themselves, it still remains an incredibly prevalent approach that has proven to be difficult to defend against. In fact, according to this year’s Verizon Data Breach Investigation Report, roughly 1 in 4 breaches last year involve the use of stolen credentials.
In this post we will explore why hackers are targeting developers, what happens if bad actors obtain their credentials, and what your organization can do about it.
Coder Credentials are the New Crown Jewels
By definition your organization’s developers are privileged users. They have access to your source code and development environment, which in turn has access to your customers and their data by way of your application. If your developers’ accounts are compromised — by something like a phishing attack, a cleverly crafted social engineering post, or other means like machine compromise — then your organization is at risk of breach, and one that isn’t just limited to your source code.
Developers generally have over-provisioned access to your environment based on the possibility that they might, at some point, need access to a system or resource to do their jobs. This is good for developer efficiency but it is the antithesis of security and unlearns almost everything we established about access controls in the 1990s. Hackers that gain access to developer credentials can cause a host of issues such as inserting malicious code into your application, leaking or copying your source code, adjusting security controls, stealing production or customer data, installing backdoors, changing restricted resource settings to expose them to the public internet, or even tampering with infrastructure as code configurations. Moreover, developers often have access to databases containing sensitive information, and attackers can use developer accounts as a foothold to move laterally in an environment. Ultimately, the level of access and options that credentials to developer accounts afford bad actors, makes them incredibly attractive targets.
Earlier this year a similar incident happened to Ubiquiti, a leading vendor of IoT products including WiFi routers, security cameras, and network video recorders. Hackers used compromised privileged credentials to access Ubiquiti’s AWS servers, gained root admin access to all AWS accounts, including all S3 data buckets, databases, user database credentials, and the secrets required to forge single sign-on (SSO) cookies. When the attack was discovered, the attackers proved they had stolen Ubiquiti source code and asked for a 50 bitcoin (~$2 million, at the time) payment to remain quiet about the breach.
How Did We Get Here?
There are several factors which are give hackers the opportunity to use compromised credentials to exploit DevOps pipelines. A few of the most important are:
- AppSec alphabet soup – The focus of AppSec has historically been securing contents (SAST/SCA) and output (WAF) of DevOps pipelines not on developer credentials or securing the pipeline itself.
- DevOps automation expands the attack surface – As our SDLCs become more efficient in DevOps models, they become more interconnected, this in turn expands the potential damage that can be done by attackers. For example, with access to a developer’s GitHub account, an attacker can potentially impact all phases of the SDLC via access to feature code, GitHub Actions, and access to infrastructure-as-code. Attackers can literally tamper with code and then build and deploy new versions of the production app all from within GitHub.
- Attackers target the weakest link – humans are typically a weak link in any system because they are human (and as such make mistakes); developers are no different.
These conditions come together to create the perfect storm for AppSec professionals. Attackers essentially have 1.) a gap in defenses to exploit, 2.) a way to widen that gap into a chasm, and 3.) an attack vector that gives them direct access to that gap.
What Should You Do About It?
- Harden authentication – Implementing strong authentication practices can all help reduce the risk of developer credentials ending up in hacker hands, and help ensure that developers are who they claim to be. Best practices include:
- Using multi-factor authentication
- Restricting IP range access
- Leveraging single-sign-on.
- Enforce least privilege – Regularly audit for excess privileges and limit developer privileges to those needed to perform their duties; this reduces the scope of damage that could occur should an account be compromised.
- Eliminate secrets in code – Insiders can also be malicious. Anyone who has access to a repository with hardcoded credentials also has access to resources that the credentials are supposed to protect. Hardcoded credentials should be checked for in production versions, version history and new commits before they are merged into the main branch.
- Automate provisioning & deprovisioning – Developer accounts often fall outside of the automated provisioning and deprovisioning processes organizations use in AD, LDAP, or HRIS systems. This frequently leads to manual errors such as failing to deprovision developer accounts after they’ve already left the organization.
- Audit the basics – It’s Important to remember to regularly test that systems aren’t using default passwords and to regularly scan the public domain for your proprietary source code because of the prevalence of hardcoding credentials, keys and/or tokens into code that developers assume will never be exposed externally.
- Enforce branch protection rules and monitor critical code – Before any code is merged into the main branch, the changes should go through a code checking review process that includes a series of security tests including SAST, SCA, secret detection and peer review. Force pushing should be disallowed and the rules enforcing these branch protections should be monitored for any changes so that malicious actors cannot circumvent the security tests.
How Cycode Can Help
Cycode helps you prevent compromised developer credentials resulting in a breach by securing your entire DevOps pipeline from code to cloud. Cycode provides you complete visibility over what assets exist and who has access to what through a cross-SCM inventory of all users, contributors, teams, organizations, and repositories in your organization. Cycode also helps you automatically audit access privileges to identify and reduce excessive, unused privileges, and implement separation of duties. Furthermore, Cycode helps ensure that strong authentication and secure development practices are in place.
Want to learn more?
A great place to start is with a free assessment of the security of your DevOps pipeline.
Originally published: August 3, 2021
