De-faulty security: You're not using preset credentials, are you?

Once upon a penetration test

Over time, penetration testers have acquired a certain reputation and a very special set of skills. These skills are not too dissimilar from the bad guys which organizations are so desperate to keep at bay; albeit we are trusted to disclose our findings in a responsible manner.

A new assignment arrived from a customer, one with specific objectives: identify vulnerabilities on the internal network and proceed to exploitation and penetration further into the network. A typical assignment but permission was granted to exploit and explore; something we do well. Coffee arrived and so did the doughnuts, and we set about discovering the customer's network with scanning software.

1. Scan
   The coffee was still warm, the scans were still running, and a member of our team declared he’d already discovered a web application that looked like an administration portal for the customer’s Active Directory. Reminiscing about times gone by, surely it couldn’t be possible to log in with admin/admin, right?

2. Login with default credentials
   Finish your coffee, pack the laptop away, there is a new domain admin in the house!

3. Gaining privileged access
   As you might have guessed, it was possible to log in with these credentials. The application was using an account with privileged access to the customer’s Active Directory. Designed to make administration of the domain easier; allowing helpdesk admins to manage user accounts.

4. Obfuscation is not security
   With good intentions, the customer had configured the domain administrator account to achieve this. The application was hiding the password of the account with basic obfuscation, but only in the client-side.

5. Exploiting the weakness
   Exploiting the client-side weakness, it was possible to change the password field to show the password in plaintext, in essence revealing to the penetration tester the domain administrator credentials.

6. Full compromise
   With slightly more than half of a doughnut still to eat, he had revealed the most privileged account in IT. The flag was captured, the finish line had been crossed, anything the customer had considered secure was now considered compromised.

Lessons learned

Although this penetration chapter is only a brief extract of the customer’s IT story, many lessons can certainly be learned. What really went wrong for this customer? Was it the default credentials, or was the application failing to sufficiently protect the Domain Administrator credentials?

We need to go back a little further to understand. Information security acknowledges that security controls will fail, therefore reliance upon a single control is simply not effective. Following the story from the beginning you will notice weak or even absent controls, starting with:

• Network Access Controls (NAC): the testers were able to connect to the network without any challenge. NAC could have made the penetration tester work harder to simply connect to the network and its services.
• Principle of Least Privilege: overly permissive credentials. The Domain Administrator account has one purpose: to manage the domain (from the domain controller). Access to this account should be extremely limited.
• Segmentation and filtering: the application found was used for managing user accounts. There was no reason for a non-administrative device to be accessing the application. Functional segmentation should be in place and filter allowed access to the application. Always keep the least privilege principle in mind!
• Default credentials: Always change system and application default credentials. Default credentials are deliberately weak and often publicly known. Policies and procedures should be established that require default credentials to be changed.