Message-ID: <BAY8-F70YsB0iWggQYl000879cb@hotmail.com>
From: trowelfaz at hotmail.com (Trowel Faz)
Subject: 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/

Powered by blists - more mailing lists