Re: Very good break in

From: news.microsoft.com (eric.elliott@stanford.edu)
Date: 03/13/03 

From: "news.microsoft.com" <eric.elliott@stanford.edu>
Date: Thu, 13 Mar 2003 13:32:14 -0800

IIS is not running on this machine. I'd have mentioned that. Also, all
netBIOS ports are blocked at the edge.

Also, there was no serv-u installed. this thing was scanning ports over
port 445. it was sending the results to another 2000 host outside of
stanford's network. as one was found to be vulnerable, a different machine
would telnet and break in.

As regards the intial break-in, i may or may not be able to get the firewall
logs. i'm trying. of course there are no iis logs. Since this thiinng is
authenticating using LM, it's quite likely that something along the lines of
a red button attack would do the trick. All of a sudden, they were in as
system.

If you're interested i have some traces of network traffic showing the port
scanning this server was doing as well as the telnet traffic and reporting
of scans.
"Karl Levinson [x y] mvp" <levinson_k@excite.com> wrote in message
news:ugM3RRa6CHA.1740@TK2MSFTNGP12.phx.gbl...
> Well, you've provided a much more detailed log and analysis of this than
> I've ever seen, and it was very interesting... but this is one of the most
> common hacks on the internet right now: installing Serv-U FTP server onto
a
> windows computer and using it as an FTP share for illicit files.
>
> What's missing here is what vulnerability was used for the intial remote
> code execution e.g. the call to CMD.EXE. The first action in the logs was
> installing Fport.exe onto your computer, but this was of course AFTER the
> computer was already compromised and wasn't really the start of the
> compromise. The most common points of entry are probably an unpatched or
> misconfigured IIS www service [you would possibly see these in the IIS
logs,
> unless a buffer overflow exploit was used] or possibly just simply using
> standard Windows GUI tools and Windows Resource Kit type tools to remotely
> manage a computer through NetBIOS or through TCP 445.
>
> Firewall logs would also help determine which ports were used and by which
> IP address. Without this information, you've got no way to trace who did
> the attack or warn the person upstream from you that their computer has
been
> compromised.
>
> I would hazard to say that there are a few vulnerabilities here that
should
> be closed: first, no firewall blocking NetBIOS [a BIG no no] and it would
> seem that outbound portscans to other networks were also not being blocked
> by anything [blocking outbound access using a firewall is also important].
> Additionally, I would guess that IIS web services are running. As you may
> know, just installing patches is not enough to secure a computer...
deleting
> insecure files, disabling unnecessary services, changing insecure default
> configuration settings, using third party software to improve security and
> monitoring for changes are all good things to do. URLScan from
> www.microsoft.com/technet/security installed on the IIS web service [if
the
> service must be left enabled] is also helpful.
>
> Here is some information that might help you learn more about the attack
and
> also start securing a computer:
>
> http://securityadmin.info/faq.htm#hacked
> http://securityadmin.info/faq.htm#iislogs2
> http://securityadmin.info/faq.htm#iislogs
> http://securityadmin.info/faq.htm#ftpfolder
> http://securityadmin.info/faq.htm#re-secure
> http://securityadmin.info/faq.htm#harden
>
>
> "news.microsoft.com" <eric.elliott@stanford.edu> wrote in message
> news:#lFDQpZ6CHA.2308@TK2MSFTNGP10.phx.gbl...
> > Here is a "timeline," if you will, form the security event logs of a
hack
> on
> > one of my servers. I'm interested in finding out if anyone can see if
> > anything jumps out and says, "You dumb*&^%, you should have...."
> >
> > To answer your first question,, this thing logs on mac's so LM is lcd.
> > Other than that, I believe its pretty well pacthed.
>
> > Attacker runs ntrights.exe - allows administrators to selectively grant
or
> > revoke local file system or registry rights.
> >
> > At approximately 4:00 Stanford Security notified me of port scanning
> traffic
> > on dynamics over port 445 (CIFS). Analysis of sniffer traffic indicates
> > results of port scans are being sent to 136.152.115.36. telnet session
> > originate from 161.58.176.139. Telnet sessions are an attempt to break
> into
> > system on stanford computers.
> >
> > This scenario could explain how dynamics was broken into in the first
> place.
> > A telnet session is used as a "proxy" to allow a host from outside
> > Stanford's network to use CIFS to gain rights to a computer.
> >
> >
> >
> >
>
>