PornoSecurity

A Sneak Preview

Posted on 2008-05-23 15:36:15 in PornoSecurity

Hi there, some time has passed since the last post on this weblog, I'm now auditing a web application written by some italian guys and I am focusing on the steps from an SQL Injection to a real command shell. Too many times SQL Injection flaws are considered as a low/medium threat due to the fact that they are often [ab]used to conduct low-impact attacks(such as defacing).
This has to change, SQL Injection flaws are a *really* dangerous threat. Here is a sneak preview regarding some of the (for now) 0-day flaws i discovered in this webapp.

I have also discovered some vulnerabilities in some Cisco/Linksys products, and I'm in contact with the Cisco Product Security Incident Response Team (PSIRT) and the Linksys security team to coordinate pubblic disclosure.

More news soon.

xine-lib NSF Demuxer Buffer Overflow Vulnerability

Posted on 2008-04-17 12:40:27 in PornoSecurity

I found a stack-based buffer overflow in the NES Sound Format demuxer(demux_nsf.c) of xine-lib <= 1.1.12. The vulnerability is caused due to a boundary error within the "demux_nsf_send_chunk()" function in src/demuxers/demux_nsf.c and can be exploited to run arbitrary code while processing an NSF file with an overly large NSF title tag.

 

Secunia advisory

Pligg 9.9.0 SQL Injection Vulnerability

Posted on 2008-04-09 00:48:39 in PornoSecurity

 

Today i wanted to try the Pligg digg-like content management system, after playing with it for a while I found a vulnerability.

The pligg developers fail to sufficiently sanitize user-supplied data before using it in an SQL query making it possibile to inject extra SQL statements. 

 

http://www.example.com/editlink.php?id=1+AND+((SELECT+user_pass+FROM+pligg_users+WHERE+user_login=0x676f64)+LIKE+0x25)+UNION+SELECT+10,2 

 

To exploit this you need the id of a news you submitted(10 in the example) and an id of a news submitted by others(1 in the example), when the LIKE statement matches you get a "Not your link" error.

This is a tipical blind SQL-injection scenario. 

 

UPDATE:  

Trying to write a little patch for a friend of mine i found many other security-related problems in pligg. Many  user-supplied variables are simply not checked or checked in the very wrong way. 

 

•  The first case, editlink.php: 

 

if(isset($_GET['id'])){
  $theid = strip_tags($_GET['id']);
}
if(isset($_POST['id'])){
  $theid = strip_tags($_POST['id']);

}
[...]
$link = $db->get_row("SELECT link_id, link_author FROM " . table_links . 
" WHERE link_id=".$theid.";")
[...]
$linkres->id=$link_id = strip_tags($_POST['id']);
$linkres->read();   

libs/link.php:

function read($usecache = TRUE) {
 $id = $this->id;
 $link = $db->get_row("SELECT " . table_links . ".* FROM " . table_links 
. " WHERE link_id = $id");
}

 

 

• Another one, vote.php:
  

 

$link->id=$_POST['id'];
$link->read_basic();

link/link.php:

function read_basic() {
[...]
$id = $this->id;
$db->get_row("SELECT link_comments, link_author, link_status, link_randkey, link_category, link_date, link_votes, link_karma,link_published_date FROM " . table_links . " WHERE link_id = $id")

 ..and so on. 

I really dunno why they insist to strip_tags instead of a simple intval() ;)