Google hacking for penetration tester - part 42 docx

Once you are ready to release your project, log into Google Code and click on the Source tab.You will be taken to your project source page.This page displays instructions on how to check

http://tortoisesvn.net/downloads or by installing Cygwin (www.cygwin.com) and selecting

the svn package For the rest of this section, we are going to operate from the console via the command line svn util.

Brief Introduction to SVN

Before we continue, let’s take a brief look at the subversion version management system

Once you are ready to release your project, log into Google Code and click on the Source tab.You will be taken to your project source page.This page displays instructions on

how to checkout your project folder as shown in Figure 10.27

Figure 10.27 Google Code Source Page

The following svn command will checkout a project:

svn checkout https://projectname.googlecode.com/svn/trunk/ projectname username

username

Substitute projectname and username placeholders with your project name and your

Google username.You will be prompted for your Google Code password (which is different

than your Google account password).Your Google Code password can be found at

http://code.google.com/hosting/settings

This svn command will create a new folder within your current working directory with the name of your project.To add files, change to the project directory and create a file Get back to command line mode and add the file in the repository like this:

svn add filename

Once you are happy with all changes and new file additions, you need to commit the project.This is achieved via the following line:

svn ci -m 'description of the commit'

Supply a different message (-m) for the commit message - something that is more descriptive and outlines the changes that you’ve made

Getting the files online

Once your project is committed into the source repository, you can access its content online

Your project is available at http://projectname.googlecode.com/svn/trunk Keep in mind

that the committed files are served as Content-type text/plain or Content-Type applica-tion/octet-stream (see Figure 10.28) which prevents them from being rendered within the browser.This means that in theory you should not be able to see/preview uploaded image

or html files

Figure 10.28 Live HTTP Headers for output for Google’s Subversion

Despite this, an attacker could still host malicious scripts which could exploit vulnerable browsers, allowing them system control of a visitor’s browser.This is where we start to see

the true potentials of the Google Code development platform.There is nothing that

pre-vents attackers from hosting their malicious files online and using them to attack their

vic-tims.This type of scenario is quite concerning since ISPs (Internet Service Providers) cannot simply block Google in order to stop a malware propagation, for example Many users will

stay unhappy

Those familiar with IDS (Intrusion Detection Systems) and IPS (Intrusion Prevention Systems) may object that malware can be also detected by using signatures as the ones found

in popular firewall products and open source projects such as Snort Although, this is true, an attack may stay undetected for most its time, due to Google Code’s encryption options As

we all know, encrypted traffic ensures privacy Google provides SSL connection for hosted

projects Here is an example:

https://projectname.googlecode.com/svn/trunk/path/to/file

By substituting https for http within the URL, we engage the https protocol which

encrypts our session, hiding the data in that session from the gaze of IDS and IPS systems

Because the https interface was meant to be used by developers, Google will prompt for

authentication as shown in Figure 10.29

Figure 10.29 Google Code Basic Authentication dialog

This is not the best scenario for an attacker wanting to host browser exploitation code, but a bit of HTTP trickery will help resolve that.The following URL will pre-supply the

credentials:

https://username:password@projectname.googlecode.com/svn/trunk/path/to/file

Once the attack is discovered, anyone can use the supplied credentials to enter the sub-version repository and revert the files back to a non-malicious state However, given the fact that most of today’s AJAX/XSS worms spread across millions of users within a couple of hours, the proposed setup is a compromise that most attackers will be willing to make

NOTE

Keep in mind that all files stored within the source code repository will be in the public domain Do not store any files that may contain sensitive informa-tion

Searching the Code

So far in this book, we’ve learned a few good tricks how to recover interesting information from Google’s vast indexes We’ve also seen that the search facility is quite fuzzy and we often need to refine our queries in order to get better results Wouldn’t it be nice to be able

to use regular expressions to find those pieces of information that are most interesting to us? Although Google Search cannot provide us with that, Google Code can Enter Google’s Code Search service http://www.google.com/codesearch (Figure 10.30)

Figure 10.30 Google Code Search

Code search is extremely useful in situations where we want to look for code snippets to borrow or just enumerate common vulnerabilities Let’s see how

Open the Google Code Search interface and type of the following query:

echo\s*.*?PHP_SELF lang:php

Notice that the syntax is a bit different from what we usually see.This is known as a reg-ular expression (regex) which you can learn more about from the following URL:

http://en.wikipedia.org/wiki/Regular_expression.This regex search returns results similar to those found in Figure 10.31

Figure 10.31 Searching for PHP_SELF vulnerabilities

