Red Team Lessons Learned Series – Episode 2

Do not neglect security in development systems

Introduction

In this series of blog posts I wanted to highlight some common patterns of problems I observed while working in cybersecurity with various organizations. I made most of these observations while working as a Red Teamer, but there are also things that occurred to me when working as an Incident Responder. Read on to ask yourself whether your organization could be affected by any of these problems – and if so – to think what could possibly be done about it.

Development systems ARE production systems as well

During the last 10 years of my career, on many occasions I saw development and test systems’ security being neglected, most likely because they are often not seen as critical assets – as opposed to production systems.

As a result, development assets tend to get lower priority in organization’s security programs, leading to gaps and vulnerabilities in several areas, especially patch management, security monitoring and password policies.

From the offensive perspective, development systems are very high-value targets, as even though they usually do not contain production data, they provide attackers with numerous extremely potent opportunities, like:

• extracting credentials from source code as well as from built deployment packages,
• leveraging source code/bugtracker access to obtain information about vulnerabilities,
• supply chain attacks,
• extracting system and application credentials used by individual developers, to try those credentials against other systems, including production (password reuse).

This high potential for offensive purposes, in conjunction with weak security creates highly potent attack vectors. Poorly configured, not upgraded on regular basis and not monitored development systems usually let attackers obtain at least one working set of credentials (to a remote system/database/password reuse of a system/service/application user), that lets them move laterally without getting any attention from security teams. When development systems are easy to breach with high likelihood of avoiding detection, further advancements against production systems are very likely to stay undetected as well. It is indeed quite difficult to recognize an attack in a successful logon not being preceded with a brute force attack (especially if it happens from the same source IP address), as well as it is hard to detect a supply chain attack caused by backdoored software that came from a compromised development system.

To combat this, organizations need to start seeing development systems for what they are – they produce, and have great impact on what ends up in production systems. Additionally, a supply chain attack risk should be considered also for in-house software which is not (at the time of writing this blog) obvious. Especially since having developed something internally, organizations tend to put even more trust into it than to external vendor products. These risks can be considered even higher, taking into account that internally developed software is less likely to be digitally signed, while checksums of its files are not recognized by external security software.