Final Video for Directed Study

So, I have been working on a simple guide/tutorial video on brute forcing.
It's my first time making a video and I think it turned out decently well.  Camtasia trial was used in the making of the video.

Cross Site Scripting (XSS)

 The whole idea behind XSS is that a hacker can inject client-side code into a website and when the website is viewed by other users - the code executes and harms the innocent users.  As you can guess, the main reason this type of attack occurs is due to the lack of data validation. XSS attacks can be broken down into 2 subgroups: Stored & Reflected XSS.  Stored XSS is when the malicious code is permanently stored in the website so either in the database, the actual site or  logs.  Reflected XSS relies on "tricking" the user into going to a specific "trusted" website where the malicious code could exist in error messages or even search results.

 The pie graph above tells us that XSS is #2 behind SQL Injection in terms how sites are hacked. 

note: Due to projects & presentations, I am not able to post much - however, starting next week, I will try to post a bit more about XSS & SQL Injection.

Data Validation Testing

OWASP believes the most common type of security weaknesses comes from failing to validate client input. This failure causes XSS issues, SQL Injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.  In fact, Michael Howard - the author of Writing Secure Code - once stated that "all input is evil".  Usually, the larger an application becomes, the harder it becomes to enforce validation.

I decided to do some further research on data validation and ended up reading a small article from Smashing Magazine.  This article talks about validating user submitted web data to make sure it is the correct format. Basically, Data can be either validated on the client or on the server and there pros and cons for both.  Applications validating data on the server-side uses a strong server-side language instead of a client language like JavaScript.  So, even if the client has disabled JavaScript on their browser, the data will still be validated. The disadvantage of server side validation is that it takes longer and if there are too many validations being conducted - it might bring your server to a crawl.  Client-side validation should be done if you want a "more responsive [and] visually rich validation".  Basically, the validation can take place before the form is even submitted and thus users get immediate feedback on whether the data is valid or not.  The main disadvantage is that since we're using JavaScript - a client can easily disable it and no validation will take place which means there will be incorrect data in the database. 

Session Management - CSRF Attacks

I decided to skip some of the sections about cookies and directly go to the CSRF attacks simply because I have no previous experience with these attacks and would like to know more about them. OWASP Defines these attacks as ones "which forces an end user to execute unwanted action on a web application in which he/she is currently authenticated". So basically, we trick the admin into executing harmful code. The concern with this exploit is that often times the admin does not even know he or she is being tricked into executing code.  In fact, even going to a simple and relatively safe website can cause the code to execute.  How does this work?

Let's a you get an e-mail telling you to visit a website. The website has the following code:

<img src=”https://domain.com/picture.gif” width=”0” height=”0”>

Seems harmless right?  Well, domain.com/picture.gif can easily be redirected to http://baddomain.com/badCode.

How do web prevent this from happening?

OASP Recommends the following actions.

• Logoff as soon as your done administering.

• Don't allow your browser to save usernames & passwords

• Do not use the same browser to access sensitive information as you use to surf freely on the internet.      

Cookies Continued...part 3

Now since we have a general idea of Cookies, it's time to reverse engineer them. But before we do this, we must first understand how to provide "a secure method of session management". In other words, how do we keep our cookie safe? Well, the first step is to make the data "hard-to guess" or unpredictable. In doing this, we are making it hard to forge the cookie which makes it harder to break into another user's session. To make it unpredictable, we have to create random values or cryptography.  Second step is to make it tamper resistance. Having a cookie with a parameter isAdmin and value "no" is not smart. It is extremely easy to temper with and change the "no" to  a "yes".  A better way of doing it is encrypting the  parameter and value.  Third step would to make sure the cookie does expire at a certain point. Make the cookie only exists in the time period that it should. Lastly, for important cookies, make sure to use the secure flag so transmission of the cookie can only occur in an encrypted channel.

If an application follows the above guidelines when generating cookies, it will be extremely difficult for hackers to temper with the cookies. Unfortunately, some cookies are not this safe and that is why reverse engineering can be done. The basic premise is that we get a handful of cookies from a website and look for patterns.  When collecting cookies, make sure the website is in the same state for all cookies collected. For example, if the first cookie collected was right after authentication, then the rest of the cookies of the sample as to be collected at the same time.  It is also important to note down the time when the cookie was collected. As stated in the last post, the time the cookie was created can be part of the cookie value.

