CMT - Old, Backup, and Unreferenced Files

A lot of times, people forget about old files that they have stopped using. Usually they are renamed, including file extension, and just left on the server. This is a terrible idea since this can lead to attackers being able to download these files and viewing the source. For example, let's say we rename our config.php file to config.php.old.  Since the renamed files is no longer a PHP file, an attacker can download it (due to the extension change, the files is served as a plain/text  rather than being executed on the server), rename it back to config.php and view the contents. This is not limited to just renaming files - often times, people leave backed up files on the server fully accessible to the public.  These backup and or configuration files should be placed in areas of the server not accessible from the web (out side of the public_html folder).

How do we prevent this?

• Don't edit files on the live system. Edit locally, then upload via SSH or FTP.
• Setup a system to delete/move old backup and obsolete files.
• The web application should be made so that data, log, and configuration files are stored outside the public_html folder.

How do we look for systems that can have this vulnerability?

First use a web mirroring tool to setup local "version" of the site. Then using the file names, try to infer the naming convention of certain files. For example, if there is a adduser.php file, there could be a deleteuser.php file.  Secondly, look at the comments of available source code. Sometimes, users leave sensitive comments in files.  Thirdly, use the robots.txt file (if exists) to look for certain directories or files that the user does not want index by search engines. A lot of times, you can find the administrator dashboard directory in here. It is also a good idea to look for open directories that might contain various different files. Some of these directories might contain a backup or renamed file.

Some tools to make this job easier are:  Nikito  ,  Wikito (like Nikito but has Google hacking strategies) and even WGET for a web spider tool. 

CMT - Testing for File Extension Handling

File extensions are used by web servers to identify different type of files and then distribute these files in a specific way depending on the type. For example, most web servers will force the user to download an mp3 or exe file, while allowing the user to view an image or html file in the browser.  File extensions can also give penetration testers information about the technologies used in the web application.  In other words, depending on how the server handle certain file type requests, we can then find some sever information. For example, if a PHP file ex executed, we know that PHP has been installed on the server. If we used a certain PHP5 function, and it fails the execute, we know that the server has an older version of PHP installed.

We can check for common used files and directories using vulnerability scanners such as Nessus or Nikito Scanner.  Other tools that can help us with this type vulnerability are web mirroring tools. 

CMT - Application Configuration Management Testing

Even if a system it self is absolutely  secure, a simple misconfiguration can lead to a security intrusion.  A lot of times, web applications come with a default configuration that are often not changed by the system administrator. For example, Microsoft IIS (Web Server) used to come with a sample site called Exair. This sample site was often kept in the server by the administrator. If the site was accessed directly multiple times, the CPU usage of the server will shoot to 100% and the site comes to a crawl. Another example of application configuration management testing is the failure to remove certain comments from the source code. For example, some times developers comment on HTML files with important information while the site is in development. If these comments are not removed before going live, then you are giving the public full access those important information.  Couple of ideas to prevent these problems are listed below

• Only enable server modules that you use (for example, if you don't use apache's SSL module, then disable it. This limits the complexity of the server)

• Replace all default error pages with custom made error pages so no server information is given out. This can be done with an .htaccess file in Apache.

• The server should be ran with just the right amount of privileges. If you give a server too much access, then a intrusion of the web server can lead to the downfall of the entire system.
• Logging should be setup for authentication passes and failures.

Lastly, the importance of logging should be stressed. Logging provides administrators with various types of information. However, we must make sure that logs are secure from attackers but viewable to the administrators.  For example, logs might contain GET information that has usernames & passwords. If an attacker somehow gets the logs, then user information has been compromised.  Logs should also be stored in a different location rather than the server it self. A lot of times attackers use a programmer called log zapper to completely wipe any trace of the attack.  Logs also can be used as a denial of service  weapon. If a attacker keeps attacking a system, and the server constantly creates logs - eventually, the system will run out of hardrive space.  So, we must either move the logs to a different server or limit the size of it.  Lastly, and if the attacker has not deleted the logs, we can use it to understand how we were attacked. For web server attacks, 40x errors happen due to a file not being found and 50x errors tells us that the application failed for whatever reason (perhaps, the failure of a SQL injection).

