This is by no means an in-depth article on exploit types, or any information on a specific application, but more a quick guide on the methodology I generally use. There are hundreds of articles on various exploit techniques for various languages, a quick google will give you all the information you need. However there are relatively few articles explaining how pen testers/researchers get from a presumed safe web app to a working exploit.
This article presumes you have a basic understanding of vulnerabilities and basic website security.
Scenario: You have been hired by a company to test their website, after initial inspection you discover they are using X-CMS, it’s a PHP based CMS with a MySQL backend, all the common features, user system, forum, chat box, blog etc.
The first thing you would want to do, is gather information. Find out what version of the software they are running, any plugins, etc. there are a lot of useful tools to do this kind of discovery, and a lot of custom scripts for various web apps for discovering plugins and themes… a quick google for “<cms name> vuln scanner” should yield some results. Otherwise just check the source, looking at every link and url you can find to see what is running behind the scenes.
This company is using just the standard X-CMS nothing bespoke or added, and the latest version. so let’s go ahead and download it. Since we are not testing for server vulnerabilities, we download and add usbwebserver [link] into the directory so we can do our testing safe on our own computer.
Once it’s all loaded and set up, learn the source, understand where specific directories are, check for any kind of filters that might need evading and what they are protecting, check what functions you want to be able to use and how their protected, which pages that should be protected might not be… just understand as much as possible.
Things to take into account:
– Directory structure
– Protected files and folders (via source controls)
– .htaccess files
– Uploadable content locations (images – avatar, post)
– Uploadable content protection, specific extension, meta tag checking, file size
– every use of include(), require(), system(), exec(), popen(), pcntl_exec(), eval(), preg_replace(“blah /e”)
– every use of every mysql statement and protection on them
– the relationship between the database and the web app (eg. is data converted before being put into the database or do they use htmlentities() when pulling it out)
– every time data is displayed, username, content, anything that can be modified, is there something that isn’t sanitized properly
This list could go on, but as you can see there is a lot to take into account, there are various scanners that will try to identify vulnerabilities [link] [link] and a quick google will give you loads more to play with… I recommend doing just that, playing until you find whats right for you, what features you like and use, what reporting style you like and stick with that (or those)
Hopefully by now you should have a list of things to test and places to look. it’s time to set up your environment for the testing phase. start up the web server. my preference is Firefox with the firebug add-on. and some sort of testing proxy, two popular ones are Paros [link] and Burp [link] there are plenty of others again it’s a case of hunting around and finding what suits you best. you might also find it useful to have some XSS tools (BeeF is a good example [link]) and SQL tools (Havij seems to be a popular choice [link])
It’s time to test, try out the exploits/vulnerabilities, learn to use the tools, hopefully you will find what you expected. If all went to plan you should now have a working exploit, access to sensitive information, XSS, a shell, it all depends on what you found.
My recommendation is to practice, practice, practice… keep downloading different tools, understand them, ALWAYS perform manual scans – read and learn the code. Download various CMS’s just to play and learn [link] is a good resource for finding CMS’s to play with. Most importantly – have fun.
if you have any questions, or notes, things to add etc. I’d love to hear from you in the comments, if not, I hope you enjoyed reading this.