|This intrusion is no test : SC Magazine : Blog : Home|
Intrusion is no Test
First Published: SC Magazine
One of the most enjoyable parts of being a consultant involved with the ‘attack’ perspective of security consultancy is the continual exposure to a diverse range of infrastructural and operational environments. Moving from one client environment to the next means that you quickly discover which solutions really fulfill their promises, and which ones continually fail.
When assessing the internal security of one of my clients, there is one area of their infrastructure and operational processes that continues to undermine the best perimeter defence solutions – their test environments. Almost all IT and Security departments underestimate the security significance of their test systems. Whether the environment comprises of a single host, or consists of a complete mirror of their businesses critical systems, the humble test system continues to represent the softest target in the compromise of an organisations informational assets.
For many organisations, their test systems are not managed in any consistent manner. In fact, 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. Quite often, even if infrastructure support or security teams are aware of their existence (which is most often NOT the case), the local development or QA team has expressly stated that the environments are not to be modified and access permissions must be left ‘loose’ so as to 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 by an attacker or malicious user within seconds, just waiting for an opportunity. If the system is connected to the live corporate environment or 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 is dependant upon the configuration and role of the environment.
Consider the test environment of a large high-street retailer I assessed not too long ago. They had assembled a number of test systems designed to mimic the relationship between several stores, warehouses and their HQ. Just 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. Firstly, 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-forcing attack which revealed dozens of accounts with passwords equal to the accounts name or “password”.
Secondly, the systems, although running a current service pack, had never had any security updates or patches applied. Therefore numerous 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.
Thirdly, the lax file and directory permissions of the hosts, combined with the mix of file sharing services they ran, meant that almost all significant business data on these hosts could be accessed anonymously anyway.
Some people may have argue that all these vulnerabilities are acceptable since they were only test systems. Unfortunately for the client in question, their systems were designed to accurately represent store-level systems. The hosts had been cloned from standard build instructions, thus all local account (including the local administrator) passwords were identical to the live systems. These local passwords worked for all hosts - including the real stores, warehouses and even corporate HQ.
In addition, for their 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 very 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 had arrived onsite the following morning my laptop had cracked the passwords for almost two-thirds of their 10,000 users – all useful and relevant to their live network.
Lastly, 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 trivial to guess, and their configuration would allow an attacker to brute-force a strong password in any case as no logging or lockout functions were enabled. This client, like many others, had focused so intently upon network based threats that they had forgotten all about things as simple as ISDN war-dialing discovery techniques. Just as importantly, this security failure mimicked the live environment exactly and identified a major threat to their real stores.
Organisations are only now discovering that they have underestimated the threat posed through poor administration and design of test environments - finding themselves vulnerable to trivial attacks that can unravel the best security defences. IT and Security departments need to take authoritative control of these test environments and manage them similarly to any other critical infrastructure component. Otherwise they may discover that their last network intrusion was no test.