Re: SQL 2000 Server gets hacked

From: centron GmbH - Wilhelm Seucan (ws@centron.de)
Date: 01/03/03 

From: "centron GmbH - Wilhelm Seucan" <ws@centron.de>
Date: Fri, 3 Jan 2003 09:42:25 +0100

Thank you Beth.
I will try to solve the problem and get back to you.

William

"Beth Breidenbach" <beth.breidenbach@getronics.com> schrieb im Newsbeitrag
news:uciGV2osCHA.2496@TK2MSFTNGP10...
> Ouch.
>
> Okay, you have some cleaning up to do.
>
> First, assess all the logins your customers are using. Personally, I don't
> let people direct-connect to the server (I build them GUIs to use -- more
> coding effort but also more controlled). Scanning a range of IPs for
> existence of port 1433 and/or 1434 is a pretty basic practice among
> entry-level hackers. It's how they determine that a) your db engine is
> SQLServer and b) you've left it connected to the Net.
>
> Next, they check to see if you're using SQL Server Authentication or
Windows
> Authentication. Using Windows Authentication raises the bar. If you
> absolutely _have_ to let people direct-connect, make them use Windows
> Authentication. Again, there's a whole class of penetration tools designed
> specifically to try and crack well-known users and pwds. (I assume you
HAVE
> placed a strong password on the 'sa' account?)
>
> Naturally, I assume that NO CONNECTION, including that of your website
code
> is running with privileges any higher than datareader/datawriter. NO dbo,
NO
> system administrator, etc. Websites are a common offender here -- I'd bet
> 30% of the sites out there are connecting as dbo, just because it was
easier
> for the developer. never never never....
>
> What next? Your SQl Service itself shouldn't be running as a
well-privileged
> account. (SQL Agent requires more, but not SQL Server). An account that is
a
> local Admin but only has guest priveleges on the domain will generally
> suffice. Why? because if they've figured out how to connect to your box as
> sa, they've probably already issued a "xp_cmdshell 'net user /add.....'"
> command --> if your service is running as System or some other powerful
> domain account, they'll have the ability to add their own domain Admin
> account. Ouch.
>
> Regarding the website: All queries should use parameters, and the
parameters
> should be passed via Parameter objects in the Command.Parameters
collection.
> Dynamically-built queries open you to risk of SQL Injection attacks, which
> lead to the items I've mentioned above.
>
> I'm assuming you've completely wiped the box clean and re-installed SQL
> Server? If they've compromised the server, they may have modified some
> system stored procedures to their advantage. You want those puppies
> reinstalled....
>
> Now, for the big question: why are you certain the hole is in SQL Server?
> You have a Windows box open to the Internet. The attack could have come
from
> a variety of configuration points. There are lockdown scripts available
for
> IIS, Windows, and SQLServer --> none of which will exactly match your
> requirements, but _all_ of which touch important configuration items for
> each of these services. The fact that SQLServer is on the box doesn't
> guarantee it was the hole -- what auditing have you done to determine the
> path of attack?
>
> Hope this helps....
>
> Beth
>
> "Wilhelm Seucan" <ws@centron.de> wrote in message
> news:av1v0i$tn0$06$1@news.t-online.com...
> > Hello Beth,
> >
> > > 1) Is the box itself accessible to the Internet?
> >
> > Yes it is. Some of our customers connect to this server with the
> enterprise
> > manager.
> > Could this be a security hole?
> >
> > > 2) Does the database accept queries from any website?
> > Yes. Can i change this? If yes, how?
> >
> > > 3) Have you configured your box with protection in mind (which is
> > > different than just applying patches -- see www.sqlsecurity.com for a
> > > checklist of things to lock down)?
> > I tried to but as you see i did it not well.
> >
> > William
> >
> > >
> > > Beth
> > >
> > >
> > >
> > > "Wilhelm Seucan" <ws@centron.de> wrote in message
> > > news:av1sv1$r93$06$1@news.t-online.com...
> > > > Hi,
> > > >
> > > > we have a SQL 2000 Server with SP2 and the latest Patch installed.
> > > > Some hackers are able to penetrate the server and install hidden FTP
> > > > Programs.
> > > >
> > > > Anyone an idea where the security hole in MS SQL Server is?
> > > >
> > > > Thanks.
> > > >
> > > > William
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: SQL account rights
    ... Please advice what is the best, suitable rights rather than domain admin ... Warren Brunk - MCITP - SQL 2005, ... Add it as a login to the SQL Server ... files, or backups, make sure that the service account has Full ...
    (microsoft.public.sqlserver.security)
  • Re: User authentication
    ... There are 2 SQL Server 2005 ... 1 SQL Server 2000 installed on another server ... Windows account instead to run backup jobs. ...
    (microsoft.public.sqlserver.clients)
  • Re: SQL 2000 Server gets hacked
    ... Thank you Beth. ... > placed a strong password on the 'sa' account?) ... Your SQl Service itself shouldn't be running as a ... (SQL Agent requires more, but not SQL Server). ...
    (microsoft.public.sqlserver.security)
  • Re: Microsoft Search service cannot be administered under the present user error SP3
    ... - Have not modified Administrator account, but i ran the SQL script anyway. ... SQL account is not a local administrator. ... > has this server ever been upgrade from SQL Server 7.0 or is this SQL ...
    (microsoft.public.sqlserver.setup)
  • Re: Microsoft Search service cannot be administered under the present user error SP3
    ... - Have not modified Administrator account, but i ran the SQL script anyway. ... SQL account is not a local administrator. ... > has this server ever been upgrade from SQL Server 7.0 or is this SQL ...
    (microsoft.public.sqlserver.fulltext)