October 12, 2011 by
Security Without Patches
This was originally posted on blogger here.
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.(Cross posted from at https://www.infosecisland.com/blogview/17304-Security-Without-Patches.html)