When looking to reverse engineer a cookie, it is good to know the value of type or types. Many times, a cookie can hold numerous values of different types.  Below is an example of a cookie.

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q

In the next post, we'll break down what each part of the cookie means.

Cookies Continued...pt2

So our first step is cookie collection. In here we're trying to figure out to answer some basic questions such as :

• "how many cookies does the application create?"
• The way I did this is by first clearing all the cookies in my browser, and then visiting the application. Then, I check the cookie list.  Doing this tells me about all the cookies created when accessing the application.

• "which parts of the application generates a cookie?"
• Go to different parts of the web application and check the browser to see if any cookies are created.

• "which parts of the application causes a modification of the cookie?".
• Same as above - when we're messing around with the application, see if the status of any of the cookies has changed.

Our next step is to analyze the cookie. For example, look at the session ID of multiple cookies. Are they just linearly made? Are they random? Does duplicates exists?  We can also examine the value of the cookie. Often times, developers make the mistake of storing actual sensitive data in the cookie. What their actually suppose to do is store a generic value and reference the real data using the generic value. Some developers store real data in cookies and just encode various methods like Hex, Base64, or MD5. What they fail to understand is that these strings can easily be decoded and the real data can be seen by unwanted eyes.

If  tokens are in fact encoded, they could contain multiple sets of data in one long string. For example, if the token is 32 bit string, the first 16 bits could represent something static like a username or IP address and the next 16 bits could by dynamic. If this second 16 bit string changes incrementally, this could represent a date or time for each access.  One way to verify this is access the site at the same time using different browsers and using the same username/IP address. In that case, the cookies from each browser should be almost the same. 

Session Management Testing & Cookies

Session Management is how web application maintains and controls all user-interaction within the application. From authentication and logging off  - sessions are used to control all interactions between clients & servers. Client-server sessions are identified through a unique token often referred to as a Session ID or Cookie. Just like everything else on the web, sessions can be exploited and one such way is by using the created session by an authorized to our advantage.

If session IDs/Cookies are created in a predictable way, we can easily duplicate a valid cookies to "hijack the sessions of legitimate users".

So, first why are cookies used? Their used because they are an easy way to keep track of a client through multiple requests. It's how companies keep details about a certain client.  Cookies will last until they expire or they are destroyed (by server or client). OWASP describes the main advantages of as giving "a state to a stateless protocol like HTTP".  They store vital information for websites and thus can be a target for hackers.  The list below describes the patter for "cookie hacking".

1. Collect information about the cookie. Make sure to get a good sample

2. Perform cookie reverse engineering - in other words, try to figure out the cookie generation algorithm.

3. Manipulate cookies - once we figure out the algorithm, we can try to forge a valid cookie to attack the server.

Since the topic of Cookies and sessions is broad, I want to limit the size of my posts - I will continue on in the next post.

Auth. Testing - Testing for Captcha

CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart. So basically, it exists to prevent responses & requests from bots.  The use of CAPTCHAs makes the word of a hacker much harder because the process becomes much slower.  For example, having Captchas in a login page helps limit bruteforcing attacks. In fact, having Captchas in any GET/POST requests "provides a rate limiting function".

Captcha's can be decoded and in some cases they are subjected to replay attacks.  This occurs when the application does not keep track of "What ID of Captcha image is sent to the user".  So a hacker can just decode it, and send the ID and decoded value to the application within a bruteforcing program.

If one captcha system has been broken, it means any captcha created by that system can be decoded. WASPS lists the following places to find decoded Captchas.

• Gimpy
• PWNtcha
• lafdc

Authentication Testing - Testing for Vulnerable Remember Password & Password Reset

Most modern web application has a way for users to reset their password through "security questions". Apps also tends to have a "remember password" feature.  In this test, we check to see if these two features are properly implemented.

The main problem with using security questions for password resets is that often times, the security questions are really not that personal. For example, "your mother's main name" is a very common yet terrible question. A mother's maiden name can easily be retrieved by a hacker. A better question could be "What was your 2nd grade teacher's name".  The problem with saving passwords to the browser is that anyone who has access to that system can use the  account.

So, how does one exploit these features?  Well to exploit the password reset feature, we must first see if the reset process even requires a secret question. Sometimes, the reset password process just sends a new or the old password the e-mail address on file. This means that if the e-mail account is compromised, the password can easily be retrieved. If secure questions are used, we then must asses the strength of the questions. We do this by figuring out how many questions must be answered and also the strength of the question. A lot of times, a user is given the option of choosing 1 or 2 questions from a question "bank". We can take advantage of this by choosing the questions that can easily be answered with a little bit of research.  

