Our 2000 Server was compromised and it has all the security patches.

A client of mine has a Windows 2000 Server running that
was just compromised. Housecall (online scan) identified
HKTL_SFIND.A / BKDR_RCSERV.C & BKDR_IROFFER12.A as
actively running.

After brief review it appears as though hacker utilities
such as serv-u ftp, sms.exe, scan1000.exe, winmgmt.exe,
sqlck.exe etc. were loaded and used for their benefit.

We have/had the following services running that could
have been exploited: SQL std. port, Terminal services
admin mode, and inetpub svcs. I checked just to see if
there were new updates to windows etc. and there are not
any. This concerns me because we have other servers
running with the same configurations with all the
patches/updates etc which leads me to believe they are
also vulnerable.

If anyone has any information as to who to contact, who
to provide information to about new exloits, how our
system may have been exploited etc please let me know.
We are preserving the hard drive for inspection if
necessary because we feel the system was compromised
beyond repair. Several system files look like they were
replaced with the hackers version and thats just from a
log file, there is no way to be sure. Also, the
scan1000.exe tools output was piped to a log file and
they were scanning for port 1433 on random ranges of IP's
(not ours) which leads me to believe that they probably
came in through SQL port if they are trying to find more.

This may be a new SQL exploit. I ran this SELECT
SERVERPROPERTY('productversion'), SERVERPROPERTY
('productlevel'), SERVERPROPERTY ('edition') and this is
what was retuned fyi: 8.00.760 / SP3 / Std. Edition

Thanks,
Scott

Ozgirl
Tue Nov 25 20:20:10 CST 2003


"Scott Carullo" <scott@softtech.net> wrote in message
news:08d901c3b3b9$3d4fd6b0$a101280a@phx.gbl...
> A client of mine has a Windows 2000 Server running
that
> was just compromised. Housecall (online scan)
identified
> HKTL_SFIND.A / BKDR_RCSERV.C & BKDR_IROFFER12.A as
> actively running.

Sounds like someone has been using IRC and allowed the
program to act as a server.
You leave a hole to let one in ......

Chris
Wed Nov 26 01:12:24 CST 2003

I do not exactly know how your SQL server is configured, but I guess it
won't have the default "sa" account enabled with no password, or if the
password is not strong, the password could be enumerated by some freeware
tools.

On the other hand you stated that you have also running Inetserv. Is there a
webpage running on the machine which interacts with the SQl database? The
hackers could have made use of "SQL-injection" techniques to elevate
priviliges on the system.

Kind regards,

Chris


"Scott Carullo" <scott@softtech.net> wrote in message
news:08d901c3b3b9$3d4fd6b0$a101280a@phx.gbl...
> A client of mine has a Windows 2000 Server running that
> was just compromised. Housecall (online scan) identified
> HKTL_SFIND.A / BKDR_RCSERV.C & BKDR_IROFFER12.A as
> actively running.
>
> After brief review it appears as though hacker utilities
> such as serv-u ftp, sms.exe, scan1000.exe, winmgmt.exe,
> sqlck.exe etc. were loaded and used for their benefit.
>
> We have/had the following services running that could
> have been exploited: SQL std. port, Terminal services
> admin mode, and inetpub svcs. I checked just to see if
> there were new updates to windows etc. and there are not
> any. This concerns me because we have other servers
> running with the same configurations with all the
> patches/updates etc which leads me to believe they are
> also vulnerable.
>
> If anyone has any information as to who to contact, who
> to provide information to about new exloits, how our
> system may have been exploited etc please let me know.
> We are preserving the hard drive for inspection if
> necessary because we feel the system was compromised
> beyond repair. Several system files look like they were
> replaced with the hackers version and thats just from a
> log file, there is no way to be sure. Also, the
> scan1000.exe tools output was piped to a log file and
> they were scanning for port 1433 on random ranges of IP's
> (not ours) which leads me to believe that they probably
> came in through SQL port if they are trying to find more.
>
> This may be a new SQL exploit. I ran this SELECT
> SERVERPROPERTY('productversion'), SERVERPROPERTY
> ('productlevel'), SERVERPROPERTY ('edition') and this is
> what was retuned fyi: 8.00.760 / SP3 / Std. Edition
>
> Thanks,
> Scott

