Hi,
forwarding an off-list discussion. Please review and comment to the list.
Thanks,
Hans
---------- Forwarded message ----------
From: Hans Hübner <hans(a)huebner.org>
Date: Fri, Oct 24, 2008 at 12:54
Subject: Re: hunchentoot session hijacking
To: Anton Vodonosov <avodonosov(a)yandex.ru>
Cc: Edi Weitz <edi(a)agharta.de>
Hi Anton,
thank you for your security analysis. I agree that, even though the
weakness of the session protection is documented, it would be better
to provide for a secure scheme from the beginning. The problem at
hand is that there is no portable secure solution. Adding a
documented hook to Hunchentoot that allows for setting up a more
secure scheme is certainly possible, but I think that this would not
be beneficial: Such a hook is trivial, and the concerned user can
always implement HUNCHENTOOT:RESET-SESSION-SECRET in a more secure
fashion, overriding the default implementation.
Another option would be to make specifying a part of the session
secret mandatory at server startup time. I would find this
inconvenient, in particular if it cannot be demonstrated that the
scheme would be substantially more secure than the existing mechanism.
Another option would be to provide for a portable secure
implementation, but I certainly lack the time to look at this.
So, if you feel that this is something that needs to be addressed, can
you provide us with a patch, either to the source code or to the
documentation? A documentation patch could consist of a short summary
of your security analysis and a description how the concerned user can
make the server more secure.
Thanks,
Hans
On Thu, Oct 23, 2008 at 23:38, Anton Vodonosov <avodonosov(a)yandex.ru> wrote:
> Hello.
>
> I've recently discovered that hunchentoot sessions are quite easy to
> hijack (while I was investigating generation of unpredictable keys
> for cl-openid). Therefore I want to suggest a solution to make them
> more secure.
>
> I know the documentations discourages from considering sessions as
> really secure, but after some experiments it turned out that in normal
> case it is a matter of just several hours to hijack hunchentoot
> sessions.
>
> For example, I know that the hunchentoot-session cookie value is
> "2561%3A5767E844C4A3FBEDBCA79C349F1DE52B; path=/".
>
> 2561 here is SESSION-ID. 3A5767E844C4A3FBEDBCA79C349F1DE52B is value
> produced by
> (encode-session-string
> (session-id session)
> (session-user-agent session)
> (session-remote-addr session) ;; usually ignored
> (session-start session)))
>
> I know my SESSION-USER-AGENT. SESSION-START is most likely the
> value of the Date header in the server response.
>
> The only unknown value is the *SESSION-SECRET* global used by
> ENCODE-SESSION-STRING. But it is easy guessable. It is generated by a
> series or RANDOM invocation. RANDOM implementation is usually deterministic,
> and therefore *SESSION-SECRET* is fully determined initial value of
> *THE-RANDOM-STATE*, which in turn is usually fully determined by current
> time (i.e. server startup time). I.e. *SESSION-SECRET* is fully
> determined by the server start time.
>
> For example in SBCL, MAKE-RANDOM-STATE uses GET-UNIVERSAL-TIME.
> Resolution of GET-UNIVERSAL-TIME is one second i.e. if we want
> to consider a year-long period, we have only (* 365 24 60 60)
> == 31536000 values to consider. This took several hours of a
> moderate laptop.
>
> After we know *SESSION-SECRET*, we may easy calculate session cookie
> for any given session ID (we usually do not know session start
> time of other people, but it is in the range of 30 minutes from current
> time for active sessions).
>
> In short, to make session more secure we need unguessable
> *SESSION-SECRET*. It is possible to use /dev/[u]random on Linux
> and CryptoAPI on Windows, but the simplest way, in my opinion,
> would be to provide a public function to set session secret (or a
> part of session secret). User will set it to some passphrase.
>
> Best regards,
> - Anton
>
>
>
>
>