Let’s take a closer look at what the regex does.The first part of the query looks for the keyword echo.Then we specify that there may or may not be a couple of spaces (\s*).The

part that follows specify that we are looking for an undefined number of characters until we

reach the final delimiter (.*?) At the end we finish with the keyword PHP_SELF Notice

the special parameter lang We specify that we are looking for PHP scripts only In general,

the query looks for something that may look like the following:

echo $PHP_SELF

echo($PHP_SELF)

echo ($PHP_SELF)

echo $_SERVER['PHP_SELF']

The improper use of PHP_SELF results in a very well known XSS (Cross-site scripting) hole.This mistake is quite common in PHP applications Most developers assume that PHP_SELF is not controlled by the user In fact, it is controlled by the user and can be very easily exploited Here is an example:

http://target/path/to/script.php/"><script>alert('xss')</script><! Notice that we append additional path to script.php which contains the characters

“><script>alert(‘xss’)</script><!— Due to the fact that PHP_SELF is usually used to find the URL of the current script, it is very likely that it is going to be used as part of an

element attribute.This is the reason why we use “> character combination, to break out of the enclosed element We end with <!—, to fix whatever it is left broken.

Let’s try another query but this time, we are going too look for SQL Injection holes (SQLI):

mysql_query.*?_GET lang:php

The result of this query is as shown in Figure 10.32

Figure 10.32 Looking for SQL Injection

The query starts with the keyword mysql_query which is a standard function in PHP Then we look for undefined number of characters with the sequence *? Finally, we look

for the keyword _GET which denotes HTTP GET parameter In general, we are looking

for SQL queries that can be controlled by $_GET A similar tactic can be applied to

$_POST based SQL Injection attacks Keep in mind that the examples shown in this chapter are just a few of the many variations that we can try Google Code Search is a very useful

tool that can be used to locate vulnerabilities in many languages

NOTE

We can use Google Code Search to locate strings within our own projects If

we have a large dataset to analyze, we can simply upload it to code and wait until the Google crawler finds it out Then we can use standard regular expression queries to locate the data that we are most interested in

Google Hacking Showcase

Chapter 11

A self-respecting Google hacker spends hours trolling the Internet for juicy stuff Firing off search after search, they thrive on the thrill of finding clean, mean, streamlined queries and get a real rush from sharing those queries and trading screenshots of their findings I know because I’ve seen it with my own eyes As the founder of the Google Hacking Database (GHDB) and the Search engine hacking forums at http://johnny.ihackstuff.com, I am con-stantly amazed at what the Google hacking community comes up with It turns out the rumors are true—creative Google searches can reveal medical, financial, proprietary and even classified information Despite government edicts, regulation and protection acts like HIPPA and the constant barking of security watchdogs, this problem still persists Stuff still makes it out onto the web, and Google hackers snatch it right up

In my quest to shine a spotlight on the threat, I began speaking on the topic of Google hacking at security conferences like Blackhat and Defcon In addition, I was approached to write my first book, the first edition of the book you’re holding After months of writing, I assumed our cause would finally catch the eye of the community at large and that change would be on the horizon I just knew people would be talking about Google hacking and that awareness about the problem would increase

Google Hacking, first edition, has made a difference But nothing made waves like the

“Google Hacking Showcase,” the fun part of my infamous Google hacking conference talks The showcase wasn’t a big deal to me—it consisted of nothing more than screenshots of wild Google hacks I had witnessed Borrowing from the pool of interesting Google queries I had created, along with scores of queries from the community; I snagged screenshots and presented them one at a time, making smarmy comments along the way Every time I pre-sented the showcase, I managed to whip the audience into a frenzy of laughter at the absurd effectiveness of a hacker armed only with a browser and a search engine It was fun, and it was effective People talked about those screenshots for months after each talk.They were, after all, the fruits of a Google hacker’s labor.Those photos represented the white-hot center

of the Google hacking threat

It made sense then to include the showcase in this edition of Google Hacking In keeping

with the original format of the showcase, this chapter will be heavy on photos and light on gab because the photos speak for themselves Some of the screenshots in this chapter are dated, and some no longer exist on the web, but this is great news It means that somewhere

in the world, someone (perhaps inadvertently) graduated from the level of googledork and has

taken a step closer to a better security posture

Regardless, I left in many outdated photos as a stark reminder to those charge with pro-tecting online resources.They serve as proof that this threat is pervasive— it can happen to anyone, and history has shown that it has happened to just about everyone

So without further ado, enjoy this print version of the Google Hacking Showcase, brought to you by myself and the contributions of the Google Hacking community