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: <Pine.GSO.4.43.0301262208530.20350-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK
 PORT 1434!

On Sun, 26 Jan 2003, Schmehl, Paul L wrote:

> -----Original Message-----
> From: Ron DuFresne [mailto:dufresne@...ternet.com]
> Sent: Sunday, January 26, 2003 3:35 PM
> To: Schmehl, Paul L
> Cc: Matt Smith; Richard M. Smith; jasonc@...ence.org; Jay D. Dyson;
> Bugtraq; Full-Disclosure
> Subject: RE: [Full-Disclosure] RE: MS SQL WORM IS DESTROYING INTERNET
> BLOCK PORT 1434!
>
> On Sat, 25 Jan 2003, Schmehl, Paul L wrote:
> >
> >> Until you've walked a mile in the shoes of the admins having to deal
> >> with this, keep your smug self-righteous indignation to yourselves.
>
> >Admins of the boxes in question and more directly the network admins
> >are fully responsible.  But, perhaps the real issue here is this is
> >a rationale for more distinct perimiter boundries.  That and the fact
> >that foreknowledge of M$-SQL issues have been known since slapper at
> >the least and thus, these ports should have long been blocked or
> >'protected' on the perimiters.
>
> This simply shows your ignorance of the issues, Ron.  Port 1434 was not
> a normal port for SQL server *until* MSDE came out.  We obviously
> blocked 1433 long ago, as did almost every edu in the universe.  But
> 1434 was a recent "innovation" to make SQL server capable of running
> multiple instances on multiple ports.
>

Actually, no, it's not an 'innovatation' at all.  I think if you review
the slapper alerts and the common ports M$-SQL is known to play upon,
you'll find that 1434 is no new issue:

From: Dave Ahmad <da@...urityfocus.com>
Subject: Microsoft Security Bulletin MS02-039: Buffer Overruns in SQL
Server
    2000 Resolution Service Could Enable Code Execution (Q323875) (fwd)
Date: Wed, 24 Jul 2002 23:55:18 -0600 (MDT)
To: bugtraq@...urityfocus.com

-----BEGIN PGP SIGNED MESSAGE-----

- ----------------------------------------------------------------------
Title:      Buffer Overruns in SQL Server 2000 Resolution Service
            Could Enable Code Execution (Q323875)
Date:       24 July 2002
Software:   SQL Server 2000
Impact:     Three vulnerabilities, the most serious of which could
            enable an attacker to gain control over an affected
            SQL Server 2000 installation
Max Risk:   Critical
Bulletin:   MS02-039

Microsoft encourages customers to review the Security Bulletin at:
http://www.microsoft.com/technet/security/bulletin/MS02-039.asp.
- ----------------------------------------------------------------------

Issue:
======
SQL Server 2000 introduces the ability to host multiple instances of
SQL Server on a single physical machine. Each instance operates for
all intents and purposes as though it was a separate server. However,
the multiple instances cannot all use the standard SQL Server session
port (TCP 1433). While the default instance listens on TCP port 1433,
named instances listen on any port assigned to them. The SQL Server
Resolution Service, which operates on UDP port 1434, provides a way
for clients to query for the appropriate network endpoints to use for
a particular SQL Server instance.
...

Yet, your reply tends to add credence to some comments made in another
ongoing thread, sorry, I'm following too many to remember the exact poster
to quote directly, but, to paraphrase them, "admins tend to do just enough
on each successive worm/exploit to cover their butts at that time, rather
then really read the information available and act in a proactive manner.

As Charles Miller <cmiller@...tiche.org> pointed out earlier in this
discussion:

<quote>
6) It has no appreciable long-term benefit. Last year, it was Code Red
   and Nimda. Everyone patched their IIS servers. There was the Apache
   mod_ssl worm (to a lesser extent) that reminded everyone to patch
   their Apache servers. This year, there's Sapphire, and everyone patches
   their SQL Server boxes. Next vulnerability, next worm, even if it's in
   IIS, Apache or SQL Server again, will catch the _same_ people, _again_.

The solution isn't defensive worms. The solution lies in the recognition
(seldom expressed, lest we later regret it ourselves), that the failure
to patch a seven-month bug is NEGLIGENCE, the failure to firewall non-
essential open ports on network servers is NEGLIGENCE. In other matters,
the failure to implement egress filtering is negligence. We could
probably come up with a pretty good baseline of what is obvious systems
administration negligence when it comes to security.

Few worms exploit vulnerabilities that are new and unknown. Most exploit
those that have been known for months. That it is cheaper for negligent
administrators to wait until the worm hits, suffer a day of disruption
and then fix the problem du jour is simply unacceptable. The only
solution, however, is to somehow make it more expensive to be negligent
than it is to be diligent.
</quote>


