Page 2

By Lisa Vaas  |  Posted 2007-09-07 Print this article Print

At one point, Sunbelts Greg Krass, vice president of product management, changed the select statement in this URL to include information schema columns, which he expected would give him the database structure. He received two error messages, which in turn told him that the defense department is using Access as a back-end database. Access isnt a SQL-based database, but its just as easy to toy with, he told eWEEK. Through such querying and tweaking of select statements, he also found out the name of the database file and that it was a Windows 2003 box. Finding that out is trivial. Krass typed this query into the URL: &strsql=select+%2A+from+test.txt, which returned an error message that said, in part, "Could not find file c:\windows\system32\inetsrv\test.mdb." The error message references the c:\ directory, which had been called C Windows NT in Windows 2000. This means its a post-Windows 2000 operating system, which could be XP or 2003, but Krass could tell "just by poking it" that it was Windows 2003, he said.
From there, somebody who wants to really abuse this database and site could just set up a script to throw known Windows 2003 and Access exploits at known vulnerabilities in those programs.
What can these sites do to clean up their acts? Patching is the most obvious part of the solution, Krass said. "Once a patch is available, its basically a verifiable admission on Microsofts part that there was something there. Whether there was a POC [proof of concept] or exploit code there [initially], you can bet your bottom dollar [there will be soon]." That applies not only to Microsoft code, of course, but also to other programs known for flaws and exploits, whether theyre proprietary or open source: PHP and Apache, for example. A security policy that would specifically help sites such as the one belonging to the European defense agency would be to keep SQL users running with bare minimum access rights, Krass said. Many times, people set up accounts that represent full-fledged database ownership when they only need read access and not write access. Setting "write" privileges on another account would be a good idea, Krass said. Instead, "people cut corners for simplicitys sake," he said. The thing about SQL is that it is often overly powerful. SQL can be used in other commands that act on the server. For example, xp_exec is an extended stored procedure. From a SQL command line, if a user gets the ability to run a command by putting a SQL query in the command path, he or she can get to a command prompt within the SQL server itself. Thats it, Krass said: end game. That unauthorized user now has the ability to tell the server to do anything. "You dont want that, you dont need that, [you should] never have that ability," Krass said. "That doesnt just affect one database; it lets you own the entire SQL box. "SQL permissions are very different from permissions that other systems use. …[Its] fairly misunderstood what you can do with those permissions. Make sure SQL access accounts are locked down." Another best practice has to do with logs. By default, logging should be turned on with most services. And they should be backed up and offloaded to another server where they cant be modified, Krass said. "If a server gets compromised, one of best things [an attacker can] do on [his or her] way out is to clear out the log files so theres no record of it," Krass said. Therefore, logs should pump out to another machine constantly, he said. "When you set up a Web server, dont just plan for not getting it compromised. Plan for what happens if it does get compromised, so you can do damage control later. How do you know what you [may] have to remedy?" Another good practice is running vulnerability assessment programs so as to pick out what software needs to be updated. Outside vulnerability assessments are another good idea, Krass said. An even cheaper, easier and quicker spot check is to run Google searches on ones own site, Eckelberry said. Set up a Google alert to look for certain keywords that will sound an alert every time the word "sex," "casino," "free ringtones" or the like pops up on a site—its a quick, simple way to tell if Web servers are being used for redirects—or worse. Sept. 7: The sites back-end database is still exposed. The defense agency has responded to eWEEKs e-mail. "Thanks a lot for your information," the communications office simply states, including no ETA for a fix. "We are working on it." Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.

Lisa Vaas is News Editor/Operations for and also serves as editor of the Database topic center. Since 1995, she has also been a Webcast news show anchorperson and a reporter covering the IT industry. She has focused on customer relationship management technology, IT salaries and careers, effects of the H1-B visa on the technology workforce, wireless technology, security, and, most recently, databases and the technologies that touch upon them. Her articles have appeared in eWEEK's print edition, on, and in the startup IT magazine PC Connection. Prior to becoming a journalist, Vaas experienced an array of eye-opening careers, including driving a cab in Boston, photographing cranky babies in shopping malls, selling cameras, typography and computer training. She stopped a hair short of finishing an M.A. in English at the University of Massachusetts in Boston. She earned a B.S. in Communications from Emerson College. She runs two open-mic reading series in Boston and currently keeps bees in her home in Mashpee, Mass.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel