Archive for June, 2006


June 30, 2006

DEFCON 14 is quickly approaching.

This year it will be held on the first weekend in August – Friday, August 4th to Sunday, August 6th.

For those who don’t know about DEFCON, it is a 72 hour caffeine-induced hackfest held in Las Vegas every year. It is the place to be for Black Hat, White Hat and Grey Hat hackers.

Dmitry Sklyarov was arrested at DEFCON 9. He was arrested on July 17, 2001 in Las Vegas at the behest of Adobe Systems because he wrote a program for his employer that cracked Adobe’s eBook DRM software. He then gave a DEFCON presentation about it and was arrested shortly thereafter.

You can read about his hard luck story here.

The underground hacker community is interesting. There’s the usual cast of characters, Kevin Mitnick and Dark Tangent but also hacking associations such as, Cult of the Dead Cow and L0pht (pronounced "loft").

I’ve never attended a DEFCON but hope to catch it one of these years.

The security industry definitely keeps the hackers on their toes.

The cycle of evolving security techniques and strategies being implemented by developers and system administrators to thwart malicious black hatters is endless.

One of the most difficult web application vulnerabilities to guard against is session hijacking.

It’s a classic web hacking technique that exploits the statelessness of the HTTP/HTTPS protocol. The attack occurs when a hacker impersonates a user and then hijacks the session ID.

There’s two approaches to hijack a session are:
  •  Guess the Session ID and
  •  Steal the Session ID Cookies

1. Guess the Session ID

This is a simple brute force technique that involves collecting a sample of session IDs and "guessing" a valid session ID that is assigned to someone else. It is similar to password guessing programs. However, in this case, Session ID guesses are made and submitted continuously until a success occurs or the session ends.

Fortunately, most new web apps are not susceptible to Session ID Guessing because the Session IDs are implemented using highly random 120-bit numbers.

2. Steal the Session ID Cookies

The other common technique is to steal the Session ID Cookie. This is more difficult to defend against because there are many creative ways to steal it.

A Session ID Cookie is an HTTP cookie that contains a Session ID.

An HTTP cookie is a packet of information sent by a web server to a web browser and then sent back by the browser each time it accesses that web server. The cookie is stored in memory and eventually persisted to a file located in the browser’s file cache.

The cookie data exchange is the most common way a web server tracks previous requests.

Most servers store the unique Session ID in the cookie. The unique Session ID corresponds to data on the web server.

Whenever the user sends a request with cookie containing the Session ID, the server:
  •  Parses the cookie
  •  Extracts the Session ID
  •  Associates Session ID to some data
  •  Uses data to re-inflate the Session Object

For most hackers, executing a successful session hijack attack with a stolen Session ID Cookie is trivial.

It is trivial because the Session ID Cookie is simply an encoded Session ID with no other information.

A good defensive measure is to encode additional information (e.g., requestor IP address, user-agent header and maybe a secret key from the server) to validate the user.

I will discuss more tactics / coding strategies in a later blog entry.

In any case, please note that the key item to protect to thwart a Session Hijack is the Session ID.

To be continued…