Sources:

http://www.iss.net/security_center/reference/vuln/iis-exair-dos.htm

http://ntsecurity.nu/toolbox/winzapper/

What is Gruyere

Gruyere  servers as a sandbox environment for  leaning penetration testing. Instead of just reading about XSS (cross site scripting), Gruyere allows us to actually do it. It allows for both black-box (penetration testing without access to the source code) and white-box (access to the application source code is given) hacking.

In order to use Gruyere, one must first go to the start page and be assigned a unique ID. This ID is pretty much your own "instance" of Gruyere. It is completely sandboxed so whatever you do does not affect other users and vice versa.

Once started, A person can use various methods to compromise the system. It can be used as a great learning tool and once I grasp basic XSS and XSRF knowledge, I will definitely have to try this out. 

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.

Configuration Management Testing - SSL/TLS Testing

Configuration Management Testing is simply analyzing the infrastructure of the web application.  There are a various ways of doing this but we will start with SSL/TLS Testing. Anytime we pass sensitive information online, the https protocol is used. Our goal is to find and detect weak ciphers ,and use it as a means to exploit the web application. One way to do this is through using NMAP (a application discussed in a previous post). Using the -sV scan option, we can identify SSL services (commonly found on port 443). 

Example:

Running the following line: nmap -sV XYXYXY.com on nmap scans available ports on the XYXYXY.com server to see which ones are open and being used. 

The results could be similar to the one below: 

Nmap scan report for XYXYXY.com(XX.YY.XX.YY)Host is up (0.040s latency).rDNS record for XX.YY.XX.YY: pNot shown: 976 filtered portsPORT      STATE  SERVICE     VERSI21/tcp    open   tcpwrapped22/tcp    closed ssh25/tcp    closed smtp80/tcp    open   http?443/tcp   open   ssl/https?554/tcp   open   rtsp?587/tcp   closed submission7070/tcp  open   realserver?

As one can clearly see, port 443 is open and is being used.  Unfortunately, to further investigate this setup, we  need software such as Nessus Scanner.

That being said, how does SSL/TLS work? When we connect to a https website, a secure connection is established between the browser and the server. Both parties identify each other through digital certificates. For the connection to work, the validity of the certificate must be checked. The three ways the validity is checked are:

1. Browsers come bundled with a list of Certificate Authority. If the the server certificate is unknown to the browser, then we might have a problem. When this does happen, the user is greeted with a message asking them if they want to allow this secure connection to occur. 
2. Certificates have a life period. In other words, even if the certificate is trusted by the browser, it must NOT be expired. 
3. Lastly, if the name on the certificate on the client and browser do not match? This problem usually arises with virtual host setup, but can easily be fixed by giving each website a unique IP address to match the certificate. 

Error Codes as a means for Information Gathering

Our next step is called Analysis of Error Codes.  In this stage, we are using common responses to certain errors as a way to get information.   One common error that pretty much all internet users has ran into at least once is the HTTP 404 error.

Example, if someone goes to the following url:  http://r.martint.net/asdads.html - they will be greeted with:

Not FoundThe requested URL /asdads.html was not found on this server.Apache/2.2.3 (CentOS) Server at r.martint.net Port 80

So, this error tells me the page is hosted on a Apache web server on port 80 running CentOS (Linux Variant).

Wen servers are not the only type of servers affected by this - people often use common errors from databases for penetration testing.  Some database errors can give us the IP Address of the database server, and then we try SQL injection to fool the server into authenticating our request.

Analysis of Error codes ends our discussion on Information gathering and now it is time to move on to configuration management testing.  More on this will be posted in the next post.

Penetration Testing #3

