First things first, you have to ask yourself if you need to be stealth. If this is for a local attack (a penetration test on your own network) then you shouldn't really need to be stealth. On the other hand if you want to try a remote attack (white hat purposes only of course) then you should be very careful to leave as little traces as possible. There are 3 golden techniques:
- run the attack from somewhere else than you residence (library, cybercafe, open access point, ...)
- use proxy servers
- Never (ever) connect to your mail servers. If in the case the webmaster of the attacked site has enough motivation he can acquire information from certain mail servers to see if there was any activity coming from the same IP address. If you have your own website on a public server you would be safer not connecting to that either.
Now that your computer "is untraceable" you need to do some information gathering. If the attack is going to be web based connect to the website and check out what applications are running. Look near the bottom of the pages to find the famous "Powered by xyz". Get as much information as possible from these applications and try to find the versions, plugins (if any), and dates installed. Often the tag won't show the version number but will show "copyright 2005, 2006". Keep everything you find in a text file so you're sure not to forget. I suggest you use google to get every indexed page with a lookup like this: `site:www.apollonews.com`. Doing this you might even find some files that were meant to be hidden. After a while you'll get the habbit of seeing certain CMS setups and can give an estimated guess simply by seeing the page layout.
Now that you have all the information you can start by seeing if an exploit for these applications/plugins already exists. There are a few exploit databases online that hold thousands of exploits. A very famous and practical database is milw0rms. If you can't find what you're looking for online you'll need to start hunting yourself. Try to find and download the exact same version of whatever application they are running. Install it on a local server, run the setup and learn how to use it. At the same time you need run through the files and check out the code. Look for common attack vectors: sql injection, include vulnerabilities, xss atacks, ...
Note that there actually does exist pretty secure applications that just can't be attacked. In that case you'll need to go deeper and checkout the server.
Another common way to get through even the most secure programs is to see how secure the installation is. If for example the site is on a public server you could open an account with the hosting service. Then from your account load a php shell onto the server. Knowing how to make your own will greatly increase your chances that your shell will work seeing that certain commonly used php functions are often blocked on most servers to avoid this kind of attack (notably "system()"). A very practical and easy to write shell doesn't actually execute server commands but simply open files for viewing. If your are able to open a file and read it's content you might be able to open other files from other directories (other websites) on the same server and read their content. After you have loaded it onto your server space, point it toward your targets space and look for potential config files.
If you installed the application locally you should know where the config file(s) are located. Inside this file there are often the credentials to the database with table names. More than often people use the same password for several applications. You could try to use the password as the applications admin password. If that doesn't work you could try to use that password for the webmasters email, then send yourself the sites password using the famous "I forgot my password" scripts.
Not to forget that if you have the database credentials and that the server uses a database for user names and passwords, try to find the highest access leveled used in the database and login. If from the inside of the application there are some sort of logs you should try to erase them regularly. Try every possible way to use the same password for other connection tools: ftp, ssh, pop ..
When using your viewer script don't forget to check to see if the server has it's own files in bad privileges. Try to open /etc/password, /etc/shadow, /etc/password.master, and also /etc/hosts to find other machines that are on the same network as the web server. If bad luck (and a lot of luck) you were able to get your hands on /etc/passwd you should download and checkout JohnTheRipper.
Running server based attacks have much more creative methods available. In the beginning you have to start out the same way as web based attacks and try to collect as much information about the servers services as possible. Scan it and look for all the listening services. For the best scans I recommend you use nmap and amap. Amap is the the not so known cousin of nmap that tries to determine which services are running on the server even if they are not running on their default ports. Now that you have gathered all the application banners with versions you could look and see if an exploit exists already for each one. Milw0rm also has a section of remote exploits that you could check out. More often than not servers are patched on a regular basis. This is where the fun part comes in (no exploits exist): you need to install the same OS as the server, then install and setup the same services. Hopefully these are open source programs meaning you can download the source and run through it. I suggest you run some flawfinders on the source that will look for common vulnerabilities using regular expressions. If you get lucky and find one time to start some application debugging and see exactly how you might be able to exploit it. Another very simple to find application bugs is to run the service in a debugger and run a fuzzer (next article on making a fuzzer
). When the exception pops up into the debugger try to find the exact query that made the application throw an exception. From here on it's time to code an exploit which will often be either a string format exploit or a buffer overflow. You should try to set up the server with the same security options as the server and think about non executable stacks etc. If not your exploit might run locally but never on a remote machine.Don't forget that if you were able to put your hands on the /etc/hosts file and that there are publically accessible servers you might want to scan and check them out at the same time. Getting access on one of then could be just as effective as getting access to your target afterwards thanks to sniffers.
There are also many applications that will set them selves up automatically with default passwords. This is why you shouldn't forget about anonymous ftp accounts etc.
To write an exploit with shellcode you should checkout the metaspoit infrastructure that will make writing shellcodes much simpler and more time efficient but you should first checkout to see if the service doesn't filter any characters.
Well that's about it for my pen testing walkthrough, hope you enjoyed it
--------------------------------------------------------------------------------------------
Hi5 Falling Stars 
0 comments:
Post a Comment