Penetration Testing mailing list archives
Re: Insecure Security Technologies
From: "Adriel T. Desautels" <ad_lists () netragard com>
Date: Thu, 25 Dec 2008 15:58:26 -0500
Nice response man!And yes, I agree there is an issue here thats very much like being stuck between an unstoppable force and an immovable object. But how do we arm consumers in such a way that they can pull them selves out of that position before they get squished?
So the problem is that people rely on security experts and on security technology to defend their infrastructures. Most of the experts and most of the technology aren't really that great at what they do or don't work as advertised. How do we enable the consumer to be able to identify the tools and providers that do work as advertised? Perhaps we put some sort of a blog in place that does a formal review of both and rates the quality and capability of both?
Another example, soon to be a post on my blog (short version). The other day our team was delivering an Advanced External Penetration Test. During that test we didn't find a single system that was outdated with respect to patch levels. Never the less, we did find a way in via Social Engineering. Once we managed to get in we identified a patch management system that also did some good Policy Enforcement. When we arp-poisoned the network we noticed that this particular solution had agents communicating to a server in the clear using MS-SQL. So then we did the obvious, we use a MITM attack and forced the patch management system to help us penetrate the targets using the solution (all of them).
So, in that case the solution did do what it was supposed to do. It kept everything up to date, but it didn't do it in a secure way. That solution was out key to the entire network... needless to say the customer was shocked but happy that we found it.
If they had someone to evaluate the technology from a security perspective then maybe they could have avoided it. What do you think?
On Dec 24, 2008, at 5:37 PM, Dotzero wrote:
Interesting post Adriel.....but not particularly surprising. In fact, I find this type of scenario more common than not. Not too long ago I came across an appliance where the admin interface (web) can be forced to fall back to SSL2 from SSL3. Fortunately I know someone at the company and they responded quickly in addressing it. In other cases the response has not been so good. You recommend that the customer get a third party to evaluate the software/appliance but the previous post you asked to have discussed here points out all the fake security experts out there. What's a poor body on the client side supposed to do? <G> The overall gist you are communicating to me (and likely others) is that there is an awful lot of insecurity out there. Details at 11? Very few organizations are going to be able to afford third party evaluations specifically on their behalf every time they purchase software, appliances or even hardware. Hardware you ask? Yep.... a few years back I found a bug in an ASIC in a network device. I'd love to claim that I found it based on something other than accident. I was investigating an interesting behavior in the device out of curioisity. Speaking from the client side, I'm going to beat the heck out of an eval unit (or software), I'm going to read the reviews and comments of others, ask for independent reports from a third party, and lastly I'm going to ask about the vendors liability insurance. I am highly unlikely to contract with a third party to test it specifically for my organization. The juice aint worth the squeeze. Just a few thoughts.
Adriel T. Desautels ad_lists () netragard com -------------------------------------- Subscribe to our blog http://snosoft.blogspot.com ------------------------------------------------------------------------ This list is sponsored by: Cenzic Security Trends Report from Cenzic Stay Ahead of the Hacker Curve! Get the latest Q2 2008 Trends Report now www.cenzic.com/landing/trends-report ------------------------------------------------------------------------
Current thread:
- Re: Insecure Security Technologies, (continued)
- Re: Insecure Security Technologies M.B.Jr. (Dec 24)
- Re: Insecure Security Technologies Adriel T. Desautels (Dec 24)
- Re: Insecure Security Technologies M.B.Jr. (Dec 24)
- RE: Insecure Security Technologies Shenk, Jerry A (Dec 24)
- RE: Insecure Security Technologies Erin Carroll (Dec 24)
- RE: Insecure Security Technologies Shenk, Jerry A (Dec 24)
- Re: Insecure Security Technologies Adriel T. Desautels (Dec 24)
- Re: Insecure Security Technologies Adriel T. Desautels (Dec 24)
- Re: Insecure Security Technologies M.B.Jr. (Dec 24)
- Message not available
- Re: Insecure Security Technologies M.B.Jr. (Dec 24)
- Message not available
- Re: Insecure Security Technologies Adriel T. Desautels (Dec 24)
- Re: Insecure Security Technologies Adriel T. Desautels (Dec 27)
- Re: Insecure Security Technologies Micheal Cottingham (Dec 27)