Karl
Wed Nov 26 05:22:34 CST 2003

I doubt that this is a new exploit. It's probably an old one.

Why the heck is 1433 open at your firewall anyways? Is that necessary? Why
is your sql server able to send anything out to the Internet on any port?
Is everything being allowed outbound on every port? Might want to check
whether your firewall is configured as securely as possible.

In the US, local police and/or local FBI office might be interested if this
is a company, although they often require proof of at least $2000 US in
actual losses before handling a case, due to the frequency of this kind of
attack. If that sounds unattractive or not feasible, investigate it
yourself using the information below and/or posting to the Incidents mailing
list at www.securityfocus.com It may be helpful if you post the results of
the stuff run below when posting there:

http://securityadmin.info/faq.asp#hacked
http://securityadmin.info/faq.asp#re-secure
http://securityadmin.info/faq.asp#harden

You might run hfnetchk or Microsoft's free MBSA in hfnetchk mode to check
for patches that weren't successfully installed. It happens. If you haven't
already removed the files, inspection of where the connections to the server
are coming from might establish who hacked it and maybe even how. Not sure
these are related to your hack, but as a general rule you should make sure
you're running URLScan from Microsoft on your web server, if it's running,
and make sure the anonymous ftp user e.g. IUSR never has both read and write
permissions to any one FTP folder, if the server had MS FTP services
enabled.


"Scott Carullo" <scott@softtech.net> wrote in message
news:08d901c3b3b9$3d4fd6b0$a101280a@phx.gbl...
> A client of mine has a Windows 2000 Server running that
> was just compromised. Housecall (online scan) identified
> HKTL_SFIND.A / BKDR_RCSERV.C & BKDR_IROFFER12.A as
> actively running.
>
> After brief review it appears as though hacker utilities
> such as serv-u ftp, sms.exe, scan1000.exe, winmgmt.exe,
> sqlck.exe etc. were loaded and used for their benefit.
>
> We have/had the following services running that could
> have been exploited: SQL std. port, Terminal services
> admin mode, and inetpub svcs. I checked just to see if
> there were new updates to windows etc. and there are not
> any. This concerns me because we have other servers
> running with the same configurations with all the
> patches/updates etc which leads me to believe they are
> also vulnerable.
>
> If anyone has any information as to who to contact, who
> to provide information to about new exloits, how our
> system may have been exploited etc please let me know.
> We are preserving the hard drive for inspection if
> necessary because we feel the system was compromised
> beyond repair. Several system files look like they were
> replaced with the hackers version and thats just from a
> log file, there is no way to be sure. Also, the
> scan1000.exe tools output was piped to a log file and
> they were scanning for port 1433 on random ranges of IP's
> (not ours) which leads me to believe that they probably
> came in through SQL port if they are trying to find more.
>
> This may be a new SQL exploit. I ran this SELECT
> SERVERPROPERTY('productversion'), SERVERPROPERTY
> ('productlevel'), SERVERPROPERTY ('edition') and this is
> what was retuned fyi: 8.00.760 / SP3 / Std. Edition
>
> Thanks,
> Scott

jcochran
Wed Nov 26 09:26:08 CST 2003

>If anyone has any information as to who to contact, who
>to provide information to about new exloits, how our
>system may have been exploited etc please let me know.

There are plenty of exploits that don't have patches. Your
administrator could simply give admin access to his buddy to run a
WaReZ site on your system. No possible security patch will stop that.

You mention only service packs and security updates, not strong
passwords, auditing of login failures, firewall rules or any other of
the many security measures you should be taking.

Follow Karl's advice, and make sure you do so on *all* systems under
your control.

Jeff

Scott
Wed Nov 26 12:55:31 CST 2003

I appreciate everyone's input / time to reply to my
post. I'll leave you with a quick summary if interested.

