January 5, 2004 at 3:33 pm
Starting last Friday, I noticed a large number of failed logins for SA on one of our sql servers. I set up profiler to get more info and noticed they were occuring roughly once per second with the following info in common:
HostName: "SERVER"
ApplicationName: "OSQL-32"
ClientProcessID: "3348"
A representative sample of the other sql servers on the network revealed they were all experiencing the same thing... (Good thing for those strong passwords!)
A quick sniff of the network revealed these were all coming from one IP, so we blocked that IP on the firewall and that was the end of the attack. Kept an eye on it through the weekend and everything was fine up until about an hour ago, at which point the attack began anew from a new IP in a different part of the world with the exact same HostName, etc as listed above.
At first, I thought this was just a worm on someone's server somewhere, but the fact that the attack continues against my entire IP range makes me think it is more of a directed attack, but that may not necessarily be the case. Whoever or whatever, they are hitting across 30 class C IP ranges.
Has anyone else experienced a similar event? Does this sound like a worm or a person? Is the best course of action simply "Notice Attack --> Block IP"? Take it as given that I know I should have my servers listening on non-standard ports... : - )
Thanks!
-Dan B
ps- I hate h4><0r5
January 5, 2004 at 5:53 pm
I used to see this kind of attack on the last company I worked for, what our network guy did was keep a log of what the suspect trying to do and his ip address, find out who is his internet provider and start calling them, send them log related to that ip's address activity and tell them that you really need their help. Network people like to work with each other and they usually shut the culprit from obtaining service from their company.
mom
January 5, 2004 at 6:32 pm
It may be one of the worms that go after sa with a blank password. A network trace could tell you for sure. If so, they did go after ranges, so it could mean someone is infected and the pseudo-random IP generators those worms use have happened to hit upon your IP range.
If you have the option, change your external TCP port from 1433 to something else. Most attacks assume SQL Server is listening on the default port.
Also, as mom suggested, your network guys probably should be communicating with the owner of that IP range, especially if it's an ISP. They can block the attack on their side, and they'll probably want to. Also, if it is an infected customer, they can communicate the traffic they are seeing and the customer can do something about it.
K. Brian Kelley
@kbriankelley
January 6, 2004 at 10:02 am
Thanks for the response.
I have been in contact with the first ISP, and while friendly, they were unable or unwilling to provide the logs. They did, however, shut the offending machine off. The second event originated from South Korea. Since I don't speak Korean I have written off trying to contact them. I did send them an email, but it bounced back... not a good sign. Either way, both IPs are blocked on our firewall.
I would like to switch all the servers to a mystery port, but that will take some time to prepare for and complete. Mostly I am just happy these attacks have been pretty simple and from individual IPs. I am also grateful for strong passwords!
So far, I have been unable to determine whether the passwords tried are blank. In my limited packet reading experience, searching for empty data is much harder than searching for a known string like 'sa'.
Thanks again!
-Dan B
January 6, 2004 at 10:25 am
We see similar ones on our DB2 machines at times and usually use the IDS to trace back where the source is and use a firewall to block the IPs as well.
At 1/sec, it's got to be an automated attack or a worm. You might want to trace the attack with profiler and a sniffer if you can and send a log to MS.
January 6, 2004 at 11:38 am
This will help you know what packet to look for:
http://www.freetds.org/tds.html
Also, a sign that there is a password is if in the login packet you see 0xA5 every other character. This character appears because of the nature of Microsoft's "encryption" algorithm and the footprint it leaves when dealing with Unicode characters in the Latin (abcd...) character sets.
K. Brian Kelley
@kbriankelley
January 7, 2004 at 11:27 am
bkelley,
Great link. I spent a while geeking out over that page. It is safe to say I don't fully understand the protocol, but it is really interesting to see how it works. I checked the packets for 0xA5 and there it was, right after the sa bytes. I am still curious though... Does sql server encode even blank spaces with the same method? What I mean is this: Does the existence of the 0xA5 data indicate that the password used was not a blank one?
I don't have any real experience dealing with application roles, but I wonder if I can set an application role (or something similar) to block access to the offending application, listed in this case as "OSQL-32"
He (she?) tried again this morning, this time using many different user names:
user
guest
administrators
administrator
admin
root
sql
boss
test
sysadmin
server
database
administrateur
as
sa
Whenever the event ends before I get a chance to block it, I find myself hoping that it didn't end with success!
Thanks!
-Dan B
January 7, 2004 at 11:49 am
I believe you're only going to see the 0xA5 if passwords are being entered. Reason being the encrypted stream is just as long as the original password (ouch). What you might need to do, if you haven't already, is install an IDS in front of the SQL Server watching the traffic and if it sees the login failures, it alerts you (provided you don't have this already). Snort is open-source and free if you don't have Cisco or another vendor's product.
K. Brian Kelley
@kbriankelley
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply