September 28, 2009 at 3:57 pm
To all, I need advice on this one.
We are using sql 2000 and I have been running a trace using SQL Profiler.
I have noticed this phrase in the Text Data column in the profiler:
-- 'sp_password' was found in the text of this event.
-- The text has been replaced with this comment for security reasons.
I know the command sp_password is a sql command and it is used to change passwords on SQL logins.
What I am not 100% certian of, is this an attempt by someone to use SQL injection or some other hack?
If it is an attack, how can I get the parameters they are passing to the sp.
Also, how can I find out what aspx or asp page they are using?
I need to present this information to management as quickly as possible.
Thanks
Gary
September 28, 2009 at 6:03 pm
It could be an attack, and the only way I know to find out what parameters it is using is to use a packet sniffer on the network or the suggestion a little further down... the MS tools won't tell you as a security measure. But you can tell alot anyway.. What machine is the command coming from, what is the login name executing it.. Is that machine a web server or an app server. Is the machine a desktop? Can you have that desktop checked out? Are you getting this a lot or occassionally.. Is this a big server where there are logs of users? Is there a policy that says passwords have to change every so often..
Also, you might be able to "hack" sp_password to store the passed in parameters in a table. I have to say I would do this LAST or perhaps not at all because of the security implications..
Also adding sp_password in the comments of a sproc is a way to keep profiler from showing the code.. I have used that trick for code that was sensitive..
CEWII
September 28, 2009 at 6:15 pm
Elliott W (9/28/2009)
Also, you might be able to "hack" sp_password to store the passed in parameters in a table. I have to say I would do this LAST or perhaps not at all because of the security implications..
This is truly something of last resort. It breaks non-repudiation which has serious legal implications if you were to have a breach caused by an employee and attempted to prosecute. Also, it brings your SQL Server to a non-supported state with respect to Microsoft.
K. Brian Kelley
@kbriankelley
September 28, 2009 at 6:18 pm
You can add Application Name and Hostname to the columns you're reporting on. Unless those have been hacked (and they can be), that should tell where, what app, and the login name column should tell you by who.
K. Brian Kelley
@kbriankelley
September 28, 2009 at 6:35 pm
K. Brian Kelley (9/28/2009)
Elliott W (9/28/2009)
Also, you might be able to "hack" sp_password to store the passed in parameters in a table. I have to say I would do this LAST or perhaps not at all because of the security implications..This is truly something of last resort. It breaks non-repudiation which has serious legal implications if you were to have a breach caused by an employee and attempted to prosecute. Also, it brings your SQL Server to a non-supported state with respect to Microsoft.
I certainly wouldn't leave it that way at least not for long, and I agree it is a last resort.. It is an option, but not a vary palateable one..
CEWII
September 28, 2009 at 6:45 pm
The machine it is coming from is a Web server. The login is the login that the web server uses to connect to the SQL server.
This has been happening about every other day at different times of the day. Sometimes late at night, sometimes mid day, sometimes early morning.
I have not been able to establish what look like a pattern, however I am not an expert in pattern recognition.
I have searched all stored procedures for the sp_password command and none of them have it.
My gut feeling is that this is an attack, but I need proof.
Thanks for the information.
Elliott W (9/28/2009)
It could be an attack, and the only way I know to find out what parameters it is using is to use a packet sniffer on the network or the suggestion a little further down... the MS tools won't tell you as a security measure. But you can tell alot anyway.. What machine is the command coming from, what is the login name executing it.. Is that machine a web server or an app server. Is the machine a desktop? Can you have that desktop checked out? Are you getting this a lot or occassionally.. Is this a big server where there are logs of users? Is there a policy that says passwords have to change every so often..Also, you might be able to "hack" sp_password to store the passed in parameters in a table. I have to say I would do this LAST or perhaps not at all because of the security implications..
Also adding sp_password in the comments of a sproc is a way to keep profiler from showing the code.. I have used that trick for code that was sensitive..
CEWII
September 28, 2009 at 6:57 pm
Do you get a whole bunch or just a couple. Also, the login that your webserver is using isn't a sysadmin is it? Also we set our sa password to an unknown, long and strong password and create a new sa user..
CEWII
September 28, 2009 at 7:24 pm
The login from the web server only has access to the specfic database as a dbo.
it is not part of any server role.
The sa account on that server has a strong password and is not used for any of the services or connections.
We use a created login as the sysadmin and it is not called admin at all.
I quickly scanned the profilers that I have saved and the times that this shows up are:
3:25 pm
3:51 pm
3:58 pm
4:09 pm
4:27 pm
4:38 pm
4:44 pm
4:56 pm
5:18 pm
I stopped the profiler shortly after that but will start it up again shortly.
Elliott W (9/28/2009)
Do you get a whole bunch or just a couple. Also, the login that your webserver is using isn't a sysadmin is it? Also we set our sa password to an unknown, long and strong password and create a new sa user..CEWII
September 28, 2009 at 8:31 pm
If you have the option, pull the web server off the wire and begin a proper forensics investigation ASAP. If it's coming from a web server using a known login that has no business issuing sp_password, that's evidence of an attack. You need to figure out how the web server is compromised (I'm assuming it is because of the evidence you've posted) but you also probably want to look at preserving evidence, too, hence the reason for taking a solid forensics approach.
K. Brian Kelley
@kbriankelley
September 28, 2009 at 10:57 pm
I agree with Mr. Kelley. You need to control your exposure at this point. I think there is a very high chance of risk and taking the WS offline in the evening is the right way to mitigate it..
CEWII
October 5, 2009 at 10:05 am
I think ever since SP4 this message appears any time the captured sql is using a password-related system sp. It is a security feature (although hiding what is going on from authorized monitoring is a bit of a problem too.)
It could be an attack, but it could also just be one of your apps that creates logins, for example, as part of its security.
October 5, 2009 at 10:19 am
I thought it went back further than that.. But I had also read that sp_password is not masked in SQL 2005/2008 anymore but CREATE LOGIN and ALTER LOGIN are..
Since this is a SQL 7/2000 post I don't think the 2005/2008 stuff matter..
Based on his descriptions I think it is indicative of a likely attack, but he does need to do additional research..
CEWII
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply