Re: ASPR #2000-07-22-1: Remote Retrieval Of IIS Session Cookies From Web Browsers

[Peter W <peterw () USA NET>]

At 11:31am Oct 24, 2000, ACROS Security wrote:

> Obviously, for the attacker, stealing such a cookie would mean a
> successful takeover of user's identity. Hence the notion that in
> critical systems, session ID cookies are just as sensitive as
> passwords (effectively they are equivalent to username:password
> pairs).

No, they're not as sensitive
 1) Random tokens are worthless to 3rd party sites, but users frequently
    choose the same username:password combinations for multiple
    systems. Get my Web email cookie and you can read my webmail but
    you cannot mess with my investment portfolio, even if both services
    use the same username/password combination.[0]
 2) Session tokens often do (and should!) have limited lifespans; so you
    can only read my email for 12 hours or so. (Naturally, the timeout
    must be enforced on the server side.)
 3) Because session tokens are meaningful only to the proper back-end, it
    is relatively easy to have the back-end provide a "log out" function
    that invalidates a session token, to further limit the lifespan; so
    when I log out of my webmail app, you're locked out, too.

Random session tokens are never as valuable as the facts used to
authenticate and initiate the sessions. That isn't to say tokens are not
valuable; just that they're not *that* valuable. Holding a door open isn't
as powerful as obtaining a set of keys to unlock it in the future.

> Throughout the analysis it is assumed that the attacker is capable of the
> following:
>
> 1) Listening to network traffic between client and server
> 2) Generating fake (spoofed) network traffic between client and server

This is a potential problem with all unauthenticated communication. Use
SSL, Free S/WAN, Windows IPSEC, etc., and you're OK. Use unauthenticated
IP connections (encrypted or not!) like HTTP/telnet/FTP and you're not.

MSFT downplays the significance of the problem, but folks should note that
more ISP's are deploying transparent Web proxy servers that are ideal for
this sort of thing, and more governments (the US and UK immediately come
to mind) are pressuring ISP's to facilitate government surveilance. That's
not to say that goverments will abuse these facilities, but to illustrate
that mechanisms with potential for man-in-the-middle abuse have been, and
are being, deployed. Unencrypted data is not safe, and unauthenticated
servers can't be fully trusted.

> Microsoft has issued a patch for IIS, available at:

> This patch makes it possible for IIS to mark its session cookies as "secure"
> thus preventing them from being sent over unencrypted connections.

You mean that wasn't an option before??? Yikes.

The fix seems sub-optimal to me, but I'll have to wait til the KB article
comes out to know for sure. At first glance, it seems that IIS session
cookies were designed to facilitate stateful server behavior, and have
been over-extended to support makeshift security mechanisms.

More secure mechanisms are possible; see
http://www.securityfocus.com/archive/1/80650 for some ideas.

Perhaps it's time for ASP shops to stop accepting Microsoft's black box
session management and reevaluate their security needs. How many
ASP shops are relying complete on ASP sessions for session security? Has
Microsoft ever suggested that its session mechanism is suitable for
security purposes, or are they being nice and trying to help compensate
for questionable programming decisions by their customers?

> It is important to note that our limited testing only covered one web server.
> There are many other web servers and various session management server
> add-ons that could be potentially affected by the identified vulnerability.

Also consider that many Web browsers, FTP clients, etc., are happy to
"remember" usernames and passwords which they (again, absent proper IPSEC
configurations) present in cleartext to unauthenticated hosts. The quiet
proliferation of transparent application-level proxy systems by ISP's only
underscores the value of end-to-end encryption and authentication.

Of course then there's the issue of Microsoft and Netscape refusing to
support things like SSL/TLS ciphersuites that provide perfect forward
secrecy to protect your "secure" Web sessions against sniffing by
attackers who've retrieved server keypairs from discarded backup tapes.

We'll save that one for later. ;-)

-Peter

[0] which is why password-retrieving hacks like @stake's PalmOS
    posting are significant beyond their immediate application

--
This fall, taxpaying American citizens will elect voting representatives to
the US Congress. Except for those in Washington, DC. http://www.dcvote.org/