New SQL Injection Attack Fuses Malware, Phishing 202
PainMeds tips a recent post in Secure Computing's research blog describing a new SQL injection attack that had infected thousands of MSSQL-based web servers by last weekend, turning them into malware delivery systems. The attack apparently rewrites the server's Web pages to include JavaScript which pushes malware to the visitor as if it were from the genuine site. Sites using Sybase might possibly be vulnerable, as it uses the same exploited syntax that MSSQL does. The post includes an example of the attack. Unlike most malware attacks, this one appears to originate from the site the user is actually visiting. From the blog: "'Similar to phishing, this attack takes advantage of the website visitor's trust in the site they are visiting. Instead of phishing for information, however, malware is sent to the client, which the client has a higher likelihood of accepting being from a trusted site... These web pages are associated with Web sites from around the world and supplying various content — including government sites, sales sites, real estate sites, and financial information sites among others."
Comment removed (Score:5, Insightful)
Re: (Score:3, Informative)
Yes, nothing new at all...
People used to do this by compromising the site in other ways, and inserting their malware rather than defacing the site... Some subtle malware tagged to a site is a lot less obvious than a blatant defacement so it lasts a lot longer and gets more hits.
Re: (Score:2)
They're just inserting the javascript directly into the websites's content, instead of putting an iframe to a hacked server to then run the javascript...
No, they're still using a central location. It's only a script tag instead of an iframe. Same idea though.
Re:Not really new (Score:4, Insightful)
Why do you assume all code is new. Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix. Not really taking into account that the interface is not controlled by the server anymore. But can be easily altered by the client. being that the bug is threw Microsoft SQL there is a higher chance that it is threw Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe. As well a bunch of people have a poor understanding on how to use SQL, they just think it is bit more optimized version of a flat file. Where the hard stuff are using joins. So they figure well this data isn't that important.
Re: (Score:2)
addendum: constraints often occur too they work to get a proof of concept and run out of money to harden their code. In theory they should have harden it before hand however, sometimes those methods get in the way of proof of concept testing, and their not paid for that. Also there is a huge number of developers who have no idea about SQL injection errors they just never thought about it before. Not all developers are on top of their game. They go to work and leave, and don't bother to learn anything new.
Re: (Score:3, Insightful)
There is also deliberate gross misconduct. A lot of the code is written by outsourced divisions, I-9 lackeys, or contractors who will be long gone by the time someone discovers the SQL injection bug. Most companies don't pay for audits of their Web code, nor do they care to.
Sad thing is that MS is doing their best to prevent this, but they still get blamed for what their customers do (or fail to do.)
Re:Not really new (Score:4, Insightful)
Don't blame the contractors, If they mess up it is usually do to bad management on the company. Having worked as a contractor/consultant I can tell you when there is good management at the company I produce really good work. When there is bad management my work isn't that great. The case of leaving a bug and being long gone has a flaw. Because people want return business and a good name. Doing a Hit and run of coding doesn't allow for a good professional credentials. But with contractors they are often under the gun far more then W2 employees to be cost efficient, any work they do needs to be approved as the company doesn't want to pay for extra non-speced work, and if that spec doesn't cover SQL injections or security and they do the right thing and bring it up, bad management will say it isn't an issue and just do what is speced, thus causing the problem. If they did go and take an extra 4 hours to make it secure they will not get paid for it. If the manager was smart and listed to the advice then good quality code can be released.
Re: (Score:3, Insightful)
Don't blame management. If you were asked to make a kid's toy, would you ask 'do you want it the safe way, which will cost an extra $5 per unit, or do you want the cheap way?'.
You are a professional, it is your job to produce software that meets professional standards. If others screw up, fine, but don't deliver an unsafe product just because nobody told you to make it safe.
Re: (Score:2, Insightful)
You've never actually held a real job, it would seem.
Re: (Score:3, Insightful)
Bingo. If it takes this hypothetical 4 extra hours to make you application secure, you should have quoted 4 extra hours, and if you didn't it's your fault, not your client's.
Re: (Score:2)
I give estimates, but they're estimates. In the end, a job takes as long as it happens to take. Others do things differently but to make the assumption you made in your comment seems to show a lack of understanding of the market.
I'm going to say you're likely in the same category as the parent and haven't actually done much serious consulting work, although I'm wiling to be wrong.
Re: (Score:2)
Like I said, the 4 hours was hypothetical. It was the amount of time the grandparent had mentioned in his post. If I were doing consulting work (I've been on salary for the last couple of years), I couldn't imagine a circumstance where I wouldn't bill 4 hours over my estimate. If your estimates are so far off that your clients won't pay actuals or you're uncomfortable even billing them then you're obviously inexperienced, and that's part of gaining experience. Sorry if I threw you off there.
My point was th
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
As a contractor myself, here's how that scenario sometimes goes:
* Client requests bid for web project
* I produce bid for web project, allowing for secure practices
* Client thinks bid is "high", requests task itemization
* Upon further review, some involved employee of client asks "What would this part cost without all that secure coding stuff?"
* Regardless of my answer, the client responds "We don't need that, redo the bid without it"
* Attempting to "hide" the extra work in the itemization is dishonest, and
Re: (Score:2)
Also, I'm regularly turning away work as it is, so why should I spend hours and hours of extra time bidding out jobs that I don't have time to take anyway? I just tell clients that I work hourly, and if they're OK with that then we move on.
Granted, I'm never going to make huge extra profits this way, but overall I think it's fairest to everyone. If the client wants, I give a range of what a project will cost with a low and high cost, and if my costs
Fixed two sites so far... (Score:2)
Once the
Re:Not really new (Score:5, Informative)
Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix.
All too true. My company maintains some sites that were originally written during the 90s by a different web consulting company. The sites were happily chugging along and serving up pages for upwards of 10 years, until last weekend when they were hit with the exact attack described in this article. Fortunately, the attack was noticed early and we were able to fix the problem quickly, resulting in a minimal impact on our client's users.
I wasn't involved much with the emergency fixes, but our team ended up installing a product called dotDefender [applicure.com] that seems to have done a fantastic job of filtering out malicious requests. It inspects GET and POST data _before_ it's passed on to the vulnerable application and stops the request if it detects things like SQL injection, cross-site scripting, directory traversal, or other attacks. If you use IIS6 and have a lot of vulnerable code; or, like us, some of the bad code is contained within compiled libraries for which you don't possess the original source, I'd definitely recommend checking it out.
Alternatively, there's a free ISAPI filter [codeplex.com] that will perform similar pre-application-level checking of GET and POST data, though I believe it only checks for SQL injection, and I can't vouch for it since I've never seen it in action.
Unfortunately, I don't believe either of these solutions work with IIS7, so if your sites run on IIS7, I wish you luck!
Re: (Score:3, Interesting)
Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe.
That reminds me of a time when I was asked to help someone add a new feature to a set of reports generated on an internal web app. I take a look, and discover that this system works by generating SQL statements based on the form fields in client-side JavaScript before loading them in a new window via window.open. So you had ?sql=SELECT+*+FROM+TABLE sitting there for all to see.
Checking the JSP (it's not just .NET devs) confirmed that it was just blindly passing whatever it got to the database and essentiall
Re: (Score:2)
Sure, blame the coders... we're partly at fault here, but a bigger piece of the problem is that such arbitrary code is allowed to be executed at all, with no way to disable it.
You can restrict queries, but there's no option to disable EXEC. That, to me, is a grave oversight. What's worse is the SQL folks sternly refuse to implement such a feature.
Re: (Score:2)
Re: (Score:2)
You can restrict queries, but there's no option to disable EXEC
If more database-accessing code used stored procedures (and hence EXEC) instead of arbitrary queries, the database parts would work faster and there would be less likelihood of this type of attack working.
It's *possible* to write a stored procedure that's vulnerable to SQL injection, but it's a lot harder than writing a plain query that is.
malware + phishing = (Score:4, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Well, there are worse composite buzzwords [userfriendly.org]...
Attempts made on our systems... (Score:2, Informative)
Our web apps got hammered with this over the weekend... our simple but effective SQL injection block kept them out, but it is also comforting to know that even if it had not, it would not have worked on good ol' MySQL 4.1
Also, for what its worth, all of the IPs (100s of them used in the course of 3 days) trace back to ISPs based in Beijing. Hmmm...
Re:Attempts made on our systems... (Score:4, Funny)
The Olympics are trying to hack your webserver?
I wasn't aware that Server CTF was an Olympic sport.
Re: (Score:3, Funny)
In Communist China, the Olympics hacks you!
Re: (Score:2)
One World, One Dream (Score:2)
Now we know whose dream it is.
$conn_id = mysql_connect("microsoft.com") (Score:2, Funny)
Re:$conn_id = mysql_connect("microsoft.com") (Score:5, Insightful)
You'd have to be an idiot programmer to have a site succumb to this... It's not even "microsoft specific".
It would affect any site that takes request parameters and passes them straight through to the db engine (well, not specifically this syntax, but the concept behind the attack).
To be fair to Microsoft (heresy here, I know) asp.net built-in validation throws an exception.
In other words, not only would a programmer have to use raw request string data with the db, he would also have had to specifically disabled the default page validation. In other words, an idiot.
My website got hit with this type of attack last week, and the attempts were all rejected by the default validation. Even if the default validation had got past, all of the database queries use parameterized stored procedure calls which pretty much ignore this kind of crap anyway.
Still, it's made me think more about security and additional parameter validation. Maybe the next attack will be a bit sneakier..
MSSQL is particularly vulnerable (Score:2)
The "feature" of MSSQL that allows compound statements separated by semicolons, without any sort of begin / end block, makes it particularly vulnerable to this type of SQL injection attack.
This type of attack requires more than just modifying a where clause or changing a value - it requires injecting one or more complete statements. MSSQL allows you to begin a new statement in the middle of any unchecked parameter. Most databases don't. That is why MSSQL is unusually vulnerable to this sort of attack.
Ora
Re: (Score:2)
It looks like its creating a procedure and then running it, which can do that. Technically I guess you could blame MS, but it'd be like blaming them because a third party used Visual Studio to write a program with a buffer overflow, which got exploited and was used to run a spambot.
They've been giving people the tools to prevent SQL injection for a very long time now. That its still happening isn't their fault, any more then its the fault of <language that lets people run direct SQL>.
Take a look down
Re: (Score:2)
> If that's the case then they could be affected too.
But for some reason they are not. This means that either
a) It is Microsoft's fault after all
b) People who use MSSQL write more crappy code than those who use e.g. MySQL
c) Attackers only target MSSQL for some unknown reason. Which means that it is less secure by default.
So, which option would you like to take. Or do you see some other options?
Re: (Score:3)
According to this study, there are more MySQL users than there are MSSQL users. So there goes down pretty much all your arguments (unless you can provide better source for database market share):
http://www.mysql.com/why-mysql/marketshare/ [mysql.com]
> there are more idiot level programmers using Microsoft stuff
Can't disagree with that argument.
Sigh... (Score:2)
Why is using stored procedures so taboo. It is a very easy way to protect against most SQL Injections. It also allows you to share the database logic to different apps as well, allowing more integration across your other apps. update x set x.y=@varname where x.j=@find is so much more secure then sql_exec("update x set x.y='"+varname+"' where x.j='"+find)
Re: (Score:2, Insightful)
The whole SP vs inline sql debate is an entirely different kettle of fish (btw stored procs suck =P). The easiest way to protect against sql injection is parameterise your sql (yes you can do that with inline sql!). Next easiest thing - realise that everything from outside the system is essentially user input and treat it as such.
I use .NET / Sql Server on a daily basis - it isn't hard to make these kind of attacks a non-event, the problem is the multitude of drag and drop developers who have nfi what the
Re: (Score:2)
Why is using stored procedures [to prevent SQL injections by creating an in-DB 'api'] so taboo?
ORM (object relational mapping) tools can't speak your stored procedure API.
Re: (Score:2)
It really depends on the setup though. For the most part I am working in places with a hefty Database Servers and apps that often do the same thing with different interfaces. For this case a lot of stored procedures and interface shells of apps tend to do the trick, as updates update all the systems at once and there is a single location to adjust security. For cases where you are working on big app with a small database server for its use. Just parameterizing queries are ok. But I found using stored proc
Re: (Score:2)
You can also run into problems in supporting multiple databases without using stored procedures.
DB specific functions can cause a similar amount of grief. Like porting SQL Server code to Oracle, then getting errors when trying to use a GETDATE() function.
Re: (Score:2)
Isn't that specifically why you should use stored procedures? Then you only have to change your connection string in your code and change the functions in the procedures as necessary.
Of course I'm a dba so I think changing a proc is easier than changing code. I think a healthy division of the work is a good thing though. Why write code in your app to do what the db already can?
Re: (Score:2)
I tend to agree myself, although a number of developers seem frightened of putting application logic in the database.
Seems they'd rather try to get something like websphere to share functionality rather than let two applications use the same stored procedure.
Re: (Score:2)
I can understand an additional middle tier approach with something like a websphere approach which gives you another level of abstraction. In truly large environments this makes sense.
4 tiers is a lot of work and creates a lot of places where things can go wrong which is why I like the 3 tier approach which is more like a traditional hub and spoke type model. Application servers can be clustered and load-balanced to achieve necessary performance, reporting servers and data-sources can similarly be scaled o
Re: (Score:2)
DB specific functions can cause a similar amount of grief. Like porting SQL Server code to Oracle, then getting errors when trying to use a GETDATE() function.
This is where SPs can make your code more portable by creating a compatibility layer that does A on Oracle, and B on MSSQL.
Re: (Score:2)
Re: (Score:2)
If your a good DBA you always want to know how a web site/app/developer/etc is accessing your database. You only give that person/app/what ever the access it needs to work no more. If you can control how they update, insert, select, and delete data from the system the better off you are. The developers may not like it, but you are doing your job if you make sure that they cannot take down or damage the database system or the integrity of the data in the system.
Most likely every developer and contractor is g
Re: (Score:3)
Re: (Score:2)
The simple fact is that the demand to use stored procedures is nothing other than a power grab by DBAs.
Uh, I use stored procedures and I'm not a DBA. I do it because:
- They run faster (since the server saves the execution plan).
- They let me handle data processing on the server if I want instead of transferring the raw data over the network to the app server and then processing it there.
- They provide task-based granular security at the database layer, so I can control exactly what certain IDs can call.
Re: (Score:2)
- Prepared statements still process data and the server. Not using stored procedures doesn't mean that you have to extract raw data.
- The task based security you claim only works if you run the entirety of that logic unit on the server written in SQL. T-SQL is an utterly horrible language. I get to run my code on the server when I choose to do so and run it on an app server when I choose to do
Re: (Score:3, Interesting)
It depends on your definition of DBA. In the large companies I've worked at, the DBA administers the database but the application developers develop the tables within them. DBA = backup, tablespaces, etc. App Dev = db contents. I'm a database developer and would never claim to be a DBA (although SQL Server is easy enough that I could get by in a pinch).
Layne
Re: (Score:2)
If your DBA can't be used as a resource for optimizing and properly designing queries and stored procedures, you need to find another DBA.
Am I in a time warp? (Score:5, Informative)
Re: (Score:2)
Thanks, I was just about to go dig that up myself. Every couple of days, someone new shows up on DZone claiming to have "discovered" this "new attack" (typically by having been a victim of it), and the meme makes the rounds yet again. Quite frustrating hearing so many cries of wolf.
We got hit a few weeks back (Score:5, Interesting)
We were added to the attack list a few weeks back, and one of our largest, most popular websites was hit. Apparently, the developers had never thought to sanitize their data, and we had multiple vulnerabilities throughout the site.
I implemented a transparent reverse proxy server running Apache with mod_security that helped prevent further attacks from getting through, but the developers finally saw the error of their ways and converted hundreds of inline SQL calls into stored procedures.
Since we were added to "the list", I've been seeing the same attack happen across multiple pages every 20 seconds, so they are definitely not letting up anytime soon.
Re: (Score:2)
Re: (Score:3, Interesting)
"Select * from Users Where UserID='" & Request("UserID") & "'"
To
CREATE PROCEDURE GET_USER_DATA(@UserID varchar(200))
AS
exec('SELECT * FROM Users WHERE UserID=''' + @UserID + '''')
END
Using stored procedures doesn't solve anything if developers don't actually understand what the problem is. You don't even need to use stored procedures. Simply switching to prepared statements would have fixed the problem.
Re: (Score:2)
I LOL'd
On a side note, I ran into a similar situation a few days ago. I was toying around with the idea of writing my own forum years ago when I was in school with way too much free lab time. I was smart enough to use validate parameters before passing them to stored procs, but when I ran out of time to play with it I just pulled down the posting and listing pages, so that people going to the website could no longer browse or post. What I forgot to pull down though, was the actual script that posted pages.
Re: (Score:3, Informative)
Oh it goes well beyond sanitizing input data, why were they not utilizing the least privilige principle [wikipedia.org] in their application design? Allowing an unauthenticated user to use a database user with full privileges to the database tables when only selects are required on specific tables is asking for trouble.
In most cases I suspect the developers are, well, just lazy. When presented with a ready made least privilege PHP application design [sourceforge.net] the response by mul
Not new at all (Score:4, Informative)
This trojan, called Asprox or Danmec, has been around for a few years. It was originally intended as a Spam distribution system but I believe that sometime in 2007 an SQL Injection tool was installed via its botnet. It has been doing the rounds every so often on the Internet since at least January.
http://blogs.zdnet.com/security/?p=1122 [zdnet.com]
http://www.secureworks.com/research/threats/danmecasprox/?threat=danmecasprox [secureworks.com]
-dZ.
Why the missing quotation mark? (Score:3, Interesting)
I just looked and see this in my logs too; looks like they started on August 6 over here.
What's funny is that it looks like they're trying the attack in pairs: once in the "classical" quotation mark form (GET /index.php';SQLCOMMANDSHERE) and then again without the quotation mark (GET /index.php;SQLCOMMANDSHERE). How is that second form supposed to get executed? They've gotta be trying it for a reason.
Re: (Score:2, Informative)
In that case your first example would be adding an opening quote, so the injection would fail. Perhaps MSSQL is even more lenient and lets you get away with un-quoted strings as well.
Re: (Score:2)
Re: (Score:2)
It's a pretty interesting attack, really. It gets around sql-scrubbing code by sending the quotes in as hex, and it only runs the update code to append the javascript on char, varchar, ntext & nvarchar fields, at least on the versions of it i've seen.
i won't get too redundant on the "you should use stored procs" thing
Re: (Score:2)
Some sort of strange logging where it's saving all requested page URLs straight to a DB? That's about all I can muster.
Broken? (Score:2)
Perhaps the problem is too many groups are attempting to use it as if it is a fail-safe system - banks, corporations, financial institutions, governments. It was never designed to be fail-safe. Frankly if they had treated it more like a the "wild west web" and less like a "cheaper and easier platform for advertising/cost-cutting" then we wouldn't be in this mess.
Answers on a postcard as to how to fix it.
Re: (Score:2)
Perhaps?
Dan Kaminsky said in his BlackHat speech something that can be extrapolated to every technology. Essentially, the statement was, that a feature that wasn't meant as a security feature shouldn't be seen as such, even if it happens to appear as one (IIRC it was about the TTL increasing the time between attack attempts. TTL was never meant to be a security feature).
The net was never meant to handle secure bank transactions. The internet was concepted as an open network between (more or less) trusted no
Re: (Score:2)
The thing is, the barrier for entry for anything "global" is so stupidly high... getting things accepted by the public is harder and harder, and large scale projects are farther and farther in between (unless they involve war).
So as soon as something of large scale appears, people jump on it. Be it Youtube, Facebook, the Internet, fossil fuel, TV, HTML 4.0... You can't make up stuff like that everyday.. we all wish we could have stuff truly designed for what we need it... but its so hard to get it massively
Re: (Score:2)
The things you mention as examples all offer something that people didn't have before and wanted. Youtube gave them an easy way to display their videos, Facebook is an easy way to have your own page for your friends to look at, the internet itself ... c'mon, we're using it right now, it has value. I dunno yet what value, but it has to have some...
Anyway. All those things offer some additional value people didn't enjoy before they appeared. So if you want "secure internet" to happen, you have to show people
Re: (Score:2)
Your examples do show something: People don't want value or features. They want mindless and easy, regardless of how useful or anything else it is for them. Mindless and easy is what they want, nothing more. They'll buy something they don't need or want, if its mindless and easy.
So yeah...secure internet will never go through. You have to find something mindless and easy that just so freagin happen to be more secure than what we have now.
Re: (Score:2)
Re: (Score:2)
Queue The MSSQL Bashing (Score:3, Insightful)
Re: (Score:2)
Are you aware that it is entirely possible to, without being hypocritical, be critical of somebody's failures while at the same time not have the skill to do the same task? Most (trusted!) movie critics couldn't write themselves out of a box. I don't need to be a structural engineer to know that ignoring load limits is a bad thing, and probably a stupid mistake.
OLD MEME (Score:2)
WELCOME TO LAST YEAR. This sort of SQL injection - DECLARE/CAST/EXEC has been going on since last November.
Re: (Score:2)
Ah, here it is:
http://isc.sans.org/diary.html?storyid=3823 [sans.org]
Is it *visitor* or *client* that trusts the site? (Score:2)
From TFA:
If this means that the browser allows malware to actually be installed without user
This is older than last week (Score:3, Informative)
I can see those in my webserver's logs dating back to 23rd of July:
Oh, and the hexes decode to:
(phew, I'm lucky to get that through Slashdot's filter!)
You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:
Have these guys been on Holiday.. (Score:3, Informative)
The attack is ancient.
The method of delivery is a bit newer - a few months ago it all got a lot more efficiently delivered - it's pretty mainstream knowledge, even this article [scmagazineuk.com] from the paper edition of SC Magazine talks about it - and their copy deadlines will be from weeks ago.
Re: (Score:3, Funny)
Re: (Score:2)
Yes, with MSSQL you want to send:
exec xp_cmdshell 'del c:\*.*';
Or something similar, my grasp of dos commandline is rather weak, being primarily a unix user.
Who the hell thought it would be a good idea to allow users of an sql database the ability to execute arbitrary system commands?
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Depends. If the admin has no choice but using remote control software to bring it back up, you might get a good chance to hit the server before every service pack and patch could be applied.
Re:DELETE FROM USER* (Score:4, Informative)
More likely to work:
del c:\boot.ini
Then, next time it's rebooted... it doesn't come up. It's not something noticeable right away.
Re: (Score:3, Interesting)
Re: (Score:2, Informative)
Only starting in SQL Server 2005 iirc... Do you have any idea how many people use MSDE 2000 still??? It's scary.
Absolutely not true. xp_cmdshell is denied by default in MSDE 2000 (and sql server 2000).
Incidentally, there is nothing inherently wrong with MSDE from a security standpoint. MS still releases patches for it. MSDE is a solid, ACID-compliant database (unlike a popular open-source database that also starts with the letter M). MSDE is the same robust database engine as its bigger brother, sql server
Re: (Score:2)
MSDE is a solid, ACID-compliant database (unlike a popular open-source database that also starts with the letter M).
If you're talking about MySQL, you're incorrect. MySQL with the InnoDB engine is absolutely ACID [wikipedia.org] compliant [mysql.com].
Re: (Score:2)
Re:DELETE FROM USER* (Score:4, Funny)
Let's see who's laughing when the Political Correctness brigade catch up with the Gregorian Calendar and hold it to task for picking on poor, old February.
Re: (Score:2)
I've been using SQL Server since 4.3 on OS/2 1.1 (94) and I can say that it was not enabled by default then. You had to specifically grant it to the user if you wanted to use it.
And as always, if you don't do string building and have properly bound variables, it's REALLY hard to get hit by a SQL Injection attack.
Layne
Re: (Score:3, Funny)
Re: (Score:3, Informative)
Take a look at the article from this comment, it has a "use at your own risk" procedure. You could probably modify it appropriately.
http://it.slashdot.org/comments.pl?sid=643879&cid=24574393 [slashdot.org]
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Re: (Score:2)
4. Wait for someone to realize your code still has SQL injection vulnerabilities, and just write an attack query in PGSQL syntax instead.
Re: (Score:2)
You mean like the UTF-8 \'-escaping vulnerability? [nist.gov]. That one was a pretty big deal for anyone with an international database, since
The best part is that you don't even have to write crap code to get hit by that... "Moderately shady" is bad enough to be vulnerable.
Re: (Score:2)
Re: (Score:2)
The internet was always populated by dogs - just that nobody knew.
Re:So, to recap...[ot] (Score:2)
Aw man, you're making me want to play Diablo II again. I remember it clearly, as Deckard Cain Said:
"According to HORADRIC lore the HORADRIC key can be made with HORADRIC alchemy by inserting HORADRIC staff and HORADRIC amulet into the HORADRIC cube. HORADRIC."
Re: (Score:2)
Not much of a revenge, as only shitty programmers will be affected by this. Its not like its using an MSSQL exploit or anything... this could be done with any database that allows multiple statements in a single query (and maybe some that don't, if the code is really bad).
This would never be able to hit any application written by someone with more than "I know how to use a mouse LOLZ" level of experience.
The only thing I've read about though, is that this attack was so aggressive, it actually DDOSed some sm