Thursday, September 27, 2012

Protecting your servers from your hosts

          It seems the phrase "hard exterior with a soft & chewy interior" is a phrase being bandied about pretty frequently these days in relation to the security of many enterprise networks. The gist of the phrase is that we often spend lots of time and money protecting ourselves from external attacks, thus creating a hard shell at the perimeter, but provide no defense on the interior of the network from attacks by devices already internal to the network.

          In many cases, there are no security controls protecting against a compromised host or a malicious insider attacking other hosts or servers. I have often been surprised at the lack of any ACLs limiting connections from hosts to servers. While clients have legitimate business needs to access resources on the server farm, limiting connections to only the required ports and from the required hosts can help narrow down the threat surface and prevent attacks.

          Firewalls or layer 3 switches/routers should be configured with access lists to eliminate unnecessary connections. Generally speaking, your average user does not need to make SQL connections to the database servers, SSH connections to Linux devices, or SMTP connections to pretty much anything, so these types of connections should be denied by default. Ideally, protocols such as SSH, RDP, or other forms of remote management that are necessary for system admins to perform their duties will be locked down to only the system admin's IP address. The use of "jump servers" can be a good choice when dealing with a large number of system administrators, because it allows for all remote admin connections to come from the same source address. While this certainly won't eliminate all attacks, if properly implemented and logged, it will give network defenders a better chance of discovering and hopefully preventing future malicious activity.

Stay tuned for a future post dealing with protecting clients workstations from each other!

Thursday, September 20, 2012

That IE O-day? Yeah, you're covered (kinda).

          On Monday, news of yet another 0-day exploit swept security circles. Leadership scrambled to throw together reports about their company's exposure level for presentation to their management chain. 

          The idea behind this particular 0-day, like many others, is to exploit the browser so that user interaction is not be required to download and execute a secondary payload. The primary payload is the script that orchestrates this activity. The secondary payload, in this case, is an executable (.exe) Trojan. Here is a visual attack chain for this exploit:

(thanks to for their analysis.)

          Your mitigation strategy? Software Restriction Policies (SRP) - it's a free tool provided by Microsoft that can be configured to prevent execution of code in unprotected, user writable directories. Following the attack chain above, everything is going as planned for the attacker until the command to execute 111.exe occurs. The executable file is located in the Internet Temporary Files which is a user writable directory; therefore, SRP prevents 111.exe from executing and the attack is thwarted. Furthermore, the attacker only has user-level privileges, post exploitation. Anywhere that is writable to the attacker is protected by SRP execution prevention policies.

          Now, keep in mind that exploitation still occurs above - SRP is not a catch all. The secondary payload is still delivered. However, the secondary payload is unable to execute because SRP is configured to prevent it. Because of SRP, this particular attack chain, alongside many other 0-day exploit attack chains released this year, is mitigated. 

Stay tuned for more about Microsoft's SRP.

Tuesday, September 18, 2012

Welcome to Secure The Interior.

          After 8 years in the cyber security industry - witnessing worms traverse seemingly "secure" networks and numerous Advanced Persistent Threat (APT) infections - one thing is clear: you will never stop a sufficiently motivated attacker from getting into your network. APT actors are compromising companies and governments that have made strenuous, focused, and expensive efforts to defend their networks.

          The trend 10 years ago was to beef up perimeter security and stop the malicious code from getting inside the soft-centered network. A few years later the idea was to install host-based intrusion prevention software on all clients - which represents a small step in the right direction. After that, the term "Defense in Depth" came about to explain a method of layering security products on both the network and host level with the hopes of detecting or preventing an adversarial attack. With these innovations, why, and, more importantly, how are networks still being infected? 

          This blog will speak to the question posed above and explain the importance of minimizing post-infection exposure while increasing detection capabilities at the host level. These two topics
 include a laundry list of best practices and configuration changes that can help keep your company out of the headlines, even when a compromise occurs. This blog is dedicated to my experiences and findings when it comes to securing the interior of any computer network, while occasionally pointing out weaknesses in important, but limited, perimeter defenses.