Re: RWW Security was compromised.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Tony Su (TonySu_at_discussions.microsoft.com)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 13:37:06 -0800

Therion,
You are not alone in this concern, and I don't think you'll find too much
disagreement that this special Admin Account policy will likely need to be
modified.

But, that's the future.

What we can and should do today seems to be fairly obvious...

- Configure a password to a far higher standard than your usual Domain
Password Policy.
- Know that Length of password is the most important single factor in
determining the effective bit strength of the Password, although other
factors can contribute.
- Exceptions exist for all current Password Rules and primarily because the
existing settings Microsoft offers to set Password Policy is too crude and
simple.
- The "effective bit strength" and other concepts which relate mainly to
brute force cracking cannot be ignored but does not address the most
important threat head on, Dictionary attacks (and variants).
- Because of "The Administrator" account is subject to special issues, it
becomes imperative to monitor the number of consecutive password attempt
failures. Jeff's suggestion about scripting an alert is good. If the password
is <very> strong/random, then you have a bigger window for discovering and
recognizing serious attacks.

I'd also like to introduce what I believe is the concept of "Predictability"
and educating any person who is responsible for configuring a password.

http://msmvps.com/bradley/archive/2005/01/24/33789.aspx

Also, partly as a result of this incident and some other issues I will be
doing presentations to a number of local User Groups on my ideas regarding
the <Practical> use of Passwords and Constructing Passwords. It won't be
heavy on mathematics and probabilities and will be fairly short, but the
slides will be available for free download from my site sometime after
2/5/2005.

Tony
www.su-networking.com

"Therion" wrote:

> Susan et al,
>
> Before I begin, a bit of background: I am fairly new to the concept of
> Windows server security as my previous experience is Unix. Don't get me
> wrong, I have deployed many Windows servers over the years but the
> environments I have deployed in were Corporate Unix shops where all external
> facing equipment was Unix. Even in the Exchange situations I always
> deployed it internally (until recently) and used Sendmail based gateways. So
> it would be an accurate statement to say I have grown in this business with
> the idea that Windows is inherently insecure, but that is changing... I am
> now heavily focused on the SMB market with Server 2003 products being the
> primary solutions.
>
> Now that the resume is out of the way, I would like to get a better
> understanding of the security issue brought out here. The debate here
> unfortunately turned into arguing the primary "cause" for Larry's incident.
> As Susan and others have pointed out, the password was the weakest link. I
> will not argue that opinion. However I find myself both embarrassed and
> concerned in light of what this has made me realize. The fact the
> administrator account cannot be prevented from logging in from these
> external tools is to say the least disconcerting, but even worse is that I
> am trying to learn how to disable this and coming up empty handed.
>
> I understand the practice of renaming the default admin accounts and the
> complexity it adds to potential compromise. A routine both Unix and Windows
> admins should practice when feasible. I further understand the passphrase
> versus password debates and the importance of strengthening them being
> paramount. This may be a simple issue of what school of security you come
> from, but I still am finding it hard to understand why this account can not
> easily be removed from accessing external tools like RWW. If this were a
> capability, I know I would sleep better at night.
>
> The probability of brute forcing a box with a 10+ strong password is
> unlikely however it IS doable. The factors that I consider on this path is
> how long it would take. I have heard the arguments of how long it takes to
> brute force various length passwords with the computers of current. But I
> have to say that has little weight with me as I have "witnessed" the use of
> distributed processing for this purpose. So the question now takes a new
> twist, what services can an attacker get the most cycles with? SMTP Auth
> would be my gamble but form requests are right up there. With the average
> SBS deployment, this could be done over a weekend and easily go un-noticed.
>
> Now that I have rambled enough, let me be direct in my questions:
>
> 1) Am I crazy to be so concerned about the administrator account being
> accessible externally?
> 2) Should I just create monitoring scripts to assess this type thing in the
> logs? I would love to hear others that may be doing this.
> 3) Or am I totally off track and need to re-program my brain... I suspect I
> will get a few of these. :-)
>
> P.S. I am very excited and impressed with MS's security efforts as of late,
> so I am not bashing MS, rather trying to comprehend what I am dealing with.
>
> "Larry K" <tech@pcmavericks.com> wrote in message
> news:%23XduJhmAFHA.2568@TK2MSFTNGP11.phx.gbl...
> > One of our clients RWW was compromised over the weekend. Apparently
> > they(the
> > hack) setup a script to crack the password on the username: adminitrator
> > and
> > password. How do I know? I don't. What I do know is that there were around
> > 580 attempts to login as administrator via RWW and one worked! So the
> > password wasn't so good. It had 7 characters and numbers uppercase and
> > lower. They accessed an application server and logged into 4 other
> > accounts.
> > I'm at a loss with this one. RWW doesn't lock anyone out after failed
> > attempts. Is there a way to lock down RWW?
> >
> > Larry K
> >
> >
>
>
>

Relevant Pages