Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Exploits-HackingTools
[Top] [All Lists]

[UNIX] Woltlab Burning Board SQL Injection Vulnerability

Subject: [UNIX] Woltlab Burning Board SQL Injection Vulnerability
Date: 17 May 2005 10:37:12 +0200
The following security advisory is sent to the securiteam mailing list, and can 
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Woltlab Burning Board SQL Injection Vulnerability
------------------------------------------------------------------------


SUMMARY

 <http://www.woltlab.de/> Burning Board is "a popular, multi purpose forum 
/ community softwareoffered by WoltLab GmbH". There is an SQL Injection 
vulnerability in Burning Board that allows for an attacker to influence 
SQL Queries and possibly query arbitrary data from the database, such as 
administrator's password hashes.

DETAILS

SQL Injection Vulnerability:
Burning Board is prone to SQL Injection attacks that may allow for an 
attacker to query arbitrary database information, including administrator 
password hashes. The vulnerability lies in the verify_email() function

function verify_email($email) {
 global $db, $n, $multipleemailuse, $ban_email;

 $email=strtolower($email);
 if( ! preg_match( 
"/^([_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*
 (\.[a-zA-Z]{2,}))/si",$email)) return false;
 $ban_email = explode("\n",preg_replace("/\s*\n\s*/","\n", 
strtolower(trim($ban_email))));
 for($i = 0; $i < count($ban_email); $i++) {
  $ban_email[$i]=trim($ban_email[$i]);
  if(!$ban_email[$i]) continue;
  if(strstr($ban_email[$i], "*")) {
   $ban_email[$i] = str_replace("*",".*",$ban_email[$i]);
   if(preg_match("/$ban_email[$i]/i",$email)) return false;
  }
  elseif($email==$ban_email[$i]) return false;
 }
 if($multipleemailuse==1) return true;
 else {
  $result = $db->query_first("SELECT COUNT(*) FROM bb".$n."_users WHERE 
email = '".$email."'");
  if($result[0]!=0) return false;
  else return true;
 }
}

As we can see from the code above, $email is never really sanitized. Sure, 
it has to match the regular expression above, but we can always do 
something like pass it an email address like this
sre464hfrgt6@4g546ufgfrh5.org' OR (userid=1 AND MID(password,1,1)='a')/*

Which would return an error message about the email already being in use 
or invalid if the first character of the password hash is 'a'. In order to 
keep from registering multiple accounts while trying to exploit this 
vulnerability an attacker simply would need to specify a username that is 
already in use. Also, it should be noted that it does not matter that 
$email is encapsulated in single quotes due to this bit of code in 
global.php

// remove slashes in get post cookie data...
if (get_magic_quotes_gpc()) {
  if(is_array($_REQUEST)) $_REQUEST=stripslashes_array($_REQUEST);
  if(is_array($_POST)) $_POST=stripslashes_array($_POST);
  if(is_array($_GET)) $_GET=stripslashes_array($_GET);
  if(is_array($_COOKIE)) $_COOKIE=stripslashes_array($_COOKIE);
}

This is not a very hard issue to exploit, and a user does not need to be 
authenticated to exploit it. Also, disabling user registrations is not a 
safe work around by itself as this issue also exists when a user edits or 
updates his profile (in the email field).

Vendors status:
he developers are said to have made a patch available as of late last 
week, and all users should upgrade their Burning Board installations as 
soon as possible.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:security@gulftech.org> 
GulfTech Security Research.
The original article can be found at:  
<http://www.gulftech.org/?node=research&article_id=00075-05162005> 
http://www.gulftech.org/?node=research&article_id=00075-05162005



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
list-unsubscribe@securiteam.com 
In order to subscribe to the mailing list, simply forward this email to: 
list-subscribe@securiteam.com 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any 
kind. 
In no event shall we be liable for any damages whatsoever including direct, 
indirect, incidental, consequential, loss of business profits or special 
damages. 




<Prev in Thread] Current Thread [Next in Thread>
  • [UNIX] Woltlab Burning Board SQL Injection Vulnerability, SecuriTeam <=