Authentication Testing - Testing for Bypassing Authentication Schema

Although for most applications, authentication leads to access -  there are certain cases were an intruder can just bypass the login page and directly access the "private" information.   This can be done through four different ways. Direct Page Request, Parameter Modification, Session ID Prediction, & SQL Injection.  Direct page requests occurs when the code checks for authentication only on the login page. Every other page in the administrator's does not check user credentials and thus can be accessed by just putting in the URL in the browser.  The second way to bypass authentication is through a modification of the URL parameter.  Some times, web apps uses fixed value parameters to signify a successful authentication.  So for example, we can easily change http://domain.com/admin/index.php?authentication=no  to authentication=yes. Then after resubmitting the data to the server, we should be in the admin panel.  The third way of bypassing authentication is through predicting an admin's session ID. Some web apps uses Session ID's as a means to manage authentication. The problem with this is that sometimes these session ID's just increases linearly which means it is easy to predict. We can get the correct session ID by using a bruteforce attack. Lastly, SQL Injection is another way of bypassing authentication. Due to the popularity of the topic, this will be covered in a future post. 

Auth. Testing - Testing for Logout & Browser cache Management

This test ensures that once a user "logs out" - they are actually logged out and it is not possible to reuse the user's session.  Secondly, we check to see if there is a timeout feature where after X amount of idle activity - the user is automatically logged out. The application must work in a way where once logged out, all session tokens (cookies) are either erased or made unusable.  Usually, we just want to make it unusable by rejecting the use of the cookie on a server level.

To properly assess this type of exploit, we must first find out what happens after a user logs out. Are session cookies erased? Are they made unusable? The easiest way to do this is by logging out, and then clicking the browser's back button. Are we still authenticated? In that case the cookies are still being used and can be exploited. If after clicking the back button we can still see visited pages but not access any new pages - it means that the private information was cached. The page allowed the browser to cache the content by "not setting the cache-control header".

It is important to have some type of server side code that prevents the reusing of old cookies.  Since cookies exists client side and can be edited by users, simply changing the values of the cookies to make it unusable is bad practice. We need to completely disallow an inactive cookie from doing any type of authentication.

How to Edit Cookies in Chrome.

Authentication Testing - Testing for Brute Force

The topic of brute forcing has always interested me due to its simplicity.  The whole idea is that you have an enumerated set of "candidates" or options and then through simple trial and error see which of these candidates will solve the situation. So, let's say a hacker is trying to retrieve the username and password for the administrator's panel of a website.  Using bruteforcing tools, he or she can automatically try out all the credential candidates. If the candidate list is somewhat accurate, the hacker can get the correct username and password in a certain period of time.

There are different bruteforcing techniques in existence and a specific technique must be used depending on the "authentication method used by the application" (131).   The two most common authentication methods used by apps are HTTP Authentication and HTML Form-based Authentication.  Within HTTP Authentication, there are two sub methods which are called Basic Access Authentication and Digest Access Authentication.

With the Basic method, the client first sends a request (going to the protected site area via a browser). Then the server sends a response stating that the location is a protected and sends the client a HTTP 401 Authorization. 

The 401 Authorization response has the following header.

HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm" Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

 The "User Realm" is the protected area and the line also contains the word Basic which tells the potential hacker the type of authentication used.

The 401 Authorization response also opens a username and password window.  The username, colon, and password is base64 encoded and then sent to the server.  If the credentials are right, then the client has access to the web site.   The main problem with this method is that if an attacker gets a hold of that encoded string, he or she can easily decode it to reveal the username and password. This is the primary reason for the existence of the Digest method.  With Digest,  the password is hashed through MD5. The username is sent to the server in plaintext form.   

Although digest is relatively safe, a lot of web apps uses the html form-based authentication method.  Basically, this means the login process is done trough an HTML form.

Now it's time to talk about the different kinds of bruteforcing attacks. The first one is called a dictionary attack.  In this attack, a bruteforcing program uses a file containing possible usernames and passwords to repetivitly attempt to login to the app. The more detailed and concise the dictionary, the faster a sucessful login will take place. In search attacks,  the program attempts all possible combination of a given "character set and givven password range".  Lastly, in a rule-based search attack, the program uses certain rules to generate good login/password "candidates". For example, if we know the password is 5 characters, and the last three characters are "cat", can setup a rule that tries every possible combination of letters and numbers to get the full password.

