Re: Cookie stealing and replay in a corporate single sign on environment

[Irene Abezgauz <irene.abezgauz () gmail com>]

> > > Similarly, I often hear "the SSO cookie is encrypted".  That doesn't
matter
> > > either.  I just need to replay the encrypted cookie "blob" in an
attack.

That's what I referred to in my email, I apologize if I somehow got you
wrong. Naturally SSL won't prevent applicative attacks such as XSS, I was
only referring to the replaying part.

Irene

Irene Abezgauz
Application Security Consultant
Hacktics Ltd.
Mobile: +972-54-6545405
Email: Irene () hacktics com
Web: www.hacktics.com

----- Original Message ----- 
From: "Willard Fernortner" <fernortner () hotmail com>
To: <irene.abezgauz () gmail com>; <webappsec () securityfocus com>
Sent: Wednesday, June 15, 2005 5:34 PM
Subject: Re: Cookie stealing and replay in a corporate single sign on
environment


> Irene,
>
> I think you missed my point about SSL not being able to protect SSO
cookies.
>   I'm really not concerned about someone stealing cookies by sniffing
> network traffic (which is what SSL would protect), but rather I'm
concerned
> that Cross Site Scripting flaws can be used to steal cookies EVEN when SSL
> is used.  SSL simply cannot stop cookie stealing via Cross Site
Scripting...
> it only ensures that nobody can see the exploit as it travels through the
> SSL tunnel.
>
> WF
>
>
> > From: Irene Abezgauz <irene.abezgauz () gmail com>
> > Reply-To: Irene Abezgauz <irene.abezgauz () gmail com>
> > To: Willard Fernortner <fernortner () hotmail com>
> > CC: webappsec () securityfocus com
> > Subject: Re: Cookie stealing and replay in a corporate single sign on
> > environment
> > Date: Wed, 15 Jun 2005 13:50:43 +0200
> >
> > Willard,
> >
> > To me SSL seems like a good solution to the problem of replaying attacks.
> > The cookie is never sent individually but is encrypted together with
> > the request as a whole, meaning you cannot just "extract the cookie
> > part" and then replay it. You could say that since you know the size
> > of the encryption block you could guess where the cookie is (however
> > unpractical that may seem). And yet, if you guessed where the cookie
> > is and extracted it, and even if theoretically the cookie is floating
> > around between the servers holding a note saying "sniff me", it won't
> > help since each individual SSL connection has a different set of keys
> > so you can't just send it in your own connection.
> > If the servers don't use SSL among themselves - it is a problem, not a
> > cookie related problem but generally "A Problem".
> >
> > Irene
> >
> >
> > Irene Abezgauz
> > Application Security Consultant
> > Hacktics Ltd.
> > Mobile: +972-54-6545405
> > Email: irene () hacktics com
> > Web: www.hacktics.com
> >
> >
> >
> > On 6/15/05, Willard Fernortner <fernortner () hotmail com> wrote:
> > > I'm wondering if anyone else has given thought to cookie replay
attacks
> > when
> > > using a web single sign-on solution on a corporate network.  Here are
my
> > > concerns:
> > >
> > > -- Web single sign-on typically works using a shared cookie that is
> > passed
> > > to all intranet web sites in the corporate domain (e.g.
> > *.myintranet.com).
> > > Because these cookies are passed to ALL internal web sites, there are
> > plenty
> > > of opportunities for these cookies to be stolen:
> > >
> > >   a) They can be harvested by employees, contractors, or anyone else
> > that
> > > is allowed to publish a web page to ANY corporate web site (through
> > server
> > > log files or through JavaScript on published web pages)
> > >   b) They can be stolen using a cross site scripting flaw on ANY web
> > site
> > > in the corporate domain
> > >
> > > -- Once an SSO cookie is stolen, the attacker can use that cookie to
> > > impersonate the victim to HR, financial, or other sensitive web
> > applications
> > > that the victim has access to.  The implications could be huge.
> > >
> > > -- Most people I've talked to appear to be clueless that a problem
> > exists.
> > > I often hear "we use SSL" when bringing up the issue.  SSL doesn't
> > matter.
> > > Cross site scripting can be used to steal cookies regardless of SSL
use.
> > > Similarly, I often hear "the SSO cookie is encrypted".  That doesn't
> > matter
> > > either.  I just need to replay the encrypted cookie "blob" in an
attack.
> > > Aside from "don't use single sign on" and "use certificates" (neither
> > are
> > > options for us for several reasons), what can be done to mitigate the
> > risks?
> > >  I've considered the following:
> > >
> > > -- Track the IP address of the legitimate user when they authenticate,
> > then
> > > validate that the user is coming from the same IP address for each
> > > subsequent request to the SSO environment.  Most SSO vendors support
> > this
> > > out of the box.  However, IP addresses can be spoofed (it's not hard
to
> > > spoof your bosses IP address when you are on the same subnet), and IP
> > > validation doesn't work in NAT environments.  Still, I think this is
> > > probably the most feasible option.
> > >
> > > -- Use timeout values to force periodic re-authentication.  However,
> > > reauthenticating too often defeats the purpose of SSO.
> > >
> > > -- Use some sort of nonce so that cookies can only be used one time.
> > This
> > > probably wouldn't work well in an SSO environment when a user might
want
> > to
> > > have multiple web applications open at once though.
> > >
> > > -- Put sensitive applications into a separate sub-domain (e.g.
> > > *.secure.myintranet.com), then use a separate SSO cookie for that
> > specific
> > > domain.
> > >
> > > Any other thoughts?  Has anyone else here implemented SSO on a
corporate
> > > network, and if so, are you doing anything to prevent cookie stealing
> > and
> > > replay?  If you aren't doing anything, is it due to ignorance, or have
> > you
> > > specifically decided not to address the problem?  Why?
> > >
> > > Thanks
> > > WF