Filelist.ro Hack

[begood]

criptatu pulii...schimbati parolele pentru orice eventualitate.

[LLegoLLaS]

de ce mortii lui nu s-a gandit acum cateva zile sa faca treaba asta?)scapam si eu de warn

[Dra3Q]

sa folosit de "the god" simplu?

[Flubber]

FileList.ro - Page 337 - TORRENTs.RO

Cate ceva interesant de pe acolo ^:

si gata nu mai merge... cel putin la mine. L-au hackuit astia

Relativ da, exploit mare ?i vechi în modtask.God încearc? acum s?-l fixeze, d-aia e oprit trackerul.

Meh..?i atât.

Pan' la urma ce a fost? Fiindca din cate vad, Psychotic s-a adaugat ca SysOp

[LLegoLLaS]

a vrut doar reclama...putea sa faca mult mai mult...sau cred ca god a observat repede si a oprit tractoru'

[sTz]

N-a avut acces la cpanel, asa ca pagube mai mari decat cele facute n-ar prea fi..

Se pare ca eu am fost ferit de mailu cu tractoru alora.Probabil serveru a fost oprit intr-un timp destul de bun..

[cigraphics]

Ratio: 2.853 Uploaded: 5.19 TB Downloaded: 1.82 TB

s-au pierdut vreo 40 GB uploadati asta e ...

[sevex]

Nici eu nu am primit pm ..

[Guest Nemessis]

Sursa: filelist.ro :: Login

This post is a technical description of the security issue that allowed a joker to escalate his rank to SysOp and send spam email from our tracker earlier this week. The hole is present in tbdev based sites and does not seem to be patched in the latest available tbdev.net source (2009 Final release 2010-02-27).

The main problem is in the modtask.php file, that receives the form submit whenever an user profile is changed, and which allows any staffer (Mod+) to update update the class of any user to an arbitrary value, for example a moderator can create SysOps by simply POSTing such a request.

To fix the main problem search for:

modtask.php wrote:

// Set class

if ((isset($_POST['class'])) && (($class = $_POST['class']) != $user['class']))

{

if (($CURUSER['class'] < UC_SYSOP) && ($user['class'] >= $CURUSER['class'])) die ();

or:

modtask.php wrote:

// Set class

if ((isset($_POST['class'])) && (($class = $_POST['class']) != $user['class']))

{

if (($CURUSER['class'] < UC_SYSOP) && ($user['class'] >= $CURUSER['class'])) stderr("{$lang['modtask_user_error']}", "{$lang['modtask_try_again']}" );

and replace the red line with:

modtask.php wrote:

// can't make sysops, can't promote user to your rank or higher, can't edit users at your rank or higher

if ($class >= UC_SYSOP || ($class >= $CURUSER['class']) || ($user['class'] >= $CURUSER['class'])) die();

The secondary problem is that even after this check, valid actions are still vulnerable to CSRF issues, for example someone might trick an a Admin to click a link and unknowingly promote him to Moderator - this is how our attacker exploited the main problem without being a staffer. Since it's legal for Admins to create Mods, the check above is not sufficient, and we must make sure they create them knowingly.

To mitigate CSRF holes there are many available solutions, ex. captchas, referrer checking, session tokens etc. Bellow is our solution that we believe is portable, non-intrusive and makes minimal assumptions about the run-time environment.

Add the red lines to your userdetails.php:

userdetails.php wrote:

begin_frame("Edit User", true);

print("<form method=post action=modtask.php>\n" );

require "validator.php";

print(validatorForm("ModTask_$user[id]" ));

Add the red lines to your modtask.php:

modtask.php wrote:

// and verify...

if (!is_valid_id($userid)) stderr("Error", "Bad user ID." );

// Handle CSRF (modtask posts form other domains, especially to update class)

require "validator.php";

if (!validate($_POST[validator], "ModTask_$userid" )) die ("Invalid" );

validator.php wrote:

<?

function validator($context){

global $CURUSER;

$timestamp=time();

$hash=hash_hmac("sha1", $CURUSER[secret], $context.$timestamp);

return substr($hash, 0, 20).dechex($timestamp);

}

function validatorForm($context){

return "<input type=\"hidden\" name=\"validator\" value=\"".validator($context)."\"/>";

}

function validate($validator, $context, $seconds=0){

global $CURUSER;

$timestamp=hexdec(substr($validator, 20));

if($seconds && time() > $timestamp + $seconds)

return False;

$hash=substr(hash_hmac("sha1", $CURUSER[secret], $context.$timestamp), 0, 20);

if (substr($validator, 0, 20) != $hash)

return False;

return True;

}

?>

Please direct any security feedback (i.e not requests to help fix your tracker) to contact[a]filelist.ro

[Guest User Name]

uitati ce a putut spune God ,intr-unul din PM.

Nu e nevoie de asa ceva, parolele nu au fost compromise - nici eu nu le am. Email-ul este oricum o informatie publica, si nu cred ca au avut timp sa extraga toate email-urile din baza de date. Sursa din forum nu contine fisierul vulnerabil, si oricum au folosit acelasi exploit si pe alte trackere, e o problema de tbdev. Filelist e unul dintre cele mai sigure site-uri, adica ce depinde de noi e facut bine.

Daca mai apare cate o gaura de securitate noua in tbdev nu prea avem ce sa facem. Nu putem decat sa fim pregatiti sa reactionam eficient, drept dovada ca in doua ore eram back online cu pagube minime.

[N-W-A]

uitati ce a putut spune God ,intr-unul din PM.

Nu e nevoie de asa ceva, parolele nu au fost compromise - nici eu nu le am. Email-ul este oricum o informatie publica, si nu cred ca au avut timp sa extraga toate email-urile din baza de date. Sursa din forum nu contine fisierul vulnerabil, si oricum au folosit acelasi exploit si pe alte trackere, e o problema de tbdev. Filelist e unul dintre cele mai sigure site-uri, adica ce depinde de noi e facut bine.

Daca mai apare cate o gaura de securitate noua in tbdev nu prea avem ce sa facem. Nu putem decat sa fim pregatiti sa reactionam eficient, drept dovada ca in doua ore eram back online cu pagube minime.

pai si asa e. mai putin la faza cu cele mai sigure. niciun site nu e sigur.