First, of course we had what is considered a strong sa
password for SQL. And of course we need it exposed to
the internet or it wouldn't be. And there were only two
people who had admin rights on the system so one of us
giving the info out was not a possibility. Also, was not
SQL injection - thats pretty easy to avoid (even though
most people probably don't utilize injection prevention!)
Thats all common sense.

It appears as though one of two things (or both)
happened. First, it appears as though (I didn't do it)
that Inet services were installed and left in its default
configuration ie: urlscan and certain directories not
removed. Anyone who has a server should do this before
its ever exposed - I think this got missed in a
configuration change somehow.

Next, I do see where xp_cmdshell was executed on the sql
server log. This should have never happened unless the
sa password was compromised. Of course if it was then we
all know how they could have created their new admin
account on the system to do whatever. The sa password
was not what I would (previously anyway) considered
weak. I looked through the password dictionary they used
and it was a learning experience - it was huge and had
every conceivable combination of what a password could be
including random chars and had multiple case scenarios
for each!! holy cow :) I'm guessing over time this is
what caused a problem. I see where the same individual
from Korea I believe attempted manually hacking into the
server over the course of about a month after piecing
together all the evidence.
Whoever reads this should do the following:
-->Make your sa password stronger or you will be sorry!
-->Run MSBA on any machine attached to the net, windows
update won't do the job sufficiently.
-->Stay in touch with your computers. Don't wait until
you have a problem to look through all the log files.
-->Go read an article about SQL injection, xp_cmdshell
etc. and be educated if you haven't already!!

Now I have one more question. Almost every company I
deal with has no need for anyone outside the US to
connect to their system in any way. Does the US have a
range of IP's (a block) that could be added and exclude
every other countries IP ranges? Seems to me if this
were possible most of the hacking problems would go
away. Heck, I think every router you buy should only
allow US access unless an option that says International
is checked, wouldn't that be cool :)

Also, one last note for you Symantec customers - I ran
symantecs virus scan on the server and it didn't find any
of the three that Trend Micro's product found. And no, I
didn't remove them with the first scan then run the next
one - everything was exactly the same. Symantec didn't
even have virus definitions for the one's Trend Micro
found. Lost a lot of faith in the product after seeing
this with my own tests... And for the guy who had a
problem with running housecall to scan a system? Because
I always double check with housecall - it really performs
and works well and runs independantly of everything else
on the system. Lots of viruses / hacks know exactly how
to get around the security apps you load resident on the
systems. Everyone has their own ideas so lets not debate
this, I just wanted to share my two cents for those who
may benefit.

Good luck staying safe and Happy Thanksgiving!

Scott

jcochran
Wed Nov 26 13:53:54 CST 2003

>Next, I do see where xp_cmdshell was executed on the sql
>server log. This should have never happened unless the
>sa password was compromised. Of course if it was then we
>all know how they could have created their new admin
>account on the system to do whatever. The sa password
>was not what I would (previously anyway) considered
>weak. I looked through the password dictionary they used
>and it was a learning experience - it was huge and had
>every conceivable combination of what a password could be
>including random chars and had multiple case scenarios
>for each!! holy cow :) I'm guessing over time this is
>what caused a problem. I see where the same individual
>from Korea I believe attempted manually hacking into the
>server over the course of about a month after piecing
>together all the evidence.
>Whoever reads this should do the following:
>-->Make your sa password stronger or you will be sorry!
>-->Run MSBA on any machine attached to the net, windows
>update won't do the job sufficiently.
>-->Stay in touch with your computers. Don't wait until
>you have a problem to look through all the log files.
>-->Go read an article about SQL injection, xp_cmdshell
>etc. and be educated if you haven't already!!

Not monitoring the logs and leaving xp_cmdshell available are the two
grievous errors. Though many have made the same mistakes before.
That's how most of us learned security -- recovering from not having
learned it earlier. :)

