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.