October 10, 2019

Default Credentials, Simple but Devastating – WST

A common weakness we encounter on Internal Penetration Tests is not what you may expect.  It is not the latest 0-day vulnerability, nor is it a hard to exploit vulnerability.  Sometimes all it takes is a web browser to result in a simulated (or real) attacker gaining full control over your entire network:  Default Credentials.

While simple and seemingly a “no brainer” to fix, the reality of modern production networks is that even with mature change control, devices and applications still configured with default credentials can happen.  An example that this engineer has seen on multiple engagements is a trial or demo of a systems management solution still configured with its default logon of “admin/admin” (or something similar).  These solutions often offer a pre- configured VM (virtual machine) “appliance” that you download and run in your environment.  Because it isn’t in “production” yet, many IT folks don’t see a reason to change this default username/password.  Why would they?  They are just taking it for a test drive!  The problem becomes quickly clear as many of these management tools will need domain administrator privileges to perform their functions, e.g. deploy patches, inventory remote systems, etc.  These domain admin credentials are entered to see how well the solution works.  Many times, the system works great, is purchased, and goes from testing to production – many times the default logon is never changed!  Or, just as common, the software isn’t purchased, and the VM is left on by accident, still configured with default credentials.

As an attacker, gaining access to management or monitoring solutions is almost always a sure-fire way to gain domain admin level privileges.  If you can’t use the software to create your own domain admin logon, you can use its management features to deploy software, run remote consoles on servers (as a domain admin level user), or sometimes just view clear-text or easily decryptable passwords.

While easy to overlook, and extremely dangerous, the fix is still simple, change credentials on any devices or software that get deployed into your environment…even for testing.  Some other recommendations include:

    • Change control processes should include a step to change default credentials on any new systems.  It is also important to read the documentation.  Often the “admin” user isn’t the only privileged user pre-configured in a system.   All built-in users should have their passwords changed, disabled, or removed if not needed.
    • Make sure change control applies to test, development, or evaluation systems as well.
    • Track deployment of trial software from implementation, to retirement/decommissioning if the trial does not transition into a purchase.
    • Sometimes a complete reinstallation, or application of large updates, or repair of malfunctioning software can wind up resetting a logon back to a default password.  Again, change control can help ensure that a system is still in a secure state after an upgrade or repair.

Past Weekly Security Tips – WST