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] [thread-next>] [day] [month] [year] [list]
From: security at brvenik.com (Jason)
Subject: DCOM RPC exploit  (dcom.c)

Paul Schmehl wrote:

> On Sun, 2003-07-27 at 21:03, Jason wrote:
> 
>
>>Are there policies governing the use of computers on campus networks?
>>
> 
> There are at UTD, and I know there are at many other campuses.  And
> they're publicly posted and routinely taught.  But again, this isn't
> about me or UTD.  It's about admins in general.
> 

"In real life IT is almost always understaffed and overworked - and then 
we have to suffer the "experts" telling us what a lousy job we're doing 
and how much better off we'd be if we'd simply hire them - at 
outrageously inflated consulting fees - to fix our problems. "

Apologies for my interpreting your words to mean that you were an "admin 
in general". I mistakenly thought you were representing yourself and 
your views as an "admin in general".

Are you instead, by virtue of the title "Adjunct Information Security 
Officer", a member of the "security community" that is "a lot more eager 
to publish exploits than they are to publish fixes"

> 
>>You can shove it down their throats, and you can enforce it. This is not 
>>easy and it is not trivial but it is your responsibility as a 
>>professional.
> 
> 
> You shove something down the throat of vice president, a dean or a
> tenured professor and you'll be joining others in the unemployment
> line.  I tend to think the same would be true for the executives of any
> corporation as well.  And I submit to you that shoving things down the
> users throats is grossly _un_professional.

To quote Nathan. That is a "pretty fucking corner-case" that you deal 
with outside of the policy.

I do not agree with the complete statement he made I just think the 
quote works well to illustrate how the professional deals with the problem.

> 
> The job of IT is to support the mission of the organization, *not* to
> shove things down people's throats.  Rather than force people into a
> preconceived mold, our job is to try to find innovative solutions that
> allow them to do their work in a secure manner.  A completely secure
> environment that disallows research is completely useless to a
> university.

No reasearch gets done when the systems go down because thay were not 
secured according to industry best practices. Seems to me this has been 
achieved everywhere but IT. How many biological research labs that deal 
with infectios disease or deadly virii complain about having to follow 
policy and procedure?

>>** It has to start somewhere, get on the train and help out instead of 
>>complaining that it cannot be done. **
>>
> 
> I have not once said that it can't be done.  I have stated repeatedly
> that it isn't as trivial as you (and some others) seem to think it is.
> 

"Great!  Now go click all 5000 computers we have to take care of.  This
is exactly what I'm talking about... or require scripting expertise that
most don't have."

"If I had millions of dollars, I could put all sorts of "security
solutions" in place.  I have yet to find one that is reasonably priced"

Sounds like you believe it can't be done. At least you imply that it 
can't be done without millions of dollars. I think it has been 
illustrated that it can be done, not perfectly mind you, but in this 
case it could have been done without millions of dollars and without 
"scripting expertise".

[snip - more he said she said]
> 
>>One approach, there are many mind you, might be to identify the RPC call 
>>in question and then look for the existence of one of the valid return 
>>addresses within the payload. Do I have to provide that too?
>>
> 
> Now you're going to teach me IDS?  When you don't even understand it
> yourself?  First, I'm not worried about outside RPC attacks.  We have a
> default deny policy at the edge and have blocked all Windows and Unix
> networking ports (including RPC) for some time now.  Second, there's
> already a snort sig for this, so I don't need you to provide one.
> 

I love this quoting bit, it is fun. All quotes used belong to Paul 
unless otherwise stated.

"Are you really serious?  Recall Slammer?  There were networks that were
locked down pretty tight.  Slammer couldn't get in, right?"

So you use IDS to _protect_ your internal systems from VPN users?

What sig would you be using?

Did it get produced by one of those members of the "security community" 
so eager to publish exploits and not fixes?

> 
>>Read your posts and show me how you have once contributed something of 
>>value to the issue. All I have seen is flawed opinion and a weak defense 
>>of a flawed position. I am asking you and all that think like you to 
>>contribute to the solution with something productive or sit back and 
>>read the list so others can.
>>
> 
> You don't think I've contributed.  Others do.  That's life.

I will give you that. You have contributed to educating the people who 
used to think it could not be done and educating the people who recently 
became aware of security who had no idea it could be done.

Thank you for your time. It has been fun but I must go now and charge 
some outrageous consulting fees... to teach...

[ snip rest ]



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