> >Yet, even if you have an internal 'cloud' of systems, they have
> entrance
> >and exit points to and from your .edu network.  It might seem dramatic,
>
> >but closing the access/entrance points from those systems that have/had
>
> >been compromised would prhaps quickly resolve the issues in that .edu
> >domain you are charged with.
>
> Now you're being silly.  I'm certain that every edu in the world was
> rushing to close port 1434 yesterday.  But the horse was already out of
> the barn.
>

You misread me, the port<s> in question should have already been closed.
And infected systems just cutoff from your network until the admins or
users in charge of them fix the problem.


> >If the .edu domains policies do not allow
> >such 'extreme' measures of dealing with admins not up to snuff, then
> the
> >matter needs to be pushed up the chain of that domains 'management',
> >which of course starts with admins, in staff meetings, pushing their
> >teir one folks and managers to push for something higher in the feeding
> chain.
>
> And here, you display your ignorance of the edu environment.  The idea
> that an admin could close a port simply because he thought it was
> dangerous is laughable.  You have to go through committtees made up of
> students and faculty and convince them it's necessary.  Then you have to
> get the President's approval, and in the case of state schools, the
> approval of the Regents or Chancellors.
>

Then again, you misread and misinterpret my comments.  If your policy is
that lacking on giving those responsible for maintaining a secure network
envoironment for your .edu domain, then get those folks who are
responsible *organised* to start pressing the matter higher up, to those
Regents or Chancellors or whomever that can give those responsible the
power to do what needs to be done to not only be proactive, but to
properly react to abusive situations.


> >Whining that your hands are too full to do the job you are hired and
> paid
> >to do, while waiting for vendors to fix issues that they have a long
> record
> >of wanting to avoid dealing with, will get nothing accomplished.
>
> First of all, it's *not* my job.  Secondly, I wasn't whining.  Thirdly,
> you'd better hope and pray there are people like me in edu who care
> enough to fight for what's right security-wise, or there's no hope for
> the Internet.  (And I can assure you that there are a *lot* of people in
> edu who care very much and are working hard to change things.)
>

It's so common to hear the "it's *not* my job" retort.  The fact is,
you;re either part of the solution, or part of the problem, or dead
weight.

> As far as waiting for vendors to fix things goes, why do you think I've
> abandoned MS products at work and refuse to use them for any of my
> security related work?
>
> Blaming the admins for what happened is akin to prosecuting a woman for
> being raped.  Instead of going after the perpetrators who wrote and
> released the worm, you want to go after the admins whose networks were
> taken advantage of.  And you *assume* they were lazy, incompetent or any
> of the other perjoratives that make you feel better about yourself.
>

I never said the "perpetrators who wrote and released the worm" held no
responsibility here, and do not think I ever implied it.
Not at all.  Who is responsible for installing what is used and
potentially abused on those systems?  If it is not the job of the admin to
properly maintain and secure those systems under their control, then whose
job is it?  Whose responsibility is it?

> Try working in a large edu sometime and see how much change you can
> initiate.  It takes a tough person to stick it out and keep fighting.
> (I'm not tooting my own horn, but standing up for all edu admins
> everywhere.)  Some universities are *still* fighting to get the NetBIOS
> ports closed, for god's sake.  Do you think for one minute that *any*
> admin in his right mind would *willing* expose those ports to the
> Internet?  If not, then *why* on earth do you think they're still open?
> (Because the admins don't have the power to close them.)
>

<see above>

> It's *real* easy to criticize.  Especially when you work in an
> atmosphere you can completely control.  It's a lot tougher to find
> solutions to real problems in the real world and fight for change where
> it needs to occur.
>

When I've had issues with .edu users being abusive, or infested systems in
a .edu domain attacking my systems, and taken the time to contact those
tasked to deal with abuse complaints in those domains, I've never had a
problem getting ports blocked, or systems locked off those nets until the
admins involved could fix their borked systems.  But, you infer here that
at your .edu, I'd have troubles getting ahold of someone with that level
of responsibility and the power to deal with the matters in a timely
manner?

> Why not blame the networks that allow these jerks to release their
> worms, run their DDoS networks and do all the other crap they do?  Why
> is it still possible to host a website on the Internet that freely makes
> worms, viruses and exploit code available to the world?  (Yeah, I know,
> it's a freedom of speech issue, right?  Yeah, right!)
>

Damn folks want to be so amero-centric, often times it's nothing to do
with the bill of rights or anything related to the US constitution at all,
*sometimes* it is a jurisdictional issue that -=crosses=- international
boundries.


Thanks,


Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