It's always good to know which applications are installed on a server before trying to exploit it.  Many applications already have existing vulnerabilities  and other applications are not updated by the company for various reasons.  Due to virtual web servers, many websites are hosted under one IP address. This means that to access a certain application, you would have to go through the DNS name rather than the numeric IP.  Finding all the web applications on a web server through whatever means is the definition of web application discovery.

Once we are given a target (a DNS name or IP address), there are three factors that influences finding  applications that are hosted on that target. First factor is a Different Base URL. The base URL is the target given to us (the DNS name). So if our target is http://google.com, the base URL is google.com, but what if the application is hosted on http://google.com/app1/?  Secondly, the use of non-standard ports. By default, people use port 80 for web servers , however what happens if people start using random ports? Lastly, we have the idea of virtual hosts.  That is, multiple domains pointing to one IP Address.  So, how do we find solutions for the above situations?

It's difficult to find applications if they are installed somewhere other than the base URL. The best way to find is through search engines (if application is on the internet) or through intelligent guessing (for example, a mail application could be installed in a directory called 'mail').  If an application is ran on a non-standard port, we can easily find it through running a port scanner like nmap. Lastly, the best way to combat the virtual host setup would be using a reverse IP tool such as the one provided by domaintools.com. The reverse IP tool works by just entering an IP address and it tries to list all the domains hosted on that IP address. 

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.  

Penetration Testing #1

A penetration test is one method of finding security vulnerabilities of a web application. It works by simulating potential web attacks. So the test is done from the perspective of a potential intruder. This means that the source code of the web application is not used as a resource to find weaknesses. Before continuing, it is important to know the relationship between a vulnerability and a threat. A vulnerability is a flaw or weakness in the application. A threat is an attack that exploits the vulnerability.

Penetration testing has two modes:
Passive mode: this is more information gathering. We are trying to find more about the system while also looking for access points of the application. We can use various tools for information gathering.
For example, let's say that a user is trying to login to a system with this url (http://example.com/?login=username=1&pass=2).
In the above system, there are two access points or gates: Username and password. 

The other mode is called Active Mode: This is were we actually do all the different type of penetration testing.
OWASP describes 9 different sub-categories for active mode testing

• Configuration Management testing 
• Business Logic Testing 
• Authentication Testing 
• Authorization Testing 
• Session Management Testing 
• Data Validation Testing 
• Denial of Service Testing 
• Web Service Testing 
• Ajax Testing 

For the rest of this blog post, I'll be focusing on the passive side. As mentioned earlier, the passive mode is all about finding information through various methods. Information gathering can be done by public tools such as search engines or private tools that can be used to connect to the application and send specific information requests. Even something as error messages can reveal a lot of information about the application (version #, database type, etc…). So just how do we find information? The next blog post will have more information about some of these methods.

The OWASP Testing Framework

Before any testing is done, an organization must create a testing framework that consists of "techniques and tasks that are appropriate at various phases of the SDLC" (44).  The activities in the framework should happen:

•  before development begins
• In this stage, it is important to have a solid SDLC already developed.  With a strong SDLC, one must also have the right policies, standards, requirements and documentation ready for the development team.  It is extremely important for the development to team know what exactly they are doing.

• during definition and design
• The requirements and documents that are made in the first stage must be logically tested to make sure they make sense.
• Once the design of a system is completed, it is important to create UML models for it. Models just help everyone in the project to understand how the system works.
• Using the system model, try to create realistic threat models. In other words, if we find a weakness in the system model, we should create threat models that describe how an intruder can penetrate the system - then, try to make sure these weaknesses are patched.

• during development
• The first step in this stage is to perform a code walkthrough where the developers walkthrough the system's code to the security team. This allows the security team to understand what is going on in the code.
• After understanding what the code does, the security team should now review the code to find security flaws.

•  during deployment
• Deployment testing consists of penetration testing and making sure the system is  correctly configured correctly. Although the application could be safe, the system could have been installed improperly.

•  maintenance and operations
• Period health checks should be done on the system as new security flaws could be found with the age of the system.
• If the system needs any changes, make sure the change is well documented and thoroughly tested before implementation.