[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Full-Disclosure] Security is not a technology, but instead attitude



This is sort of a rant. Companies believe there is a 'black box' that will secure them. We all know this to be false. Besides all the buggy code, unsafe operating practices and the like, one of the biggest issues is from the attitude of the companies themselves. Recently, I experienced this first hand in case seperate cases:
1) Emailed major vendor about a flaw in the operation of one of their patches that will render a vulnerable service back to life to be exploited. After their verification this can happen, I received a FU type of response:
"At this point I don't see any further actions I can take on this issue.
I do not want to update the KB with text along the lines of 'And it is
possible to restart the service as an admin by clicking a link' since
that would allow attackers an easy pointer to a bug, even though all
known attack vectors are blocked."


So, even though all current *known* attacked vectors are blocked, a service can still be restarted unknowningly by the user and exploited with *unknown* attacks (or at least unknown to the vendor). If I set something to disabled, it should stay in that state unless I explicitly enable it. Yes, one could delete the offending files, but given the OS involved, it *will* reappear sometime later.

The second case involves a vendor who offers commerce transactions to a very large community worldwide. Their main login screen is not SSL wrapped, but there is a tiny link near the bottom that allows for SSL logins. This service is used by *many* non-technical people, most of who probably don't even notice the SSL link for an alternate login page. So, when the user logs into their account, their login/password are transmitted in clear text for easy sniffing or recording in web proxies or on the vendors web site itself. Now mind you, many of the users of this service probably also have the same login/password for their ecommerce access, which is tied directly to their credit cards and bank info (which, by the way, the vendor has a vested interest in). Their response? "There is an alternate link for using an encrypted login if you wish". Why not make that the default?

In case 1, then vendor acknowledged there is still a bug, but doesn't want it to get out, and wants to do nothing to address it. When there is a working exploit for it, they will fix it. This is reactionary mode. Don't do anything unless something bad happens, then only fix that part instead of fixing the problem as a whole.

In case 2, then vendor has their get-out-of-jail card handy since 'there IS a way for encrypted login, but it is not default'. This ignorance costs not only the vendor, but the banks and users involved hard cash. Sure, someone who is hit by a compromised account may be able to get some of their money refunded, but the perp probably got away with it AND the user now has the possibility of their other personal information leaking out to who knows where all because a vendor did not act responibly in the first place. And this vendor has other 'security' in place to ensure you have to authenticate if you wish to look up some 'marked public' info for other users. Why bother? Simply sniff their credentials off the wire and have fun!

All in all, the real security threat is from attitude. Attitude for not addressing problems that are reported. Attitude from releasing poorly coded applications just to meet a deadline. Attitude from failing to take the basic precautions for doing business on the Internet.

_________________________________________________________________
Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html