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.