Thoughts on Security

This past weekend I gave a talk at BSides San Antonio titled "Pigs Don't Fly - Why owning a typical network is so easy, and how to build a secure one." I took a top-down look at the security barriers in a typical organizational network, the many techniques attackers use to break them, and how to build networks and hosts that were not vulnerable by doing a few things almost nobody does that will break the attack playbook.

First, a good understanding of how attackers actually break security barriers is necessary. I broke down the different levels of access into the following order: local user, local admin, lateral movement, and domain admin, along with internal network and internal server. To obtain any new level of access requires breaking a security barrier, provides a higher privilege level, and provides higher levels of access to critical data and systems; the objective for attackers.

The following graph summarizes the playbook to gain and escalate privileges on a primarily Windows network, the most common of which are in bold:

I went over these in greater detail in the talk, but I want to concentrate on how to stop them for this blog post.

Just as critical as access methods for attackers are methods of delivering attacks and getting data into and out of a network without being caught. A wide variety of control and data exfiltration methods have been used, and can basically be summarized as any way your systems and users can communicate with the outside world, attackers can use as well.

So how can you stop this from happening? By doing the following:

1. Isolate your network. The gold standard is to air-gap your network from the internet, disable the USB driver, and enforce strong physical security.

Failing that, block direct communication out from all your workstations and servers via firewalls, forcing the use of proxies that whitelist every aspect of communication you can:


2. Never use passwords.

Despite the fact that they are the easiest to implement and therefore default authentication method for everything, passwords should be considered pure evil on your network. They can only provide a false sense of security, and they break down about 1000 different ways:

• Your admins will leave them lying around in scripts and shared drives that attackers will find.
• They will be dumped from memory by mimikatz and similar tools.
• They will be keylogged.
• They will be guessed since your users will choose predictable passwords.
• They will be forgotten by users and then made easy to reset by an attacker.
• Users and admins will save them in password documents since they can't remember them.
• When anyone clicks a phishing link, they won't inspect the URL and will enter their passwords into a page that looks like a real login or give them up to someone who sounds like tech support on the phone.
• Everyone will re-use them so that anyone who finds the next RockYou password dump posted to pastebin or compromises a user's home computer and gets their Facebook password will also have access to your network. It is easy to ignore this vector, since your pentesters will never hack your users' home computers, but real attackers do not care.
• If an attacker can see the network traffic of a user authenticating, which can be done by a simple website with NTLM authentication, that challenge-response authentication can be cracked offline at high speed.
• An attacker without any access to your network can cause great pain and suffering locking out all your accounts by entering invalid credentials. If that is not the case, the attacker will be able to attempt high-speed online brute force password guessing and compromise many accounts. You can't win.
• Passwords provide a huge window of exposure, as whenever compromised, they can be abused forever, or at least for months until the next forced password change.
• But worst of all, their hashes will be stored en mass and can be re-used just like passwords. If an attacker can get some level of admin privileges for just a moment, he will dump every hash database he can get access to. He will then be able to impersonate any of those users whenever he wants to by passing the hash, spreading across your network and owning all your systems and data.


Passwords are pretty much the devil


All of these problems with passwords can be solved with the following rules:
• Force smart card logon for all users and admins
• Force Kerberos by denying all incoming NTLM
• Deny network and RDP logon to any non-smart card accounts

If these suggestions are implemented, they will solve the above problems. They will completely prevent passing-the-hash; hashes will never be used. There will be no hash/private credential database to steal in bulk. Private keys remain in the smart card and cannot be keylogged or stolen out of memory. Users cannot re-use or choose weak passwords that can be cracked, guessed, or bruteforced, and users cannot give them up to social engineers over the telephone or web. Admins cannot leave passwords in shared drives or scripts. It's easier on users’ memory. Only active logons can be hijacked, only temporarily (tickets are only good for up to 10 hours), and only by attackers with SYSTEM-level access on a system that your administrators log into interactively. Credential exposure is dramatically smaller, and by isolating your admins' workstations and using remote management tools that do not leave reusable credentials on remotely managed systems, it can be effectively mitigated. As an added bonus, NTLM relaying will also not be possible.

3. Whitelist all executable code.

Don't allow any code to run unless you or someone you trust has approved it. Whitelist all executables, and lock down scripts, like powershell, vbs, and bat files. This breaks the persistence mechanisms of every public attack toolkit out there, as well as most methods of lateral movement, etc.

4. Use strong exploit mitigations.

Force full mandatory DEP (AlwaysOn) and full mandatory ASLR on all modules via the registry. This can break things, but it will also break most memory corruption exploits. EMET can add additional mitigations, and other attacks can be mitigated by disabling vulnerable addons, like Java.

5. VM-isolate target applications.

Stronger than exploit mitigations is putting your applications that are likely to be attacked, such as document editors and viewers and browsers, into a VM sandbox. You can do this with some commercial products, or by rolling your own with seamless desktop integration and desktop VM software.

6. Don't use file shares.

Windows shares and shared drives are basically a hacker's dream. They were designed long ago with apparently little concern for security, and hackers will easily use them to spread to different systems and escalate privileges:

• Executable planting: Literally anything you double-click on a shared drive could be an executable with the name and icon of a document or folder and will give attackers access to your system.
• Shortcut hijacking: Any shortcut file can spawn a full command line, not only opening whatever program or document you intend, but also spawning a malware executable or script that will infect your system. So any shortcut you can edit on a shared drive is a method to infect anyone who clicks on it.
• DLL preloading: Even if you show file extensions and verify you are double-clicking on a legitimate file, many if not most applications use insecure library loading and will execute code in a DLL that just happens to have the right name.
• Script infecting: Any script that is run from a shared drive could be infected by a user with write access, owning every system it is run on.

So what can you do about this? Don't use shared drives as a way for your users to share files. Instead use a web content management system (CMS) such as WordPress, Joomla, SharePoint, or MediaWiki. In contrast with accessing shared drives, accessing a CMS is like accessing a website; your computer is not designed to trust it, won't automatically load DLL's from it, and your browser will clearly show you what file type you are downloading and warn you before you run something you don't intend to.

Having said that, shared drives that only admins can write to are still OK, and network drives that only one user can access, such as home drives are also still OK, since they do not introduce holes in any security barrier.

So go forth and build secure networks. Put in a little extra work up front, and don't fall for the easy defaults; you will regret it in the end.