Re: IIS 5 cookie encryption password

[Santiago Barahona <sant-bar () dsv su se>]

check out:

http://tools.ietf.org/html/rfc3257
http://cr.yp.to/syncookies.html


"SYN cookies are particular choices of initial TCP sequence numbers  
by TCP servers."
The first sequence number sent can be any value as decided by the  
sender... right?...   many use zero as the initial sequence number...  
however it seems that the SYN cookies are initial sequence numbers  
that are carefully constructed according to the following rules:

t = A counter incremented every 64 seconds
m = The Maximum segment size value that the server would have stored  
in the SYN queue entry
s = The result of a cryptographic secret function computed over the  
server IP address and port number, the client IP address and port  
number, and the value t. The returned value "s " must be a 24-bit value.
The initial TCP sequence number, i.e. the SYN Cookie, is computed as  
follows:

First 5 bits: t mod 32
Next 3 bits: an encoded value representing m
Final 24 bits: s
The server then performs the following operations.

Checks the value t against the current time to see if the connection  
is expired.
Recomputes s to determine whether this is, indeed, a valid SYN Cookie.
Decodes the value m from the 3-bit encoding in the SYN Cookie, which  
it then can use to reconstruct the SYN queue entry.
From this point forward, the connection proceeds as normal.






On 3 Apr 07, at 18:32, Serguey Forcade wrote:

Thanks, but I based my assumptions on an article from Microsoft
(http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/ 
iisbook/c06_asp_session_id_and_session_security.mspx?mfr=true)

Even tho your statement makes sense. It's just that I haven't been
able to find more info about the relationship between the session ID
and the cookie.

On 4/3/07, Rogan Dawes <discard () dawes za net> wrote:
> Serguey Forcade wrote:
> > Hi, I'd like to know if anyone knows of a paper that explains how to
> > extract the encryption password IIS creates when it starts up, and
> > uses to encrypt the session ID + random data in order to generate  
> the
> > cookie value the users receives.
> >
> > I'm interested in IIS 5.0.
> >
> > Thanks.
> >
>
> Take this with a pinch of salt, but I don't think that the session
> identifier and the cookie value are directly related.
>
> One reason for this statement is that if you abandon the session  
> (using
> ASP), and create a new one, the cookie value does not change. However,
> the result of "Session.SessionID" DOES change.
>
> I suspect that the cookie value is generated using a combination of  
> some
> static/sequential info, and some random data, and then associated with
> the next available (i.e sequential integer) SessionID. When the  
> session
> is abandoned, the session object associated with that integer  
> SessionID
> is discarded. A subsequent request from the client containing the old
> Session Cookie value will then automatically be associated with the  
> next
> available sequential integer SessionID.
>
> Hope this helps.
>
> Rogan
>
> P.S. One consequence of this inability to change the cookie value
> through abandoning the session is that ASP apps are AUTOMATICALLY
> vulnerable to Session Fixation
> <http://www.owasp.org/index.php/Session_Fixation>. An approach to
> protecting ASP apps against session fixation is shown here
> <http://www.owasp.org/index.php/Session_Fixation_Protection>

------------------------------------------------------------------------ 
-
Sponsored by: Watchfire

It's been reported that 75% of websites are vulnerable to attack.  
That's because hackers know to exploit weaknesses in web  
applications. Traditional approaches to securing these assets no  
longer apply. Download the "Addressing Challenges in Application  
Security" whitepaper today, and see for yourself.

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fHF
------------------------------------------------------------------------ 
--



-------------------------------------------------------------------------
Sponsored by: Watchfire

Today's hackers exploit web applications to expose, embarrass and even 
steal. Firewalls and SSL may be commonplace but recent studies indicate 
3 out of 4 websites remain vulnerable to attack. Watchfire's "Addressing 
Challenges in Application Security" whitepaper, explains what to do and 
provides a guideline to improving your own application security. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fHF
--------------------------------------------------------------------------