Re: Yet another fascinating advisory!

[Daniele Muscetta <daniele () muscetta com>]

Dave Aitel wrote:

> For those of you who wern't at my BlackHat talk in Seattle, one of the 
> themes was that the management and monitoring software and other 
> enterprise-level software that people install is rarely looked at, and 
> highly vulnerable.


Indeed. I think is ot even the first time that you referred to Compaq 
Insight Manager as to a backdoor in the past and that kind of things.... 
I perfectly agree (like most security guys I suppose). Try to convince 
the "old-school"  sysadmins though....




> My suggestion during the talk was that you should write in your IT 
> aquisition contracts a phrase that requires a third party review from 
> a security company you trust before you purchase the software, at the 
> vendor's expense.


when companies buy something, they buy it for the functionality. They 
don't look at all at the security aspects of it. Sometimes it happens 
that the security department (or one-man-band rather than a department, 
like in my case) is not even notified that something is in the process 
of being acquired ! ...it happens several times that you find out some 
department went through the process of finding out a piece of software 
for themselves, without letting security know, but in most cases without 
letting any IT people know. That is, the high management has spoken to 
some salesman, who promised something.... and that's it. You have the 
product in the house. Now they even expect you to mantain it, and OF 
COURSE to make it secure ! Charming isn't it ? Still is the way it goes.




> I listed about 5 or 6 products (including Harbor) that will be having 
> advisories soon. But the point was not that "company X has bugs" it's 
> that every product you install on your gold build needs to be looked 
> at, and the ones that don't have a bugtraq thread five pages long on 
> them are the ones I, as a hacker, will look at first. Hacker's aren't 
> above breaking into one box on your network, and writing 0day for 
> everything on it to use to own every other box, without fear that some 
> IDS will catch them.

This sound pretty much logical to the hacker indeed.
People who make those gold build are usually even disappointed when the 
security guy gets in the way and has to include extra settings / patches 
/ etc .....



> There's a common practice of developing "gold builds" or "standard 
> builds" which you place throughout your enterprise, or use as a 
> desktop build. And I like to divide the things you do to generate a 
> gold build into three catagories:
> Catagory 1.  Software you can download off the internet: Often has 
> hardening guides you can download off the Internet. The NSA Windows 
> Hardening guides, for example, or various Solaris hardening scripts.

> Catagory 2. Software you own that few other people own: Rarely has any 
> good information available on the Internet related to configuration or 
> hardening guides. Often has not been looked at by the public security 
> community, and so has many "low hanging fruit"
> Catagory 3. Software you wrote: Obviously other than broad guidelines, 
> there is no specific documentation on how to harden your own 
> applications. There probably should be though - and a good CSO will 
> make sure that it gets produced and used before the application gets 
> put on the net.

This can hold true, but only assuming that the CSO is at the management 
level - so hopefully he has an overview of what goes on in the whole lot 
of the company, and can take dicision as to "make sure"....

In other companies, the Security Officer is just a "specialized"  system 
administrator..... this implies that:
1) he does not even always get notified IF something new gets taken into 
the company - he might be asked to give his opinion when buying a 
firewall or an IDS.... but if they are buying ANYTHING else they won't 
consider it a security issue, so not worth letting the security officer 
know in the first place - this includes the above mentioned management 
products, of course, but whatever else, really !!
2) he is not at a management level, so in the end he does not even have 
a foot to stand on and say that things should be done one way or 
another. He can give an advice, hoping people above him will listen;

About the second thing in particular: this is even worse than being a 
consultant. A consultant can give an advice, but if at the end of the 
day the customer company wants to do differently, it really is none of 
the consultant's business, nor he should worry for it.
For a Security Officer, this is only partially similar, and it might be 
more painful: he gives advices, and if his management does not follow 
his advice, he can't just carry on with it. When shit will happen it 
still will remain his problem. For it is 'his' system, his network. Or 
at least, the ones he's in charge of, and he's expected to care for.

So,  - just to make a silly example - if he advises "let's buy an 
antivirus" and they don't buy it, the first time his network is fucked 
up with a worm, he still will be the one to blame (for he was doing the 
securty wasn't he ?) !! ...and he still will have to clean the mess on 
his own !!!

In this, being a consultant is much more easier. At the end of the day, 
you told your advice, is up to the customer to follow it or not.
When it is about YOUR OWN network, you have to deal with things not just 
once to write a report about it, but costantly.
It takes much more patience, dedication, political skill, and it makes 
your hair go white :-)





> To  produce a gold build that is actually hardened, you need to go 
> beyond #1 (which is where most people are) and take some control of #2 
> and #3. This is rarely done, and I think a serious misstep by any 
> information security department who fails to do so. To get control of 
> 2 and 3, I recommend:

Unfortunately *most* people are NOT EVEN at step one. You are very 
optimistic about the possibilities of the human kind, indeed :-)




> Alternatively you can hire a company to do this at your own cost. Keep 
> in mind that without source code and access to developers, it's harder 
> to do a complete review, but that for this kind of software, a 
> complete review is rarely needed to find several major problems.
Indeed. this would be nice. assuming, again, that the security people 
are made aware that this new software has been taken in-house.....
Most of the times that software was already there, and hardening 
something after it has already been implemented and it is in production 
is much more pain (and much less effective usually) than just do it 
right at the beginning.

Some other times different departments just buy their own software 
without asking suggestions first, and then they pretend you to implement 
it AND to make it secure.
Companies are complex beasts.





> 2. Create business guideline for your gold build. I.E. When I look at 
> it, I need to see "why we have SNMP enabled" written somewhere. Then 
> when I review it, I can write "This is the risk you are running" and 
> you can check "ok" and be done with it, rather than having to revisit 
> it every time you do a review or derive a new Gold Build from it.
In many cases this already happens instead.
Even if you do a pen.test or any kind of audit, you find some things.
In some cases they might be incredible news for the customer, in some 
other cases he might already know about them. When he knows about them 
usually one of the folowing applies:
1) he's already trying to address them;
2) he knows the risk and wants to run it for some other reasons;
3) he knows the risk, and he would like to minimize it, but he CAN'T do 
it right now (for external factors).

It is like with SNMP in your example. I believe that most of the times 
the customer can tell you: "yes, I know I risk this and that, but I am 
willing to run that risk because I love SNMP (example!) and it lets me 
do this and that....".

What you mention is just lack of documentation, and documenting things 
is also something very boring (and also VERY important). .....not even 
WRITING docs is boring as much as MANTAINING them is.... as things are 
never static and they do change often ...... :-)

But in some cases these configuration guidelines do exist. 
They are mainly made with the intent of being able to re-make the same 
thing in the future, for disaster recovery, or just to leave somewhere a 
description of how things work.
Less often they also take into account the security aspects explicitly. 
But is at least a start when *some* documentation of how things are 
working is there.




> 3. Whatever everyone else on the list pipes in to say that makes sense.

Hope what I just wrote does (even if the original message was posted two 
weeks ago - and I replied only now !).
:-)


Regards,


Daniele



_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave