Consultants view: This intrusion is no test
When assessing the internal security of my clients, there is one area of their infrastructure and operational processes that continues to undermine the best perimeter defense solutions – their test environments. Almost all IT and security departments underestimate the security significance of their test systems. Whether the environment comprises a single host, or consists of a complete mirror of their businesses-critical systems, the humble test system continues to represent the softest target within the scope of most organizations' informational assets.
Few organizations manage their test systems consistently. A lot of test environments are simply referred to as "that kit over there" – a shared resource of aging servers where administration is the responsibility of the last person to use them. And even if infrastructure support or security teams are aware of their existence (which is rarely the case), the local development or QA team often stipulate that the environments are not to be modified, and that access permissions must be left "loose" so they will not affect testing deliverables or project timelines.
This means that test environments continually suffer from open-access permissions, poor patching levels, lax backup implementations, and general neglect. From a security perspective, the repercussions are easy to quantify – the system can be compromised within seconds by an attacker or malicious user waiting for the right opportunity. If the system is connected to the live corporate environment, or if it is accessible remotely and makes use of confidential business data, any compromise of the system will lead to a loss of business integrity and confidentiality.
How damaging can the compromise of a test system be? A lot depends upon the configuration and role of the environment. Consider the test environment of a large high-street retailer I recently assessed. It had a number of test systems designed to mimic the relationship between several stores, warehouses and its headquarters. Like the real stores, each environment had its own ISDN lines, routers, servers and standard access to live business data streams.
A number of significant security issues were discovered and exploited within the first 30 minutes of testing. First, none of the systems had been hardened to any significant degree and had a number of default services. It was thus a simple enumeration process to identify all the user accounts and data connections on the hosts and routers, which was quickly followed by a simple brute-force attack that revealed dozens of accounts with passwords equal to the account's name or "password."
Second, the systems (although running a current service pack) had never had any security updates or patches applied. Therefore, several services were vulnerable to remote attacks that would lead to user and administrator level interactive access. After only a few minutes sifting through various online code repositories for appropriate exploit code, compromise of the most significant hosts was achieved.
Third, the lax file and directory permissions of the hosts, when combined with the mix of file-sharing services they ran, meant that almost all significant business data on these hosts could be accessed anonymously.
Some people might argue that all these vulnerabilities are acceptable because they are only test systems. Unfortunately for the client in question, its systems were designed to accurately represent store-level systems. The hosts had been cloned from standard build instructions, so all local account passwords (including those of the local administrator) were identical to the live systems. These local passwords worked for all hosts – including the real stores, warehouses and corporate headquarters.
In addition, for its system to work efficiently, the environment required access to the corporate LAN and its own backup domain controller. One of the systems compromised within the first 30 minutes of the assessment through poor patching was this backup domain controller. It didn't take long to recover a copy of the domain authentication databases and start the decryption process. By the time I arrived the next morning, my laptop had cracked the passwords for almost two-thirds of their 10,000 users – all useful and relevant to the live network.
Finally, access to the hosts could be achieved through their ISDN routers. While the passwords used on the routers were not as poor as "password," they were easy to guess, and their configuration would allow an attacker to brute-force a strong password, because no logging or lockout functions were enabled. This client, like many others, had focused so intently upon network-based threats that it had forgotten all about things as simple as ISDN war-dialling discovery techniques. Just as importantly, this security failure mimicked the live environment exactly and identified a major threat to its real stores.
Organizations are only now discovering that they have underestimated the threat posed through poor administration and design of test environments, and are vulnerable to trivial attacks that can unravel the best security defenses.
IT and security departments need to take authoritative control of these test environments and manage them as they would any other critical infrastructure component. If they don't, they might well discover that their last network intrusion was not a test.