Authentication Testing - Credential Transport for an Encrypted Channel

We're moving from configuration management testing to authentication testing. In this scenario, we are trying to make sure the "right" person is sending/transmitting the "right" data. One way to make sure of the validity of data is sending through a secure channel. A practical example of the importance of data encryption is when we log in to various websites. Even if the website uses a POST method to "hide" the user name and password, the parameter values can still be retrieved through sniffer tools. How do we prevent this from happening? Through the use of the HTTPS protocol. When a site uses HTTPS, the login data is encrypted and assuming the encryption method is strong, this makes sniffing the account details much tougher.

Tools that can aid potential hacker retrieve account details include WireShark and WebScarber.
So to quickly summarize - if there is a login aspect to your site, make sure the POST method is used along with having an HTTPS connection.

CMT - Testing for HTTP Methods and XST

The HTTP protocol has a bunch of methods used for interacting with the web server. Most people only know of the POST (parameters values are hidden in the HTTP request) and GET (parameter values can be seen in the URL) methods. However, there are  6 more methods in existence.  These include  HEAD, PUT, DELETE, TRACE, OPTIONS,  & CONNECT.

The PUT (allows clients to upload files), DELETE (allows client to delete files) , CONNCT (allows clients to use the web server as a proxy server to connect to other servers)  and TRACE methods should be disabled by all web servers unless it is specially needed.

For a hacker to take advantage of this, he or she must first know which methods the server supports. OWASP Testing guide states that this can be done through a program called NETCAT . Once this program is downloaded and installed, one simply has to run the following command: nc -v www.domain.com 80.  Unfourenelty, this method did not work for me and I kept running into the following error.

DNS fwd/rev mismatch: www.domain.com  hostname.domain.com
www.domain.com [xxx.xxx.xxx.xx] xx (http) open.

The next couple of days, one of my goals will be to try to get this this working since it seems like a valuable tool.  Lastly, the guide provides more information on cross site scripting using the TRACE method, but due to the NETCAT not cooperating with my computer,  trying this out will have to wait a few days.

CMT - Infrastructure and Application Admin Infrastructure

A lot of web applications have an administrators area/panel for easier managing and control of the application.  Ideally,  this area should only be accessed by people with the right privileges, however, there are situations where unauthorized or standard users are able to access the area and perform undesired actions.

Some times, when accessing the admin area, no authentication takes place. In other words,  access is given to anyone who access the supposed "private" URL.  Hackers can guess the location of this area through various methods. These includes trying common directories such as /admin and /administrator or  viewing the comments and html code of a public page for administrator specific code.

The best way to prevent unauthorized access is to both force authorization/authentication upon logging in and also limited the area to specific users/IP address/network range. 

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.