GIAC GSE.....the beginning

So it’s been a while since I have blogged, but I have decided to try again. This time though I am going to take the reader on a ride. I have spent considerable time contemplating and I have made the decision to attempt the SANS/GIAC GIAC Security Expert (GSE).

If you are unfamiliar with the GSE it’s SANS Expert level certification check out this link for details, it covers the requirements and the testing process. The certification is a two part process with a written and hands-on practical lab (very much like the Cisco CCIE.) I hold all three required certifications with a gold GSEC paper, Introduction to Malware Analysis. I am using my GCFW to satisfy the second gold paper (or elective). With the minimum requirements meet, I applied for the exam.

This week the application was approved,  and I have come up with this study plan and schedule for the written. I already indexed the three classes (SANS SEC 401, 503, and 504) that the written test covers, so I plan is to review the index and then read the books from each class.

After each class, I am debating if I purchase a set of practice of test for each class to review my strengths and weaknesses. If I don’t purchase I will spend time reviewing areas I feel I need to work on. If I do purchase practice exams I will take one after each “class”, than take a final consisting of all three “classes” at once.

My planned schedule is to review 3 to 4 modules a night during the week and at least 6 each weekend day (total of at least 12 each weekend). At that rate I hope to have the following schedule for each class:

                401 – 5/23 – 5/30

                503 – 5/31 – 6/5

                504 – 6/6 – 6/12

I will then do a final review the week of 6/13 with an eye on testing 6/18. As I write this it has me thinking about the challenge ahead, and to quote Barney Stinson “Challenge Accepted”! I will update the blog as I move towards taking the written. 

fuzzing a web applications directory structure

When performing black-box web application penetration test one of the most important steps, but often overlooked is the application profiling phase. The objective of the application profile phase is gather as much information about the application structure and the applications functionality as possible. Typically, especially during a black-box test, the tester is provided the application URL and perhaps a couple of logins to use for the pentest.

As with any other phase of a pentesting, the application profile phase is really made up of several steps. One of these steps is determining the applications directory structure. Its simple to find the “public” directory structure of the application, but what about the “private” directories of the application that should not be found, such as old versions of the application or more importantly administration functions?

To find these and other gems that can provide juicy information hidden in the “private” directories the tester must fuzz the applications directory structure. Web application fuzzing is simply sending random data to the web site requesting a resource and reviewing the results of the request to determine if the resource exist.

To give a simple example how fuzzing works lets examine the fuzzing process on the imaginary website www.site.com. The website directory structure consist of the following directories and if they are linked in the web application:

/admin – Not linked in the web application

/docs – Linked in the web application

/images – Linked in the web application

/pages – Linked in the web application

/scripts – Linked in the web application

/source – Not linked in the web application

/test – Not linked in the web application

The following HTTP status codes are used when fuzzing an application to inform the tester if the requested resource exist:

200 - OK

301 – Moved Permanently

302 – Moved Temporarily

401 - Unauthorized

Any other HTTP status code says the resource does not exist or is forbidden (HTTP 403 status code) to the tester. Understanding the HTTP status codes, the tester can to fuzz the application to determine its directory structure.

The tester will fuzz the directory structure by manually requesting the following directories and the request corresponding HTTP status code:

/admin – 401

/backup – 404

/code – 404

/docs – 200

/images – 200

/include – 200

/old – 404

/pages – 200

/source – 301 Redirects to /test directory

/scripts – 200

/test – 200

By manually fuzzing the application the tester found the /admin, /source and /test directories. Had the tester not fuzzed the website these directories would have been missed. Although the /admin directory requires authorization to access the tester now knows to spend some time trying access this area of the application. Finding the /source and /test directories, the tester chances of finding information about the security of the application increases.

Although in the above example the tester was able to find 2 “private” directories with just 6 guesses in the real world the tester would typically try thousands of directories to increase the probability of finding “private” directories. Of course, no tester wants to do thousands of manual requests to a website, so a fuzzing tool should be used to fuzz the directory structure.

With an understanding of what fuzzing is and how it works next time I will discuss a tool that I use to perform web application fuzzing. Of course like any tool there are lots of them out there is this tool is my personal preference.