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.