Some tools used for bruteforcing:  John The Ripper, Brutus, THC Hydra

Authentication Testing - Default or Guessable (dictionary) user account

Nowadays, web applications used are open source and/or extremely popular and relatively well known.  They also require some type of minimal configuration by the user to be properly setup. Unfortunately, plenty of people misconfigure their web apps leading to certain security issues. For example, certain web applications come with a default username and password. Part of the configuration process is to delete this username and password and create another administrator account.  People don't like doing this and thus a lot of web applications exists with default usernames and password ready for some attacker to completely take control of it.

Some common usernames and passwords are listed below:

• Usernames
• Admin, administrator, root, system, guest, operator, super, qa, test, test1, testing.

• Passwords
• <completely blank password>, password, pass123, password123, admin, guest.

Some times, usernames are named after the application it self. So if we are trying to penetrate an application called "SystemKeeper"  - one should try systemkeeper as a username and perhaps also the password.  Another way to do find a password is looking at the source. Poorly programmed applications might have the username  visible in the source.

CIRT, GovermentSecurity.org, and virus.org provides the default usernames and password for various applications and devices.

Authentication Testing - Testing for Enumeration

The whole point of this phase is to see if can retrieve valid usernames. The usernames can help improve the effectiveness of other security attacks (bruteforcing, social engineering, etc…). Web applications tend to reveal existing usernames in different ways. For example, if I try to register and type 'martin' as the username, the application might sent out an error that states that the username already exists. If an attacker does this for a while, he or she can have a long list of valid usernames.  Another way to retrieve usernames is by trying to login to the system. If I try the username "martin", and a random password - the application might print out an error saying "Sorry, you entered the wrong password". This pretty much tells us the username is completely valid. Lastly, some other ways of looking for valid usernames includes :

• Analyzing Page titles - Invalid User and Invalid Authentication could mean two different issues.

• Analyzing Message for credential recovery facilities - basically, using the "forgot password" or "forgot username" parts of a website to figure out which usernames are valid or not.

• Guessing usernames - Sometimes, usernames are in sequential order (ex, LabUser1, LabUser2).

A Complete OWASP Checklist

As I wandered throughout the Internet looking for why NETCAT was not working on my laptop, I ran into a spreadsheet that potentially can help me in the future. This checklist has three worksheets.
The first worksheet serves as checklist of all the tests one must do to make sure a website is secure. The checklist is extremely interactive and can help me keep track of everything. The second worksheet summarizes all the categories of testing, the names of each test per category, a description of each test, and lastly the tools used for testing. Finally, the third worksheet provides a list and description of various testing tools.

The spreadsheet was last updated in October of 2011 and can freely be downloaded from its Google Code Site.

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. 

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.

Foreword, Frontispiece & the OWASP Testing Framework (pages 7-44)Foreword, Frontispiece & the OWASP Testing Framework (pages 7-44)

