Google Is Evil

Entire shelves of books have been written about the tools malicious hackers use; books discussing programs like nmap and Metasploit, and meticulously describing attacks from the mundane stack smash to the sophisticated arc injection attack.

But there is one tool more sophisticated than all the others: Google. The popular search engine enjoys pole position in the attacker's toolkit. Like every agnostic technology that can be wielded equally well for good and evil, Google is turned to evil ends every day.

Need a Sploit? Google it up
The most obvious pernicious use of Google involves using it to do just what it was built for. Even script kiddies who only come as high your ankle know that Google can be used to find attack tools. The most dangerous attack tools are scripts that exploit software vulnerabilities in widely used software. Instead of subscribing to mailing lists devoted to describing software vulnerabilities (and how they cause software to fail) like bugtraq, vulnwatch, and Security Tracker, nascent malicious hackers can build up a collection of sploits using Google to light their way in the dark.

There are two basic categories of malicious attackers: those who write the scripts, and those who merely know how to aim the scripts and press ENTER. The first type build the sploits. The second merely use them.

Exploiting software vulnerabilities from scratch is difficult and time consuming, often involving hours spent with debuggers and disassemblers, pouring over machine code at the lowest level, understanding stack architecture and pointers, and building a complex payload under serious technical constraints. Simply knowing that a software vulnerability exists is not enough. A would-be attacker must carefully craft a special purpose payload and then somehow cause that payload to be properly consumed by the target software. Two books, The Shellcoder's Handbook and Exploiting Software, explain this difficult process in some detail.

On the other hand, using a script to attack a victim often involves only picking the target and running the script. Possibly the hardest part of the entire process is finding the script in the first place. That's where clever use of Google comes in. Google makes things easier by indexing many kinds of binary files and HTML files.

It's worth mentioning another common use of Google along these lines: Plundering and pillaging corporate data accidentally exposed to the world on the Net. Search engines know about surprising things!

Of course, using a search engine is hardly novel. What may be a surprise is just how easy it is to find attack code and confidential corporate documents. Give it a shot yourself. To learn more about how Google can be turned on its ear, check out Johnny Long's book Google Hacking for Penetration Testers.

Google for Victims
Google sees much more insidious use by attackers than simply trawling up scripts and finding confidential files. It can also be used to find victims. The Google spiders ceaselessly crawl the Web building, a gigantic searchable index of everything they come across. In way too many cases, people who expose their machines to these Web spiders have no idea that they are simultaneously exposing their vulnerabilities for all to see.

Some attackers without a particular target in mind use Google to find machines running vulnerable software and recently have even begun to look for common programming errors. One researcher in the U.K. recently created a tool called Bugle that leverages Google technology to look for common software security bugs in code found laying around on the Net. The collection of bugs that Bugle knows about is small (less than 25 patterns) and is reminiscent of early ITS4 rules from the first generation of static analysis tools for source code review. With more sophisticated approaches to static analysis in modern tools like Fortify, it may only be a matter of time before much more sophisticated bugs can be Googled up.

Of course, security researchers have known for years that search engines were useful in uncovering vulnerabilities. A decade ago at Cigital, we set up a very early honey pot on our Web server with bait that appeared to be a CGI-bin program well-known to be vulnerable to attack. Our program tried to determine who was tickling the bait program, snag their IP number, and report their questionable activity back to root at the machine in question. Attackers used Alta Vista to find our bait and tickle it. It worked.

That was a long time ago, and the world has changed since then. Today, e-commerce is common, all banks use the Internet, and the number of people using the Internet is over one billion. Many of these billion people need to make sure they're not unintentionally hanging out an "0wn m3" sign.

Okay, it's not Google that needs to change. What does need to change to address this problem is clueless exposure of vulnerabilities to search engines. So quit reading this, go see what Google knows about your software, and whip up a set of robots.txt files!

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading