lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <200407271620.i6RGKpu07304@netsys.com>
From: dinis at ddplus.net (Dinis Cruz)
Subject: Security is not a technology, but instead attitude

Hello Trowel

I totally agree with you that (one of) the major problem(s) with security is
one of attitude and responsibility.

At the end of day these companies are business whose focus is on their
bottom line. Not on the security of their applications neither on the
security of their customers.

In my view the only solution for this problem is to make the end users (i.e.
the paying clients) aware of the (in)security level of the products and
services that they are buying and today implicitly trust.

When clients are aware, they do chose wisely and decisively. The problem is
that today there is no effective mechanism to let users (of websites and
applications) know about the level of security of their choices.

When such mechanism are created and developed, you will see a dramatic
improvement on the security of these applications because then, reactive
responses to security problems (as the ones you described in your post) will
be more expensive than ensuring that those problems are not there in the
first place.

I have told so many companies that they have security vulnerabilities in
their applications or websites, and barely any has told their clients about
it. 

It is so disgraceful and irresponsible that sometimes you just want to call
the editor of major IT magazine and expose them, but with the current laws
that we have (the "Computer Misuse Act" for example in the UK) one has to be
careful in publicly disclosing these vulnerabilities, because the first
thing that the affected companies will do is to report you to the police!
(It's funny that nobody seems to be worried about the affected clients whose
data, reputation and identity is at risk)

In my view the best thing the people that are really worried in improving
the security of today's (and tomorrow's) digital world can do, is to work on
the development of tools, standards and laws that 'show' in a easy, quick,
authoritative and effective way the level of security of websites, software
applications and hardware firmware.

I cannot finish this post without saying that this list (full-disclosure) is
already a huge step in the right direction (even with all the 'healthy
noise' and off-topic discussions).

Best regards

Dinis Cruz
.Net Security Consultant
DDPlus

> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com [mailto:full-disclosure-
> admin@...ts.netsys.com] On Behalf Of Trowel Faz
> Sent: 22 July 2004 16:51
> To: full-disclosure@...ts.netsys.com
> Subject: [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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