But this high-profile site deftly deflected these attacks and the others that followed because Poteet had anticipated—and then protected against—the kinds of exploits he knew would be coming. How did he know? Quite simply, hes a hacker, and thinking like a hacker—and getting to know the tools that hackers use—is one of the most effective ways to protect your company from being exploited.
Poteet, chief security officer at AppDefense, is the type of hacker commonly referred to as a white-hat hacker or security researcher—someone who digs for system holes to point out where trouble could occur. Black-hat hackers are just the opposite—people who try to gain access to systems and the data on them for nefarious purposes. In the past, most hackers were in it for fun or for bragging rights.
Now, black hats are selling exploits for tens of thousands of dollars as the malware industry capitalizes on flaws to capture passwords, credentials for banking sites and personal information for identity theft and financial fraud.
Learning how black-hat hackers think, what theyre looking for and how they get it should be a fundamental part of any companys security strategy.
According to George Kurtz, author of "Hacking Exposed," hackers targets have changed dramatically in the last few years.
"When I got into the game ... it was, We dont have a firewall, we have a packet-routing filter. Fast-forward to today, and youve got very interactive applications: Youve got Web 2.0 tying in back-end databases and all the exposures around that," said Kurtz, who is also the founder of Foundstone, an organization that teaches hacking and secure coding practices. Foundstone is now a division of McAfee, and Kurtz, of Mission Viejo, Calif., is senior vice president of McAfees enterprise division.
Indeed, applications are increasingly drawing hackers attention. According to research by Gartner and Symantec, close to 90 percent of software attacks were aimed at the application layer as of June 2006.
"Once you open Port 80, you have unfettered access to an application," Kurtz said.
Application-level flaws arent new. In 2002, Poteet won eWEEKs OpenHack IV competition, in which people were invited to hack a test e-commerce site. Poteet was able to hack the version of the site tied to an Oracle database application.
Basically, the flaw that Poteet exploited was a screen in which users could edit their profile. The user name constituted one field—supposedly not an editable one. But as soon as input was accepted from the front end, with the Web server taking data from a browser, it didnt matter whether the field was designed to be editable or not—at that stage, everythings editable.
Poteet changed the name in the field to "A Smith," and then he waited, like a spider for a fly. As soon as somebody named "A Smith" logged on, he pounced, immediately gaining access to all of A Smiths data.
The problem is, most application developers dont think the way Poteet did during OpenHack.
Poteet said he has consulted with many companies and has grown accustomed to seeing not just a vulnerability here or there, but a vulnerability in every field in every screen of every application in question.
And were not talking mom-and-pop shops—most of Poteets clients are Fortune 500 companies, and many of them are financial institutions. But, even in organizations within the financial realm—an industry known for being well-versed and experienced with security issues—those who work on code still leave well-known security holes that draw attackers like flies to honey.
Fool Me Once ...
If theres one sure thing when it comes to security, its that people make the same mistakes—over and over and over. Its something that hackers have come to count on.
Common holes include data in error messages that can be used to access systems, SQL injections, XSS (cross-site scripting) and access control in J2EE (Java 2 Platform, Enterprise Edition) applications.
Hackers especially love SQL injection: A good SQL injection will elicit data from all the tables in your database. And if attackers gain edit capability in a user query, they can change data in the database.
These issues are among the top 10 most frequent mistakes made in application security, as outlined by the Open Web Application Security Project. Also included in that list is usable information provided in error messages.
Take this error message: "Microsoft OLE DB Provider for SQL Server error 80040e14 Column newsTBL.NEWS_ID is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. G:\WEBSITES\WWW.SAMPLECOMPANY.COM/internal/dbSys.inc, line 241."
From that one error message, a potential attacker will learn that the application uses OLE DB to communicate to the database, that it uses SQL Server as the database, that SQL commands can be passed to the database and that theres a table called newsTBL in the database, among other things.