begood Posted July 13, 2010 Report Posted July 13, 2010 criptatu pulii...schimbati parolele pentru orice eventualitate. Quote
LLegoLLaS Posted July 13, 2010 Report Posted July 13, 2010 de ce mortii lui nu s-a gandit acum cateva zile sa faca treaba asta?)scapam si eu de warn Quote
Flubber Posted July 13, 2010 Report Posted July 13, 2010 FileList.ro - Page 337 - TORRENTs.ROCate ceva interesant de pe acolo ^:si gata nu mai merge... cel putin la mine. L-au hackuit astiaRelativ 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 Quote
LLegoLLaS Posted July 14, 2010 Report Posted July 14, 2010 a vrut doar reclama...putea sa faca mult mai mult...sau cred ca god a observat repede si a oprit tractoru' Quote
sTz Posted July 14, 2010 Report Posted July 14, 2010 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.. Quote
cigraphics Posted July 14, 2010 Report Posted July 14, 2010 Ratio: 2.853 Uploaded: 5.19 TB Downloaded: 1.82 TB s-au pierdut vreo 40 GB uploadati asta e ... Quote
Guest Nemessis Posted July 14, 2010 Report Posted July 14, 2010 Sursa: filelist.ro :: LoginThis 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 classif ((isset($_POST['class'])) && (($class = $_POST['class']) != $user['class'])){ if (($CURUSER['class'] < UC_SYSOP) && ($user['class'] >= $CURUSER['class'])) die ();or:modtask.php wrote:// Set classif ((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 higherif ($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 Quote
Guest User Name Posted July 14, 2010 Report Posted July 14, 2010 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. Quote
N-W-A Posted July 14, 2010 Report Posted July 14, 2010 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. Quote