Authentication is part of what is commonly known as ‘‘triple A.’’ This stands for authentication, authorization, and accountability. An in-depth look at these concepts is beyond the scope of this book; instead, what should concern us here is whether any type of web page authentication has been discovered at
this point. Just consider the importance of authentication to the web site. If it is being used, it is most likely to protect sensitive areas. There are many different ways to authenticate users. Common authentication types used by web sites include the following:
Basic
Forms based Message digest Certificate
Basic authentication is achieved through the process of exclusive OR’ing (XOR). Basic encryption or encoding starts to work when a user requests a protected resource. The Enter Network Password box pops up to prompt the user for a username and password. When the user enters the password, it is sent via HTTP back to the server. The data is encoded by the XOR binary operation. This function requires that, when the 2 bits are combined, the results will only be a 0 if both bits are the same. XOR functions by first converting all letters, symbols, and numbers to ASCII text. These are represented by their binary equivalent. The resulting XOR value is sent via HTTP. This is the encrypted text. As an example, if a malicious individual were to launch some type of man-in-the-middle attack, he could most likely intercept the packet containing the basic authentication packet:
Authorization: Basic gADzdBCPSEG1
It’s a very weak form of encryption, and many tools can be used to compromise it. Google can be used to quickly find programs that will code or decode Base64. URLs for several such sites are provided here:
www.opinionatedgeek.com/dotnet/tools/Base64Decode http://makcoder.sourceforge.net/demo/base64.php www.motobit.com/util/base64-decoder-encoder.asp
The second type of web authentication up for discussion is forms based.
Forms-based authentication functions through the use of a cookie that is issued to a client. Once authenticated, the web application generates a cookie or session state variable. This stored cookie is then reused on subsequent visits. Because HTTP is a stateless protocol, cookies are needed. Just imagine going to an airline site to book a trip to visit a clients work site. You will be asked a series of questions:
Where are you flying from?
Where are you flying to?
What date to you wish to depart?
What date do you wish to return?
To keep track of all this information, the web server must set a cookie.
Problems arise with cookies when they are stolen or hijacked. The malicious individual can then use the cookie to spoof the victim at the targeted web site.
If the attacker can gain physical access to the victim’s computer, these tools can be used to steal cookies or to view hidden passwords. You might think that passwords wouldn’t be hidden in cookies, but that is not always the case.
It’s another example of security by obscurity. Cookies that are used with forms authentication or other ‘‘remember me’’ functionalities may store passwords or usernames in clear text or in a Base64 format. Here’s an example:
Set-Cookie: UID= dWlrXTataWtlc3Bhc3N3b3JkBQoNCg; expires=Mon, 08-Aug-2008
The UID value appears to just be random numbers or some type of coding.
However, if you run it through any one of the Base64 decoders discussed previously, you will actually end up withmike:mikesp@ssw0rd. This should make it clear that it is never a good idea to store usernames and passwords in a cookie, especially in an insecure state. If you want to take a look at some cookies yourself to see what is in them, go to the following sites:
Cookie Spy—http://camtech2000.net/Pages/CookieSpy.html Karen’s Cookie Viewer—www.karenware.com/powertools/
ptcookie.asp
Seeing how weak Base64 is makes us aware that there must be a better method, and there is: message digest authentication. Message digest uses the MD5 hashing algorithm. Message digest is based on a challenge-response protocol. It uses the username, password, and a nonce value to create an encrypted value that is passed to the server. The nonce value makes it much more resistant to cracking and makes sniffing attacks useless. The message digest process is described in RFC 2716. Think of it as a one-way type of process. A friend once said a hash was like running a pig through a grinder to get sausage. The sausage is not easily reconstituted into a pig. While it was an unusual explanation, it helped me always remember that it’s truly one-way! An offshoot of this authentication method is NTLM authentication.
This propriety Microsoft authentication scheme is discussed further in Chapter 5, ‘‘Enumerating Systems.’’
Another strong form of authentication is certificate based. Certificate-based authentication is by far the strongest form of authentication discussed so far.
When users attempt to authenticate, they present the web server with their certificate. The certificate contains a special type of authentication known as a public key and the signature of the certificate authority. The signature works much like a notary does in real life in that it verifies the authenticity of the signer. The web server must then verify the validity of the certificate’s signature and then authenticate the user by using public key cryptography.
For more about this concept, see Chapter 7, ‘‘Understanding Cryptographic Systems.’’
IN THE LAB
The risk from cookies is that they may provide too much information. You can mitigate these risks by reducing the number of cookies your system will accept and periodically removing them from the browser cache. In the lab, you will want to download and install Cookie Spy, available at http://camtech2000 .net/Pages/CookieSpy.html. Once installed, point it to the folder of your browser cache and start looking through existing cookies. If your organization is using cookies on its web server, you will want to closely examine what and how they are being used. Watch for any cookie that may be used incorrectly for authentication.