bugtraq - Potential SQL injection vulnerability in Apache::AuthCAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 7 Dec 2007 01:41:14 +0100
From: Matthias Bethke <matthias@...iski.de>
To: bugtraq@...urityfocus.com
Subject: Potential SQL injection vulnerability in Apache::AuthCAS

Some weeks ago, I sent the following message to David Castro, the author
of Apache::AuthCAS. As there hasn't been any reply and the guys at
ja-sig.org haven't been able or willing to look into it, perhaps there
is somebody here who wants to have a closer look at this?

CAS is the Central Authentication Service that seems to be used in
several large, mainly academic, networks.

I believe I have found an SQL injection vulnerability in
Apache::AuthCAS, the perl module used to authenticate users of various
web sites against a CAS server. That is, I haven't been able to verify
it as I don't have a working system here (and didn't want to hack around
in others'); my colleague Dirk Stander and I just came across it while
looking for candidates for a web authentication system and it seems
fairly obvious from looking at the source:

In line 516 of the CPAN version
[http://search.cpan.org/~dcastro/Apache-AuthCAS-0.4/lib/Apache/AuthCAS.pm],
the session ID is extracted from the cookie as

 $cookie =~ /.*$SESSION_COOKIE_NAME=([^;]+)(\s*;.*|\s*$)/;
 $sid = $1 || "";

then it is passed to get_session_data() iin line 544 without sanitizing
it. get_session_data() simply inserts $sid into SQL in line 1005:

my $sth = $dbh->prepare("SELECT last_accessed, uid, pgtiou FROM $DB_SESSION_TABLE WHERE id='$sid';");

Manipulating your cookie to contain a session ID of "x' OR 'x'='x"
or someting equivalent wouldn't be caught. As this way of inserting
arguments into SQL is used throughout the module, there are other places
where it is potentially even more dangerous, like the INSERT in line
974, although we didn't check the program flow to this function.

regards,
	Matthias
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

Content of type "application/pgp-signature" skipped