Security Without Patches

Wednesday, October 12, 2011

Gabriel Bassett

C70bb5cfd0305c9d18312d92f820c321

Let’s discuss something a bit awkward:  Not Patching.

As security professionals, the first assessment of a security problem is that it is either due to a mistake in the code, a mistake in the config, a mistake in the RFC, or a mistake in the user.  Either way, the code/config needs to be fixed to fix the mistake, (because we certainly won't fix the user).

However, as auditors, we assess risks.  Every time we recommend a risk be mitigated by patching we are recommending our customers fight the security battle on the bad guy’s turf.

As Dusko Pavlovic points out in Gaming security by obscurity, the Fortification Principle implies that defense is at an inherent disadvantage when trying to use patches as our mitigation.

So instead, I propose something profound:  Secure your network without patching.  I don’t mean to never patch, but plan to only apply security patches, (and possibly configuration changes), as part of a regular deployment cycle.

In my last blog, I suggested establishing a context for the risk using a narrative.  Using the steps outlined in the blog, a narrative of the likelihood of a typical SQLi might look something like:

  • Attacker wants to embarrass your company
  • Attacker downloads backtrack and watches a Youtube video to learn how to conduct SQLi
  • Attacker runs SQLi scanner against company website and discovers SQLi
  • Attacker enumerates tables
  • Attacker dumps user table
  • Attacker leaves website and posts contents to Pastebin

The consequence is the embarrassment of your company, risk to your customers who reuse passwords, required immediate mitigation, etc.

Now I want YOU to come up with a solution.  One rule:  YOU CANNOT PATCH THE SQLi.  The narrative provides a powerful tool for this. 

If every step is required for the attack to happen, then disrupting any step mitigates the risk.  Alternately, it may be worth letting the attack happen if the consequences can be mitigated.

-----STOP HERE AND COME UP WITH YOUR MITIGATION-----

Did you do it?  Good!  Post your favorite mitigations in the comments below.  Having trouble?  Consider some of these ideas:
  • Why does the attacker want to embarrass your company?  Can you prevent that?  Can you make responsible disclosure more appealing?
  • You have an idea how the attacker is training.  Train internal staff the same way and allow them to test your systems.  This way you find the issues before the attacker.  You may find it early enough that you can use your normal development cycle to patch before you’re attacked.
  • As Dusko points out, when your attacker interacts with you, you have a valuable chance to both collect information as well as pass them the information you want them to have.
    • Can you prevent scanning for SQLi?
    • Can you inject fake SQLi returns to their tool?
    • Can you redirect the SQLi?
    • Can you detect the SQLi attempt and block or degrade your level of service to the user conducting the scan?
    • Can you detect the success of the SQLi and use it as an alert to take action yourself?
    • Can you make the attacker mistrust the data he receives back? (What if many of the entries in the user table look like fake accounts.  Will the attacker be confident enough to publish them still?)
  • Again, look at the options for step three.  The attacker is interacting with you.  Use it to your advantage.
  • Writing your user table to port 80 should not be normal. Use that knowledge to your advantage.
    • How can you detect it?
    • How can you prevent it?
    • How can you provide the attacker fake information?
    • Can you make the attacker think they’ve received fake information?
    • What about including every single account created by spam bots in the attacker’s dump of the table?
  • Most attackers believe that once they’ve completed the attack, they’re home free.  Law Enforcement doesn’t.  Just because you’ve been hacked doesn’t mean you don’t still have a chance to mitigate the attack.  You potentially collected a lot of information about the person as they accessed your systems.  If you can make them aware you know who they are and the consequences of posting the information, they may think twice about doing it.  Alternately, you may be able to provide them a positive incentive not to release it.

As for the mitigating the consequences to your company, it’s worth considering what you lost.

  • What if the usernames were encrypted along with the passwords?  Would the attacker then have to decrypt them to make use of them?
  • What if the username/password were simply hashed together in the database instead of storing the clear-text username?
  • What if there were so many garbage records it would be clear to anyone downloading it that the work to filter out legitimate users wouldn’t be worth the trouble.
  • What about seeding your user table with every name in the Atlanta, GA phone book followed by @nsa.gov.  Will the attacker trust the user table then?

Some of the above ideas are good, some aren’t.  The ideas aren’t what matter.  What matters is that you took the time to look at the ENTIRE attack narrative, choose multiple mitigations, whether it be corporate policy, training for personnel, operational mitigations, technical solutions, or patching existing technology and weighed their pro’s and con’s.

By having multiple options, you can choose the one that costs you the least and costs the attacker the most.
Possibly Related Articles:
6996
Network->General
Information Security
Patching Patch Management Network Security Configuration hackers Mitigation Fortification Principle
Post Rating I Like this!
C6dd57cb9806eadc9f7915a90d91aa92
Tony Campbell Hi Gabriel,

Very interesting. An unknown vulnerability (to the system owner) is the same as an unpatched vulnerability from the point of view of it's exploitability. However, we are discussing software/system defects rather than architectural problems here, so you need to explain that as part of the design analysis.

Some exploits will be countered by the solution design while others certainly can only realisically be countered by patching, especially if the system is malfunctioning in terms of its security posture.

I think that what you say here, "What matters is that you took the time to look at the ENTIRE attack narrative," is the most important take away from this piece, but it's not a new concept, but it's more commonly followed during the solution architecture phase rather than the day to day running, operational phase. Attack trees are commonly used during this system architecture design phase by security architects to map the threats and vulnerabilitys at each level to the proposed technical solution, running through the same 'attack narrative' process you describe. Once the attack tree is complete, the security designer can build in the countermeasures, so contributing to the overall architectural security posture.

Patching doesn't really come into this part of the design phase as it's part of operational security management; it's something additional you need to do in order to further protect the system during day-to-day operation.

I agree that each security patch needs assessing for its impact to the system it's being rolled out to, but most systems are designed from the outset to accept the fact that patches need to be deployed (with products in the architecture for deploying such patches), so it would be an odd choice to decide not to patch but instead to change the design or architecture to mitigate.

My advice would always be to patch, patch and patch some more. The components that are broken or have systemic problems are the ones that attackers will always look to exploit. Patching those holes, stops that attack in its tracks.

Anyway, that's my two penny's worth.

Cheers for a good post.

Tony
1318580196
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.