>Now I have one more question. Almost every company I
>deal with has no need for anyone outside the US to
>connect to their system in any way. Does the US have a
>range of IP's (a block) that could be added and exclude
>every other countries IP ranges?

Sort of. But what prevents a hacker from compromising a system in a
small college in Peoria and using that to attack you? That's not the
best way to prevent outside attacks.

>Seems to me if this
>were possible most of the hacking problems would go
>away.

There are still a large portion of attacks from company insiders, as
well as from US-based systems and US systems that have already been
compromised. The internet is global, learn to play a global game.

>Heck, I think every router you buy should only
>allow US access unless an option that says International
>is checked, wouldn't that be cool :)

Again, useless. And a bit against the entire global communication
basis of the internet as well.

That said, we've dropped a large block of IP's at our firewall that
originate in China and Korea, too many attempts and no legitimate
traffic from those ranges. But my attacks seem to come from France,
Italy, Israel, Saudi Arabia and Pakistan pretty regularly as well. Of
course, it's still probabaly 70% from US/Canada so blocking IP ranges
is pretty futile in our case.

Good luck on the second time around, and again on the third. And yes,
there'll be a third. :)

Jeff

Karl
Thu Nov 27 07:21:30 CST 2003


"Scott" <anonymous@discussions.microsoft.com> wrote in message
news:026601c3b44e$dd95b2d0$a301280a@phx.gbl...
> I appreciate everyone's input / time to reply to my
> post. I'll leave you with a quick summary if interested.

Thanks, and well written.

> First, of course we had what is considered a strong sa
> password for SQL.

Adding special characters such as Þ ALT-0222 in admin passwords is helpful
[though it could cause problems for IIS, not sure about Exchange or SQL].

There are articles out there arguing that 4 character passwords are just as
secure as 8 character passwords. These articles have a point, but your
scenario helps to argue otherwise.

> And of course we need it exposed to
> the internet or it wouldn't be.

I'm curious what the need is for SQL connections from the Internet. If you
have certain customers that need SQL connections, perhaps ACLs permitting
those IP addresses plus a VPN or IPSec tunnel is in order? I can't imagine
a scenario where you would need to permit every IP address in America access
to SQL over 1433.

> -->Go read an article about SQL injection, xp_cmdshell
> etc. and be educated if you haven't already!!

Besides disabling xp_cmdshell and a long list of other stored procedures
that have the same problem, I highly recommend considering the other things
mentioned in the sql hardening checklist at www.sqlsecurity.com

> Now I have one more question. Almost every company I
> deal with has no need for anyone outside the US to
> connect to their system in any way. Does the US have a
> range of IP's (a block) that could be added and exclude
> every other countries IP ranges? Seems to me if this
> were possible most of the hacking problems would go
> away. Heck, I think every router you buy should only
> allow US access unless an option that says International
> is checked, wouldn't that be cool :)

There are lists in www.google.com of the subnets associated with certain
countries, and some people do block out certain countries. This could be a
little useful. However, if an attack is possible from Korea, and you
haven't used other means to harden yourself from that attack, then sooner or
later someone in America [or a compromised computer in America that is being
remotely controlled by someone in Korea] is going to try that attack.

> Also, one last note for you Symantec customers - I ran
> symantecs virus scan on the server and it didn't find any
> of the three that Trend Micro's product found. And no, I
> didn't remove them with the first scan then run the next
> one - everything was exactly the same. Symantec didn't
> even have virus definitions for the one's Trend Micro
> found. Lost a lot of faith in the product after seeing
> this with my own tests... And for the guy who had a
> problem with running housecall to scan a system?

I find the trendmicro virus database a lot more descriptive than
symantec's... but I've had good experiences with Norton. All antivirus
products have isolated slipups. And there are other factors besides just
number of exploits detected when evaluating antivirus. When deploying to
desktops on a large organization, ease of use and remote management tools
for reporting, installing and patching the software without causing
excessive network traffic become important. And, if you're using trend
micro on the computer, running a second opinion scan from the trend
housecall site is no longer as helpful, because something that slips by
trend could possibly slip by housecall as well.