CMT - Infrastructure Configuration Management Testing

The basic principle of infrastructure configuration management testing is the idea that the misconfiguration of the application infrastructure (web, db, smtp, etc.. servers) can lead to intrusions upon the web application. In other words, even if the web application is extremely secure -  misconfiguration of the  infrastructure can lead to a potential breach.  So how do we assess and manage this problem? A thorough examination  of the entire infrastructure must take place. The examination should identify the different elements that make up the infrastructure and how these elements interact with the web application. Information on the infrastructure must be either given to us by the application developers (the best way) or retrieved through various information gathering methods.  Once the infrastructure information is received, penetration testing can be done through different tools to find exploits.

Penetration Testing #2

One great way to find information is through the public domain.  There are plenty of "private" websites that can be found using search engines. This happens if a company does not setup their robots.txt file correctly and allows search engines to crawl their private website (*note - robots.txt can be completely ignored by search engines, but reputable search engines like Google follows the guidelines). Let's say you found a "private" website - now how do we get more information? Well, using the advanced search operators, we can restrict our searches to a specific website (example) or (cache example ). Once we have access to this information, we must now find points of entry to the web application.  Once such way to accomplish is through analyzing GET and POST (for more sensitive information) requests through "an intercepting proxy" (61).  An example of a post and get requests can be seen below:

• GET: http://domain.com/shopping/buyproduct.php?customerid=1&item=1001$quantity=5
• We can pretty much change the value of the parameters any given time.

• POST: http://domain.com/shopping/accounts.php?action=login
• The parameters are sent through the body of the message rather than in the URL.

Tools like Burp Suite or OWASP's WebScarab are great intercepting proxy tools for analyzing these requests. After finding potential entry, it's time to move on to fingerprinting.  In this stage, our goal is figure out what web server the web application is running. This is important because different commands will react differently on each web server and that is exactly how we will figure out the web server type.  For example, each webserver has a different order in how they display header information.  If one sends a simple HTTP request, the date and time parameters of the http header will be in different order in each web server.  Another way is to simply use a tool such as httprint.

Our next step is figure out which web application is hosted on a specific web server which I will cover in the next blog post.