September 2, 2009 at 12:02 pm
Hello everyone,
I got a nasty shock when I tried to prove that my production server was protected against sql injection attack via OPENROWSET.
Cesar Cerrudo has written an article describing the use of OPENROWSET functionality to allow attacks on both system and user tables. (www.appsecinc.com/.../Hunting_Flaws_in_SQL_Server.pdf).
I checked my production server, using Surface Area Configuration For Features, and confirmed that under the topic "Ad Hoc Remote Queries", that Enable OPENROWSET is NOT checked. I was feeling pretty confident when I went to a non-linked server and tried "Select * from ProdServer.Master.dbo.MyTable", this returned "Could not find server 'ProdServer' in sysservers". So far, so good.
However,
Select * from OPENROWSET('SQLoledb',
'server=ProdServer;uid=sa;pwd='MyPwd',
'Select * from Master.dbo.MyTable')
instantly returned the entire contents of the table.
Cerrudo's article states that when a hacker can get a response from a victim server, it may be fairly trivial to then obtain all necessary control to do some real damage.
This is really frightening. Does anyone know how to lock down OPENROWSET and OPENDATASOURCE?
Thanks,
Elliott
September 2, 2009 at 1:18 pm
The ad hoc remote queries option doesn't block sa-level logins.
Edit: And, honestly, if someone has the password to the sa account on your server, locking out OpenRowset is the least of your worries.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 2, 2009 at 1:49 pm
Yes, I did use the sa login in my test, following the example that Cerrudo gave in his white paper. (BTW--my original citation actually points to another of his papers. Google "Cerrudo Manipulating Microsoft SQL Server Using SQL Injection" to reach the actual pdf).
I am not satisfied that I have done everything possible by depending on strong passwords and "requirements" that developers restrict input strings to foil SQL injection. I am seeking other ways to lock down SQL Server and it would certainly help if I could limit the use of OPENROWSET.
G-Squared: Thanks for your response. If you know of other good resources on effective security management, I would appreciate it.
Elliott
September 3, 2009 at 7:14 am
Yes, I read the paper. His use of sa was just examples. As I mentioned, if someone has the sa password for your server, SQL injection is the least of your worries.
This particular injection problem can be pretty well avoided by the usual techniques (parameterized queries and not using string concat to build anything you're going to execute), and by not using sa for anything. (Personally, I prefer to only use AD security, not SQL logins. Too many vulnerabilities, and it's easier to control.)
Locking down remote ad hoc is a good idea in most cases. Same goes for xp_cmdshell, of course. (You don't even want to know what injection attacks can do if they can also access the command shell.)
But the most important is parameterized queries. Preferably stored procs, and no dynamic SQL that uses user-input at all.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply