05:40 AM

Google Is Evil

The popular search engine is a great source for nascent hackers who want to build up a collection of sploits

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

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.