Some steps to a secure environment. Most environments I encounter in my everyday job share many problems that makes it VERY difficult to secure them. They are complex, heterogenous, lack inventory, have a great number of dependencies, are decentralized etc.etc.
These are som steps to follow if you really want to create a secure environment. Consider the possibility to create a new parallell environment and migrate into it, it´s sometimes the only way if you really wants to succeed!
Steps to a secure IT-environment:
Standardise, centralize and modernize your environment.
-A Standardized and centralised environment is a lot easier to manage and monitor, therefore easier to secure. Modern hardware, operative systems and application are often more secure and easier to manage. A good time to initiate this project could be when you move to Windows Server 2008/Windows Vista platforms.
Segment and harden the perimeter. (Layer 3 is not enough!)
-Consider application aware inspcection and monitoring. Whitelisting wherever possible (As oppose to blacklisting). Segement the perimeter (Why should a compromized DNS-server on the DMZ be able to make direct connections to a Mail-server on the DMZ?)
Segment and harden the network layer
-Implement internal segementation and isolation. Why should an ordinary client be able to connect to back-end SQL-servers? (Most internal networks are not "trusted", think of it as internet, only expose front-end-services). Why should a client be able to connect directly to another client? (This is a vector for hacker-attacks and worms, enforce local firewall rules to prevent this) A combination of IPSEC, VLAN segementation/ Internal ISA-Server Segementation/ Local Firewalling can be used for network layer hardening
Role-base and harden servers, clients, services and applications
-If you rolebase Clients, servers, services and applications they will become easier to manage, harden, monitor and delegate administration to. Use hardening according to the corresponding security guides, Use local firewalls.
Enforce a restrictive software deployment&execution policy.
-Vulnareble or trojaned applications can lead to system compromize. Make sure that you only use quality applications in your environment. Use a centralized process so that you can keep inventory.
Patch everything!
-Since you are enforcing a good software deployment process it´s easy to implement a good patchmanagement process, wher you make sure that you are aple to patch/mitigate all known threats to your installed software. Remember that network appliances and similar also have software installed, Patch EVERYTHING!
Implement strong authentication on exposed services
- Easy-to-guess passwords, weak network authentication protocols etc. are common reasons for system/application compromize. PKI-based smartcards/OTP etc. are stronger alternatives to ordinary passwords. Legacy applications can be terminalized, virtualzed, proxified or tunneled in IPSEC/VPN to make use of stronger authentication.
Delegate administration and data access according to least privilege
-If an account gets compromized the attacker will be able to do everything that account has rights and permissions to do. Enforce least privileges everywhere, avoid unneccesary dependencies and remember that a users credentials are always exposed on the system he is logged on to.
Audit and monitor critical computers, users and services
-You want to know if your systems are attacked, you want to be able to analyse logs if a system has been compromized. Real-time logging to a non-dependant, secure system is always a good thing. (Separation of duties ensures that a hacker cannot alter logs)
Encrypt hard drives on exposed computers
-If a computer is ever left unattended and potentionally exposed to someone untrusted it should use strong harddrive encryption and be turned off at the time of exposure.
Educate users
-If the users practice restrictive interaction with untrusted websites, application, devices and people you will decrease the attack surface drastically.
Implement understandable and accessible policies and processes
-Almost nobody will read a 200 page it-security policy document that is not even possible to enforce in the real-world. Implement a easy to read policy that presents relevant information to easch role in the company, And limit the pages that every role gets to a minimum. (Mabe the receptionist needs 2 pages while the it-support guy needs 6 pages..)
Of cource there are more things that could be done, Consider this a simple "draft" Feel free to comment this post, we can all complete the list together. :)
aka
Why an exposed LM/NTLM Hash is comparable to a clear-text password
aka
Why a 127 character long password is not necessarily stronger than a 4 character long password
aka
Why generating LM/NTLM rainbow tables is a complete waste of time
aka
Passing-the-hash for direct authentication to remote systems
aka
Why one vulnerable system can compromise the entire Active directory forest
aka
One of the scariest Windows authentication hacks you ever saw.......
During a Microsoft MVP summit in Redmond I demonstrated some of the work done by my group (Truesec Security Team) to some fellow security MVPs.
I was asked to write a blog on one of the “hash injection”-demos I demonstrated, so here we go:
Conceptual:
This is the concept of injecting a compromized hash into a local session and then use the hash to authenticate to network resources. This method eliminates the need for password cracking in a windows environment.
Description of the demo below:
1. Hacker compromises one server/workstation using a remote/local exploit. (This is not demonstrated in this demo)
2. The hacker extracts logged on hashes and finds a logged on domain admin account hash
3. The hackers use the hash to log on to the domain controller
4. The hacker extracts all the hashes in the Active Directory database and can now impersonate any account in the domain.
Demonstration:
The starting point of this attack is that an attacker has control over at least one computer using for example a client/server-side exploit. (Since this demo is not about exploits I will leave that out in order to keep focus on the authentication attack)
To simulate a remote exploit, I´m simply using a psexec connection connecting to the compromised server:
In this first scenario I´m running a Truesec tool named Gsecdump to dump the logged on hashes. I can see that both a user from the hell-domain named marcus is logged on as well as a local account named service1.
My next step will be to use the domain-joined password hash to connect to the domain controller.
Before I do that I will try to connect to the domain controller without the hash to prove that I do not currently have credentials to access the domain controller:
I´m trying to set up a net use session and just as expected, my current credentials doesn´t allow me to mount the hard drive on the domain controller.
So, my approach would be to start a new session on our local attack-machine and inject the hash into that session:
The Msvctl tool is a Truesec internal tool that we use in this case to create something similar to a “runas”-session, but instead of using a username and a password we are simply injecting the hash.
The Truesec Msvctl tool will initiate a new cmd session in the context of the user marcus with the injected hash:
Now when we run the net use command again I´m allowed mounting the hard drive on the domain controller. This works since the Marcus account is a member of the Domain Admins group.
The natural finish would be to run the Gsecdump tool again and extract the password hashes from the entire active directory database:
This means that since we can extract all the password hashes we now can impersonate any account in the entire domain using the Msvctl tool.
Another thing that deserves to be mentioned is that the exact same method can be used to extract the local hashes stored in the SAM (Security Account Manager) database of a client or a server:
In my experience as a pen tester, most environments still use identical local administrative accounts and passwords between servers and clients. The effect of this is that I can use the local hashes from this computer and use it to gain full access to other servers or clients. This drastically increases the chance that I will be able to extract logged on hashes from any member of the Domain admins group since I will control a greater number of computers.
(In this demo I have deliberately left out a lot of info on what the Truesec-tools do exactly and we will not make the msvctl tool publicly available.)
Conclusion:
This attack proves that if one computer is fully compromised then the attacker can directly impersonate all the logged on accounts and the accounts stored in the local SAM database or Active Directory Database.
Other important things that needs to be mentioned:
PKI/Smartcards
The first natural reaction would be to think that PKI-based smart card logon would solve the problem. Even though I´m personally a big fan of PKI/Smartcard-based authentication it doesn’t prevent this attack.
The issue is that LM/NTLM can still be used for network logon event if the users are using smartcards to authenticate
(The security settings in Windows can´t force smart-card-based logon for network access, only interactive.)
The fact that passwords will be changed into long randomized passwords when you implement smartcard doesn´t change anything. The hash is still there and we are simply using that hash, not the password.
Using the same password for different users
It´s really easy to try the extracted hashed passwords for different user accounts. My experience from the field is that it´s very common that admins reuse passwords between service accounts, their regular user accounts and their administrative accounts. This means that the low privileged user account that we extract from the admins desktop often gives us control over important servers and sometimes even the entire domain.
The length of the password it not of importance in this scenario
In this scenario it doesn´t really matter if a password is a one character password or a complex 127 character password since we are only using the hash.
A simple security or registry setting is NOT all it takes to get rid of LM/NTLM hashes for network authentication
The highest setting (Even in Windows Vista) is “Network Security:LAN Manager Authentication Level=Sent NTLMv2 response only”.
If we could enforce Kerberos or native PKI/smartcard authentication for network authentication this could solve the problem. You can actually do this but it will require an IPSEC authentication implementation in the network.
The purpose of this post is to generate a discussion on potential countermeasures. I have many thoughts of my own on this topic, but before I post them I´m very interested in ideas from others.
Credits
This work is a team effort and the biggest credit should rightfully go to Johannes Gumbel for research and coding. Jonas Ländin for researching and testing. Hasain Ashakarti for his fantastic intelligence and support.
Guys, being in the same team as you in not only educating and stimulating, it´s also incredibly fun!
- Marcus Murray, Truesec Security Team
A post on countermeasures and my personal thoughts will be posted shortly.