Re: Administrator Accounts

["David Lodge" <dave () cirt net>]

On Thu, 23 Feb 2006 01:09:13 -0000, Nick FitzGerald  
<nick () virus-l demon co uk> wrote:
> > "The ultimate goal is that every single application that we have
> > installed in our systems will run in user modes," Bradley said. "The
> > Microsoft applications do run in user mode. I cannot say that for the
> > rest of my stupid line-of-business applications. To get certified for
> > design for a Windows XP logo, you have to run as a user mode."
> Had corporates taken this "we actually really do care, maybe just a
> little though, about security" this problem would not exist _for
> "business use" software_ today.

As has been already stated because us security experts don't get a say in  
it until the application has been bought and the "you must install"  
command comes from high.

Sometimes the only reason I can think why some corporate applications are  
used is because somebody high up has shares in that company.

Also most IT people seem to be fundamentally lazy: everytime I see  
insecurity in applications I require that it is fed back to the  
developers. I get arguments from the IT people, arguments from the  
providing company, massive out of scale costs to amend their precious  
software - even when it makes the developers' lives *easier* ad nauseam.  
If I had a pound for every time I've heard "Our product is endorsed by the  
military/Mastercard/Visa/the Masons" I could retire!

The reason is that, even though we try to fight the good fight, it is  
still easier to write applications insecurely, test them insecurely and  
implement them insecurely. Meaning that the security folks appear to be  
the "bad guys". Microsoft is finally getting the message, Oracle may get  
there; but the "one product" vendors have a long way to go.

In the real world I've fought crap applications that:
* Use a password compiled in the executable to connect as DBA to an  
Oracle. When asked whether we could reduce the rights, the answer: "It's  
an untested solution and we can't support it".
* Are supplied as a "black box" (even though it's just W2K running IIS and  
SQL Server - insecurely) and are told that we have no rights to touch it  
or "it will break" and they "cannot see a point in doing that".
* In a pretense of security use a SQL Server application role (a totally  
pointless security 'feature') to restrict rights to the database, but then  
insist that the ODBC connection is done as 'sa'.
* In the above application, use a simple transposition cypher to 'encrypt'  
the passwords in the database (10 minutes on the back of a fag packet and  
we had worked out the algorithm).
* Have the audacity to attempt to charge 10's of thousand of pounds to  
allow their system to authenticate by LDAP (as if LDAP is a new  
technology).
* Deliberately avoid making life easy (e.g. having a complex log-in system  
for SQL Server, when they could just use the MS approved, simple, Windows  
authentication model) then complain that they can't allow password aging  
as it would be too difficult.
* Document in their support base that the administrator level account  
should have a password equal to the - easily guessable - username.

I have many many more examples. The conclusion - most corporate software  
really, really sucks and without a *drastic* change in how development  
shops deal with security it won't get better.

This has been your depressing rant for the day.

dave
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.