Foreword
What’s limiting our technological advancements is the security aspect of it. The goal of the Open Web Application Security Project (OWASP) is to take out this limiting factor so technological improvements can continue to progress.  To do this, OWASP created the Testing Guide (v3) for software developers, software testers, and security specialists (IT Audit companies).  It is important for people to actually understand security issues rather than relying on automated tools.  Automatic tools are a great asset to have if they are used as a supplement rather than fully relying on them.  This is due to the fact that generic tools are not to find issues in custom code (ex, applications), but rather, they are suited for an already defined environment (ex, network security).
Frontispiece
OWASP recommends that when viewing application security, we must view it as a “people, process, and technology problem because…security includes improvements in all those areas” (14).
OWASP describes testing “as a process of comparing the state of a system/application against a set of criteria” (16). OWASP wants developers, testers, and specialists to all understand the “criteria” before any testing begins. Testing should be done as a means to eliminate the differences between a company’s security practices and that of the industry’s best practices.
So when should the testing process begin? Surprisingly, most people only test applications once it has been deployed (code already created).  This not only increases headaches, but also costs. OWASP recommends that security testing be done at each phase of the project’s SDLC.
Once security is implemented, we must decide what exactly should be tested. OWASP recommends that we take a holistic approach and test not just the software (technology), but also the people and processes. A lot of companies just test the technology, which leads to problems down the road when the companies’ people and process could include security risks in the technology. This approach “eradicates bugs early and identifies root causes of defects “(17).
Before any testing occurs, one must first understand the principles of security testing
1. There is no silver bullet – There is no one service or a tool that can fully keep your application secure.
2. Think Strategically, not Tactically – Don’t use the patch-and-penetrate model (fixing a bug, but not reporting the root cause of it).
3. SDLC Is King – it is extremely important to incorporate security into each phase of the SDLC.
4. Test Early and Test Often – Find common security issues and test them in each phase of the SDLC.
5. Understand the Scope of Security –  Information needs to be classified depending on how important/valuable they are. For example, personal information should be treated with due care.
6. Develop the right mindset – You have to think outside the box to find some security vulnerabilities. Think like an intruder rather than the average user. Automatic testing tools lack the ability to think outside the box.
7. Understand the Subject -  Accurate documentation of an application must exist (data-flow diagrams, use cases). It is also important to have some type monitoring system setup to monitor intrusions.
8. Use the right tools – Although tools are not perfect, they do help “automate many routine security tasks” (20).
9. The Devil in the Details – Don’t just breeze through the security testing. Go into every possible “section of  [the] application logic” (20).
10. Use Source Code when Available – You shouldn’t just always do a black box testing. Since the source code is there, use it find security flaws.
11. Develop Metrics - it is important to quantify the results to make sure the security testing is actually doing its job.
12. Document the test results - All testing results should be documented for "developers, project managers,  business owners, IT department, audit and compliance" (20). This will allow the right person to make the right decision moving forward.
Testing Techniques
1. Manual Inspections & Review
1. It's the idea of talking to the system owner or looking at the system documentation  and finding out "how something works and why it was implemented a specific way" (21). It's a way to make sure the SDLC works as desired and has  the right policies in place. Identifies threats during development of the system.
2. Threat Modeling
1. Is the idea of finding out potential threats that the web applications could face and allocating resources to  mitigate these threats. Identifies threats during design of the system.
3. Code Review
1. It is one of the best way to test for security concerns. It is the idea of looking at the source code and finding inherent security flaws. A lot of threats cannot be found with simply a black box approach.  Identifies threats during development of the system.
4. Penetration Testing
1. Is the idea of testing an application or network from a user perspective. Source Code is not given and thus this testing is akin to how most hackers will try to penetrate the system. Although it works well for networks and operating systems, it is often a poor choice for application testing because  applications are always custom coded (bespoke) and different exploits exists in different applications.
Which testing to use?
1. OWASP  recommends in using a balance approach (using a combination of the above techniques) when trying to test for security flaws because it will "cover testing in all phases of the SDLC" (25).  Most of the testing should take place in the early stages of the SDLC (define, design…) with emphasis on manual inspections & review and  code review. Again, black box testing is not recommended for web applications.
What are the objectives of testing?
1. The objectives of the testing are placed in the security requirements document . The content of this document derives from our business requirements. For example, if our business is selling products online, then we must have security guidelines to product customer data and also comply with government regulations.  We validate our security requirements document by testing it at various stages of the SDLC.

Tentative Semester Reading Schedule

1.       Pages based on pdf from: OWASP Testing Guide v3

Foreword, Frontispience & The OWASP Testing Framework

a.       Pages (7-43)

                                                              i.      Deadline: January 27, 2012

2.       Web Application Penetration Testing (4)

a.       Pages 44-99

                                                               i.      Deadline:  February 3, 2012

b.      Pages 100-142

                                                              i.      Deadline: February 10, 2012

c.       Pages 143-166

                                                              i.      Deadline: February 17, 2012

d.      Pages 167-181

                                                              i.      Deadline: February 24, 2012

e.      Pages 182-213

                                                              i.      Deadline: March 2, 2012

f.        Pages 214-239

                                                              i.      Deadline: March 9, 2012

g.       Pages 240-261

                                                              i.      Deadline: March 16, 2012

h.      Pages 262-281

                                                              i.      Deadline: March 23, 2012

i.         Pages 282-300

                                                              i.      Deadline: March 30, 2012

j.        Pages 301-326

                                                              i.      Deadline: April 6, 2012

k.       Pages 327-345

                                                              i.      Deadline:  April 13, 2012

3.       Writing Reports + Appendix (5) – (346-369)

a.       How to Value Real Risk

b.      How to Write the report of the testing

c.       Appendix

d.      Deadline: April 20, 2012