April 20, 2004 at 2:40 pm
The Internet Storm Center saw an increase in scans for tcp/1433, the port SQL Server listens on in recent days. The news has also made C|Net.
Internet Storm Center - Handler's Diary for April 18, 2004
There's not a lot of information out yet as to why the scans are up and it may end up being nothing. Only time will tell.
K. Brian Kelley
@kbriankelley
April 22, 2004 at 8:24 pm
I've seen a few very frightening things recently. Hackers are port scanning entire IP ranges for boxes withSQL Server installed. Then they issue brute force password attacks against the sa login. Once they have the password cracked, they do three things. First, they install several additional NT services that look like legit services, but are actually nothing more than back doors. Second, they run their sql scanner and sa pass cracker from the newly hacked box. Third, they set up a warez/pirated software site.
I've obtained a copy of the hacker tools from a recently hacked box. The sa pass cracker brute forces up to 32 characters. The tools are fast, too. I ran them against a few class B ranges. It spit out several IP addresses and the passwords for the sa account on each of those IP. Keep in mind these guys are running this cracking util from every sql server box they have already cracked, so they have plenty of cpu time and bandwidth.
Once cracked, the hackers try cover their trail the best they can. Their motive appears to merely be a means to an end for building a giant network of fast servers with lots of storage so they can trade pirated software. As far as I can tell, they do not seem to want to cause damage to the host systems. The entire hack appears to be just a way to more effeciently pirate software. At least that is what I could tell from two different sql servers. Just server for hidden rar files on the largest volumes attached to the sql server, and you will see what I mean.
Anyway, the short term solution is to set your sa password to something much longer than 32 characters. An excellent long term solution would be to have Microsoft add functionality into SQL Server so we could list the IP address that were allowed to log into the SQL Server as sa. Changing the port SQL Server listens on will not help, because these hackers are port scanning. This is not a dumb worm that simply gives up if nothing is listening on a given port. Additionally, blocking tcp and udp access to sql server at the firewall will not help many sql admins, especially web hosting company that have webmaster customers located all over the internet. What we really need is a MySQL style solution were we can list the IP that will be allowed with each login. I would love to have a solution that customer log into sql server from any IP, but require sa to login from 127.0.0.1. That would resolve this problem completely.
April 26, 2011 at 3:54 am
We have also experienced this attack on one of our machines that hosted at the Amazon cloud. The instance has been there for only a couple of days and was already infected by this brute force tool.
The strange thing is that we did not have SQL server running at all though it is installed.
Eyal
April 26, 2011 at 4:19 am
Although the OP is over seven years old it's clear that there are still lessons to be learned here for many of us. Is it really a requirement to have an sa account or is it OK just to set up another one that does the same things under a different name?
April 26, 2011 at 5:13 am
One more insight: In our case the attacker used the tomcat manager interface (that unfortunately was publicly open with the default password) to install a servlet that started the worm.
April 26, 2011 at 6:47 am
Richard Warr (4/26/2011)
Although the OP is over seven years old it's clear that there are still lessons to be learned here for many of us. Is it really a requirement to have an sa account or is it OK just to set up another one that does the same things under a different name?
The sa account is present, but you can rename it and disable it in newer versions of SQL Server.
K. Brian Kelley
@kbriankelley
April 26, 2011 at 6:48 am
ebeyalb123 (4/26/2011)
One more insight: In our case the attacker used the tomcat manager interface (that unfortunately was publicly open with the default password) to install a servlet that started the worm.
Default passwords will get you every time.
K. Brian Kelley
@kbriankelley
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply