Security Watch

Hacktivist Turf War

Plus, parking permit system compromised; inside the SQL Injection attacks; more.

Hacktivists or Criminals, Site Owners Need To Lock It Up
Defacements, allegedly in the name of hacktivism and allegedly between Serbian and Albanian criminals, continued to occur. This. despite claims that the "two sides" were discussing a cease fire.

Talk about overly sensationalized reporting! So what if the "groups" are allegedly sharing lists of vulnerable sites among "members"? So what if there's allegedly a tool that, to some extent, automates the attacks?

The simple fact remains that there are many sites -- governmental, business, and others -- that are poorly secured and left available to criminals. That the sites have been defaced and not abused in some more serious fashion is merely luck on the part of site owners. At some point, some form of legislation might be enacted in many countries whereby a lack of proper security will become a liability. What if the sites had had malware implanted on them instead of defaced content? Why should innocent visitors to such sites see content other than what they expected?

Instead of sensationalizing the acts of some childish criminals, perhaps we should put more focus on the act of disregard the site owners perpetrated that allowed their sites to be defaced.

Web Site Defacements Galore
More sensationalist reporting about Web site compromises. At least this time, proper attention is paid to the malware being dropped there and the manipulations to the site to have that malware propagated to unexpecting visitors.

This is another SQL injection attack being used to compromise sites and implant malware and it demonstrates the criminal's approach to simply find every site possible to compromise. The authors claim the criminals involved in these acts have "purposely avoided Chinese government sites." How, prey tell, do they know this? Could it be that the searching techniques simply went for a high level domain that did not include government sites? Does that mean they purposely avoided government sites?? I think not.

Perhaps we'd all be better off sticking to the knowns, and leaving unknowns, like motivation, out of the reporting.

Double Parked at Oklahoma State reports that a server at Oklahoma State University was found to contain warez recently. It was believed compromised late last year. The server also contained the personally identifiable information of everyone who had purchased a parking permit over the past five years.

The story starts by saying, "Personal information belonging to anybody who got a parking pass at Oklahoma State University (OSU) over the last five years has been compromised, university officials said Wednesday." Even if that was what university officials said, do you get the feeling we're going over the top with these PII breach notifications?

The university investigated the access to the server and found no evidence the data had been accessed or copied. So, why say the data has been compromised? Do we start imagining that warez are being placed on servers to cover up for data theft? Would a criminal leave warez, which are typically obvious to anyone who knows what should be on the server, and make the server stand out in an audit? Would they chew up tons of bandwidth distributing warez from the compromised server if they were getting value out of the PII records on it?

Come on folks, let's be sensible.

Death by SQL Injection
A presentation at EUSecWest demonstrates how to get GUI access to a SQL server via SQL injection, allowing OS hacking.

This is not exactly big news, especially when you consider the author claims that a DOS prompt isn't very powerful. It's hard to imagine how a criminal couldn't find a DOS prompt powerful enough to do what they want, especially if they've been able to compromise passwords in the process. Heck, Exchange 2007 is administered entirely via a PowerShell prompt, which isn't that much different than a DOS prompt.

Microsoft's Own SQL Injection Response
Given the significant increase in SQL injection, coupled with the abuse of Google and other search engines to identify sites that are backed by SQL servers, Microsoft has issued a security advisory to raise awareness of the problem.

As if the previous stories aren't enough to raise awareness, Microsoft issued the advisory with links to tools to assist administrators in realizing how their sites are vulnerable. For the info to be of any use, administrators must first think about whether their sites are secure or not, and unfortunately this advisory and the tools it links to isn't going to make that happen -- typically, the site will first have to be compromised before the administrator thinks to do anything more than they have already done.

If you look back, over time you'll see that we've been telling folks to look into their input code for a long time now. Knowing what you expect users to input is crucial to securing your site, coupled with ensuring you've stripped down your production SQL server to the bare minimum commands and programs it needs to function. For example, removing CMD.EXE can go a long way to avoiding problems. So what if I'm able to get the SQL server to execute the xp_commandshell if there isn't one for it to call!

Regardless what you've done, take the time to have a look at these tools and test yourself, you may very well find a combination you hadn't considered, or a page you'd forgotten about.

About the Author

Russ Cooper is a senior information security analyst with Verizon Business, Inc. He's also founder and editor of NTBugtraq,, one of the industry's most influential mailing lists dedicated to Microsoft security. One of the world's most-recognized security experts, he's often quoted by major media outlets on security issues.

comments powered by Disqus
Most   Popular