August 14, 2008 at 7:35 am
Hi,
I ran into this article that is fairly recent. It mentions a new SQL Injection attack.
http://www.trustedsource.org/blog/142/New-SQL-Injection-Attack-Infecting-Machines
I not sure if this is old news or not. The article doesn't really mention a fix. Not sure if your guys are aware or if there are any fixes for this?
Thanks
TKE402
August 14, 2008 at 7:47 am
Last timeI created a web app, there was a procedure to test to see if incoming data was valid SQL and if so, to throw an exception. How does this new exploit get around standard stuff like this, especially if you're first verifying the text to not be SQL and ALSO passing said text through a procedure?
edit: There also are simple programming way to pass text of ANY sort to a procedure from the web server to the DB and it will NEVER get executed. All standard practice.
Not saying this can't happen, but how do they get around these obsticals?
August 14, 2008 at 7:59 am
I think this is a new attack.
August 14, 2008 at 8:09 am
This specific attack is new, but the technique is not.
There was a question of the day on this site a month or two ago that was on this subject.
- 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
August 14, 2008 at 8:13 am
Not sure about the rest of it, but the CAST(Varbinary as Varchar) Injection trick has been around for at least 3 months. There are several instances reported here from May/April time frame.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
August 14, 2008 at 8:24 am
bcronce (8/14/2008)
Last timeI created a web app, there was a procedure to test to see if incoming data was valid SQL and if so, to throw an exception. How does this new exploit get around standard stuff like this, especially if you're first verifying the text to not be SQL and ALSO passing said text through a procedure?
As for bypassing the verification, that's not always that hard. The cast from varbinary defeats most keyword matching. As for defeating the procedures, far too many developers write web apps using concatenated together SQL strings, not parameterised calls to stored procs.
You call it standard and it should be, but far often the 'quick solution' is used instead
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 14, 2008 at 11:54 am
The problem with "checking for valid SQL" in the parameter string, is this:
http://www.mywebpage.com/subpage.aspx?id=1
Many coders will take the 1 and use string concatenation to add that to the Where clause of a query.
Private Sub GetCol1 (ID)
dim Query as string
Query = "select col1 from table1 where id=" & cStr(ID)
connection.Execute (Query)
(I left out a bunch, but it gives the basic idea.)
Even if you add in some steps like:
if ID like "select"
exit sub
end if
Even with a whole set of those, what happens when you cast this to a string?
0x313B6465636C61726520405320766172636861722831303030293B73656C656374204073203D202773656C656374202A2066726F6D207379732E616C6C5F6F626A65637473273B6578656328407329
You have to convert it to a string to concatenate it with the Where clause of the query. But when you convert that particular bit of hex to a string, you get:
1;declare @s-2 varchar(1000);select @s-2 = ''select * from sys.all_objects'';exec(@s)
Concatenated with the sample query above, this becomes:
select col1 from table1 where id=1;declare @s-2 varchar(1000);select @s-2 = ''select * from sys.all_objects'';exec(@s)
The code then tells it to execute that string. Depending on how result sets are handled and errors are trapped, it may or may not display the data set on the screen. But if it were an update or insert command, it wouldn't even need to return data to the screen.
Screening for SQL keywords just doesn't do it. You have to use parameterized queries (procs or otherwise) and you have to set strict security controls, and you have to use both correctly.
Don't give the login that your web aps rights to any tables that it doesn't absolutely need them for. Deny Insert, Deny Update, on any tables/views that the users shouldn't be modifying through the application, etc.
- 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
August 14, 2008 at 12:15 pm
According to reddevnews.com
"...stemming as they do from design trade-offs, development deadlines, functional requirements, a lack of imagination or developer indifference."
Even MS developers blame it on functionality requirements(trade off) or poor programming.
In the case of a 'trade-off', this type of attack can be expected and some sort of extra checking to 'verify' incoming code. For most other issues, it comes down to poor programming/design.
August 14, 2008 at 1:05 pm
Yeah, most of these things boil down to a lazy programmer or twelve somewhere along the way.
- 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 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply