doekia Posted July 29, 2015 Share Posted July 29, 2015 Depuis quelques jour un bruit court a propos d'une ENORME faille de sécurité connue de l'équipe PrestaShop. Il apparaît aujourd'hui que quelques agences "triées" sur le volet auraient reçues de la part de l'équipe technique PrestaShop des patchs ... Quelle est donc cette manière de procéder en total violation tant avec l'esprit communautaire et de l'équité? A propos de la faille, c'est une histoire rocambolesque ou quelqu'un "pourrait" prétendument deviner le prochain mot de passe aléatoire généré par une boutique en créant N compte client et demandant M regénération de mot de passe (restreint par construction à PS_PASSWD_TIME_BACK (6h par défaut)) En tout premier la fonction aléatoire sous-jacente mt_rand() utilise rand() de la libc qui elle peut être partiellement prédite si tant est que l'on puisse garantir être les seuls à l'utiliser - ceci est bien sûr une utopie sur un serveur réèl. En second, vous devez être capable de connaitre l'url du BO de la boutique que vous souhaitez attaquer - ceci n'est possible que grace à un autre bug - que PrestaShop se garde bien de corriger et menant a une indexation de cette url dans Google. Ou plus facilement sur le cloud où tous les BO partagent la même url En troisième vous devez connaitre l'email de l'un des admins- bon ok un peu de social engineering suffit Il faut également que l'url BO ne soit pas protégée par .htaccess (pas possible à protéger sur le cloud sauf à violer les conditions générales d'utilisation) ---- Le patch implémente une soupe de openssl_random_pseudo_bytes ou mcrypt_create_iv ou sinon un melange de sha1(mt_rand()), qui palie à ce genre de cas totalement improbable en gros (26!/8!) === Une attaque bien plus facile à mettre en oeuvre consiste à forger un message à envoyer par le formulaire de contact, ce dernier contient une commande destructrice qui n'ayant pas le bon token activera le mode dans lequel l'employé pourra malgré tout exécuter celle-ci. C'est très facile et il est a parier un réussite dans 80% des cas compte tenu de la nature humaine. === On peut également développer un module/thème buggué (95% des modules addons). Ceci amenant une demande de support ou l'on récupérera un access FTP découvrant ainsi toutes les informations "secrète" d'un shop ... a partir de là c'est mode super badass à volonté - aussi appeléla fête du slip - ============================= Pour conclure: - je trouve mesquin d'effrayer les gens sur un scénario très improbable, - de laisser des bugs impactant la sécurité autrement plus facile à exploiter - d'avoir laissé passer des mois pour appliquer un patch de sécurité "qualifié" de majeur, alors que commit du 8 avril: https://github.com/PrestaShop/PrestaShop/commit/dcb1f8000ecf47437593373091ae56c4ffdf42ac - de ne distribuer les patch qu'a une "élite" qui va alors pouvoir monétiser cette frayeur montée de toute pièce. 12 Link to comment Share on other sites More sharing options...
Mediacom87 Posted July 30, 2015 Share Posted July 30, 2015 Que répondre à ce constat accablant Link to comment Share on other sites More sharing options...
Mediacom87 Posted July 30, 2015 Share Posted July 30, 2015 ah tiens un petit mail : https://www.prestashop.com/blog/fr/mise-jour-securite-prestashop/ Link to comment Share on other sites More sharing options...
Yoya Posted July 30, 2015 Share Posted July 30, 2015 Merci Doekia pour cette analyse pertinante. Cdlt, Pierre Link to comment Share on other sites More sharing options...
coeos.pro Posted July 30, 2015 Share Posted July 30, 2015 En second, vous devez être capable de connaitre l'url du BO de la boutique que vous souhaitez attaquer - ceci n'est possible que grace à un autre bug - que PrestaShop se garde bien de corriger et menant a une indexation de cette url dans Google. suffit de mettre dans robots.txt : Disallow: /le_nom_du_dossier_admin/ non, c'est une mauvaise blague, ne faites surtout pas ça. Blagues mis à part, si vous souhaitez limiter l'accès du BO à votre IP ou à plusieurs IP, créez un fichier .htaccess à mettre dans le dossier admin (surtout pas à la racine de la boutique!!!) contenant : Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from 127.0.0.2 Allow from 127.0.0.3 ErrorDocument 403 http://www.example.com ErrorDocument 404 http://www.example.com Evidemment les 127... représentent vos addresses IP, et n'oubliez pas que vous n'aurez plus accès à votre BO depuis un autre ordi (chez un client, en vacances...), à moins de mettre à jour le fichier .htaccess http://www.example.com étant l'url de votre boutique ou une autre url. Link to comment Share on other sites More sharing options...
shagshag Posted July 30, 2015 Share Posted July 30, 2015 (edited) Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from 127.0.0.2 Allow from 127.0.0.3 ErrorDocument 403 http://www.example.com ErrorDocument 404 http://www.example.com je ne suis pas sûr que ça soit la meilleur méthode, si on trouve d'une façon ou d'une autre le dossier admin, on aura une confirmation en essayant d'y accéder : erreur 403 au lieu de 404 et page d'erreur différente de la normale. Je passerai plutôt par PHP pour filtrer par IP et envoyer un vrai 404 et la page standard pour que ça soit vraiment transparent. Avec en prime une alerte en interne pour dire qu'il y a eu une tentative d'intrusion, histoire de savoir qu'un ancien stagiaire a voulu tester ses accès ou un truc du genre. Avec le cookie d'admin je pense qu'on peut savoir qui a essayé de visiter l'admin (s'il est loggué) et lui envoyer un mail d'explication. Mais bon on est loin du sujet initial. Edited July 30, 2015 by shagshag (see edit history) 2 Link to comment Share on other sites More sharing options...
quentin audrain Posted July 30, 2015 Share Posted July 30, 2015 Bonjour doekia, Avant tout, merci pour votre post et votre réactivité. C’est toujours un plaisir de voir que des membres de la Communauté prennent à coeur les avancements de PrestaShop. Je voudrais en profiter pour réagir un peu et donner quelques détails sur la manière dont nous nous y sommes pris pour communiquer sur le sujet. 1. La première annonce a été faite à toute la Communauté en même temps ! Dans cet article de blog, vendredi dernier pour être précis. L’annonce est discrète car nous n’avions pas encore de date pour la sortie du correctif, mais bien présente ! (Pour information, nous avons, également mis en avant cet article sur les forums anglais et français). 2. Nous avons ensuite tenu au courant toutes nos agences partenaires 3 jours plus tard (lundi), afin de les informer de la situation et de leur conseiller de se libérer du temps en prévision de l’annonce publique qui était prévue pour mercredi. Certaines agences ont entre 300 et 400 boutiques PrestaShop. Je vous laisse imaginer l’organisation à mettre en place pour appliquer le correctif à toutes les boutiques sous leur responsabilité. 3. Mercredi, nous avons envoyé les correctifs à toutes nos agences partenaires à midi. Nous voulions leur donner une avance de quelques heures, afin qu’ils ne soient pas innondés de demandes urgentes de la part de leurs clients. Ces agences partenaires de PrestaShop, avec lesquelles nous avons des contrats avec clauses de confidentialité, ont pu nous faire des retours utiles sur l’application du correctif, tout en restant discrets et sans affoler la Communauté inutilement. Nous les en remercions. 4. Nous prévoyions initialement de faire l’annonce publique mercredi vers 17h00, mais suite à ces quelques retours de certaines agences partenaires, nous avons décidé de se laisser 12h supplémentaire pour améliorer légèrement le correctif avant de le publier à toute la Communauté. Ce qui nous amène à ce matin, 12h00, heure de l’annonce officielle. Il faut bien comprendre que dans un moment comme celui-ci, nous avons deux mots en tête : « Sécurité » et « Communauté ». Le mot Sécurité est placé en premier afin de s’assurer que tous les membres de la Communauté disposent des outils nécessaire pour sécuriser leurs boutiques. Si l’information a fuité, c’est que cette confidentialité n’a pas été respectée par tous, et de là vient le problème d’une possible « frayeur mesquine ». Nous estimons avoir agit de manière responsable pour protéger au maximum les boutiques PrestaShop tout en laissant le moins longtemps possible la Communauté dans l’ignorance de la disponibilité du correctif. Cette pratique responsable n’a pas forcément été suivie par tous les participants, et nous en prenons note pour améliorer notre processus de traitement des problèmes de sécurité. Concernant le temps passé trop long pour la mise à disposition du patch, nous sommes conscients que tout n’a pas été parfait de notre côté, et nous reconnaissons sans problème cette mauvaise évaluation. À vouloir bien faire, nous avons perdu beaucoup trop de temps. Les mises à jour de sécurité sont très rares chez PrestaShop et nous sommes déjà en train de revoir notre processus interne pour pouvoir réagir plus efficacement, et surtout plus rapidement. Merci ! Quentin Link to comment Share on other sites More sharing options...
doekia Posted July 30, 2015 Author Share Posted July 30, 2015 OSEF 404, ou 403 puisque google jusqu'a la fin de l'univers connu possède dans son index l'url contenant le chemin exact du BO. inurl:live_edit=1 ... Le problème est a mon sens de nous faire croire a une faille majeure et un patch (avec 17 non 7 correctifs (ben oui en plus ils savent toujours compter aussi bien)) et bien sûr de donner 3 mois plus tard cette information a une "élite" avant de publier officiellement. Et certains se sont empressé de monétiser celà. Enfin, si mentalement c'est envisageable d'exploiter dans les faits c'est totalement impossible. A titre de démonstration j'invite tous ceux qui pensent le contraire sur: http://hackme.enter-solutions.com le back-office est sur http://hackme.enter-solutions.com/bo l'email de l'admin est: [email protected] les restriction temporelle pour le changement de mot de passe ont été baissé à 0 donc vous pouvez regénérer autant de mot de passe que souhaité. les seules limites concernent l'envoi de mail qui sont limité à 5 par secondes 1 Link to comment Share on other sites More sharing options...
doekia Posted July 30, 2015 Author Share Posted July 30, 2015 (edited) @Quentin Tu es bien sûr conscient que l'annonce de Vendredi dernier ne dit pas "il y a une faille" et que au demeurant a part la partie .htaccess le reste n'adresse en rien le problème si tant est qu'il y en ai un (je peux mettre un pass complèxe si le hackeur peux le changer dans un suite prédictible ça ne sert à rien). Le bug du live_edit quand à lui fait que changer l'url du BO ne sert à rien. En terme d'annonce globale PrestaShop est très fort pour nous inonder de publicité de tout poil mais dans le cas d'une faille de sécurité on fait une annonce sibylline dans une recoin obscur de la nébuleuse de publication plus ou moins suivi... ça semble très logique. Pour finir certaines "agences certifiés" se sont empressé de tenter de vendre la mise en place de correctifs y compris à des clients qu'ils n'ont pas - correctif qui je le rappelle existe depuis 3 mois !! Edited July 30, 2015 by doekia (see edit history) Link to comment Share on other sites More sharing options...
shagshag Posted July 30, 2015 Share Posted July 30, 2015 Pour moi le soucis est de parler de faille de sécurité, c'est plutôt une amélioration de la sécurité. En pratique je vois mal comment on pourrait exploiter cette "faille", si elle ne l'est pas ce n'en est pas une. Et dans ce cas ce patch et tout le stress, business et utilisation de la peur qui vont avec sont pires que le remède pour l'utilisateur final. 5 Link to comment Share on other sites More sharing options...
Julien Bourdeau Posted July 31, 2015 Share Posted July 31, 2015 Les 10 fixes votés ont tous été ajoutés. https://github.com/PrestaShop/PrestaShop-1.5/releases/tag/1.5.6.3 Improved/changed features: [*] BO : Fix #PSCFV-11705, save availability date when adding new combination [*] BO : Hook displayBackOfficeHeader is now executed even if the module is disabled [*] CORE : Add Random charlist to passwdGen Fixed bugs: [-] FO : Fix additional space #PSCFV-12536 [-] FO : Fix bug #PSCFV-12003, robots.txt without unactive languages [-] FO: Fix bug #PSCFV-12160 pagination with instant search [-] FO : Fixed Fatal error [-] FO : Fix bug #PSCFV-11922, Carriers not updating correctly when changing address [-] BO : Fix bug #PSCFV-10539, memcache_connect [-] BO : Bug #PSCFV-11515, Supply order autocompletion is now sorted [-] BO : Fix bug #PSCFV-11166, orderslips in multishop [-] BO : Fix bug #PSCFV-9880, no overrides pdf TR in FO [-] BO : Bug #PSCFV-11936, Escape HTML char for Return Message [-] BO : Fix bug #PSCFV-12091, default shop reset on employee pwd renewal [-] BO : Fix bug #PSCFV-12030, false positive on extract return when pclzip [-] CORE : Fix bug #PSCFV-9517, check voucher validity before order validation [-] CORE : Force shop_id for 'all shops' context before sending core mails [-] CORE : Fix bug #PSCFV-11298, context in single shop on module install Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 <?php declare(ticks=1); function interrupt() { global $i; echo 'interrrupted at iteration '.$i.PHP_EOL; exit; } pcntl_signal(SIGINT,'interrupt'); pcntl_signal(SIGTERM,'interrupt'); $i = 0; $rnpg = array(); $nibble = array(); while(true) { $rnd = mt_rand(0,25); if (array_push($nibble, $rnd) > 7) { array_shift($nibble); $reverse = array_reverse($nibble); $segs = array_keys($rnpg,$rnd,true); foreach($segs as $v) { if ($v < 7) continue; $found = true; foreach($reverse as $j => $r) { if ($rnpg[$v-$j] === $r) $found &= true; else $found &= false; } if ($found) { echo 'RNPG predictable at '.($v-6).' iterations ('.implode(',',$nibble).')'.PHP_EOL; exit; } } } $rnpg[$i++] = $rnd; } Ce code ayant tourné 12h et procédé à 1915256 itérations n'a strictement été capable de rien. Ceci démontre que prédire le mot de passe généré avec la méthode dite "insecure" relève d'un scénario hollywoodien. Après évidement si des aliens venant d'une autre galaxie décident de pénétrer les boutiques PrestaShop... même pas sûr que le code actuel offre une protection. Mais nous pourrons alors faire appel à Will Smith. La faille qui divulgue sur Google l'url du BO et qui elle permet de détruire des boutiques avec un rien de social engineering et l'ignorance des utilisateurs. Vous la traitez avec la même priorité ou tout ces grand discours étaient là en écran de fumée pour faire accepter du code de geek inutile sauf pour vos élites ? 3 Link to comment Share on other sites More sharing options...
Julien Bourdeau Posted July 31, 2015 Share Posted July 31, 2015 Ce code ayant tourné 12h et procédé à 1915256 itérations n'a strictement été capable de rien. Ça ne veut pas dire qu'un exploit n'est pas possible. 1 Link to comment Share on other sites More sharing options...
Guest Kaylabs Posted July 31, 2015 Share Posted July 31, 2015 (edited) . Edited January 21, 2016 by Kaylabs (see edit history) Link to comment Share on other sites More sharing options...
Julien Bourdeau Posted July 31, 2015 Share Posted July 31, 2015 Changement à venir en 1.7 Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 Ça ne veut pas dire qu'un exploit n'est pas possible. Le point avec de nombreux tests et quelques avis éclairé de pointure de l'analyse crypto. mt_rand utilise glibc rand() sur les os moderne (debian5 +) rand() utilise lui-même random_r() l'algorythme quoique restant un RNPG boucle sur n tirages rendant le calcul d'un seed impossible, seule l'attaque brute force reste envisageable. Le calcul mathématique laisse entrevoir un bouclage de l'algorythme tous les 7^((2^8)-1) soit 7^127 ou encore 2.125450925×10¹⁰⁷ tirages. A raison de 2 génération par seconde, ça laisse un peu plus de 10¹⁰⁷ L'univers connu n'a selon les dernières estimation pas beaucoup plus de 10⁸⁰ particules élémentaires. J'affirme donc qu'il n'y a pas d'exploit possible par cette méthode. https://fossies.org/dox/glibc-2.21/random__r_8c_source.html Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 Et le passage de paramètres live_edit en POST c'est prévu pour quelle version 1.8 ? Link to comment Share on other sites More sharing options...
ZenGraph Posted July 31, 2015 Share Posted July 31, 2015 lol Link to comment Share on other sites More sharing options...
ZenGraph Posted July 31, 2015 Share Posted July 31, 2015 Ça ne veut pas dire qu'un exploit n'est pas possible. En gros.. y'a autant de chances d'exploiter cette faille que pour Prestashop de pouvoir calculer les taxes correctement sur l'ensemble des factures de toutes les boutiques ? Je demande hein , c'est juste pour savoir au niveau statistiques... !! 2 Link to comment Share on other sites More sharing options...
Julien Bourdeau Posted July 31, 2015 Share Posted July 31, 2015 J'affirme donc qu'il n'y a pas d'exploit possible par cette méthode. https://fossies.org/..._8c_source.html J'affirme donc que tu n'es pas un hacker. Tu comprendras que nous ne pourrons pas révéler plus de details sur l'exploit. 6 Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 Mais oui alors, sans me donner de détail, pénétrez le système que j'ai mis à disposition dans ce but! Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted July 31, 2015 Share Posted July 31, 2015 Bonjour tout le monde. Je ne suis pas développeur (comme vous le savez) mais j'ai du bon sens. Un peu. Juste ce qu'il faut, quoi. Aucun éditeur de logiciel n'a jamais prétendu à une faille de sécurité pour faire de l'argent, ça n'a aucun sens. Ecoutez-vous un peu, votre théorie est complètement invraisemblable. Si nous en sommes arrivés à faire un patch et communiquer sur cette faille, si nous savons qu'elle est exploitable, c'est qu'elle a été exploitée. C'est aussi simple que ça. Fort heureusement, elle a été exploitée par quelqu'un de bienveillant qui nous a prévenu et qui a travaillé avec nous sur le patch de sécurité. Si vous pensez vraiment que nous avons "inventé de toute pièce" une faille qui aurait pu nous mettre en gros porte-à-faux, c'est que votre besoin de nous prêter de mauvaises intentions a dépassé votre enthousiasme à développer en communauté un logiciel open source. C'est pas bon signe, les gars, on vieillit trop vite à force de s'acharner à voir le mal partout. Je peux comprendre les gens que les théories complotistes passionnent et si c'est votre cas, je vous conseille celle qui consiste à chercher sur quelle île 2Pac et Bob Marley sont en train de se boire un cocktail avec Elvis à la guitare. C'est moins déprimant ! 5 Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 Vous avez exploité un faille requérant 10¹⁰⁷ génération - pragmatique comme tu dis l'être, tu vois bien que c'est une gageure. Qu'il existe un bias permettant de réduire d'un facteur X pourquoi pas mais si il reste encore un minimum de 2³⁰ possibilités (valeur que je prends arbitrairement) c'est encore une fois totalement inexploitable et ce d'autant plus que sur système *live* il faut être capable d'itérer les 2³⁰ régénération de manière atomique (sans qu'aucun élément ne vienne perturber l'itération). On est bien d'accord, afficher 2³⁰ pages, sans que personne d'autre sur le net ne vienne en afficher une pendant ce temps !!! Maintenant il est très facile ayant une connaissance plus approfondi de l'exploit de démontrer qu'elle existe - tout à été mis en oeuvre sur le système de POC pour faciliter cette dernière - aucune contrainte temporelle de régénération, divulgation de l'url bo, divulgation de l'email de l'admin. Démontrez le! Pour la partie "faire de l'argent" je m'insurge de la manière de divulguer à une soi-disant "élite" (lire partenaire) en amont. Certains ayant trouvé là un filon! Et je m'insurge également d'entendre "nous prenons très à coeur la sécurité" alors que le fix a été divulgué il y a 3 mois. Donc si faille il y a vous avez pointé du doigt celle-ci depuis le 8 avril et donc laissé 3 mois et demi aux hackers pour l'exploiter - donc soit c'est de l'inconscience, soit qu'elle n'était pas exploitable. Link to comment Share on other sites More sharing options...
N°6 Posted July 31, 2015 Share Posted July 31, 2015 (edited) Bonsoir, De mon côté je pousse une "gueulante" : Le module de patch ne fonctionnant qu'avec les dernières versions de prestashop en 1.4, 1.5 et 1.6, toutes celles et ceux qui ont des versions "intermédiaires" se font avoir car bien évidemment on obtient un message d'erreur du module. Alors après on fait comment si on n'est que e-commerçant et non développeur pour patcher soi-même le problème de sécurité ? Et c'est vrai que certaines agences ont spammées nos messageries en nous inondant de propositions de prestations, même les agences à qui je n'ai jamais acheté de modules. Ce qui m'agace vraiment c'est que le staff de prestashop, qui sait pourtant envoyer des spams régulièrement sur nos messageries, n'a cette fois-ci pas daigné nous avertir de cette si importante faille de sécurité ! C'était assuré d'avance qu'en n'offrant qu'un module de patchage pour seulement 3 versions de prestashop sur plusieurs dizaines il y en auraient qui feraient un joli business la-dessus ! On dirait presque que c'était calculé comme tel à l'avance ! A se demander si il va bientôt falloir payer pour obtenir ces informations autrement que par agence partenaire interposée. Quand au guide d'aide en anglais : je sais bien que nous sommes devenus une minorité mais la moindre des choses aurait été de le proposer en plusieurs langues, dont le français, votre terre d'origine tout de même. Tous les commerçants francophones utilisant prestashop ne savent pas forcemment lire l'anglais, encore moins si c'est un peu technique. En tout cas je me doute bien que cette faille va faire les choux gras de certains au détriment des utilisateurs "normaux" de prestashop. Et ne me parlez pas du module de mise à jour en 1 clic made in prestashop qui plante une fois sur deux votre boulot, je ne veux même plus y penser ! Je sens qu'on va en entendre parler longtemps de ce manque volontaire de communication. Pas cool du tout. Edited July 31, 2015 by N°6 (see edit history) 1 Link to comment Share on other sites More sharing options...
doekia Posted July 31, 2015 Author Share Posted July 31, 2015 Le patch de la faille inexistante de "sécurité" cher N°6, quelque soit ta version consiste à remplacer la fonction Tools::passwdGen() par ce code: /** * Random password generator * * @param integer $length Desired length (optional) * @param string $flag Output type (ALPHANUMERIC, RANDOM) * @return string Password */ public static function passwdGen($length = 8, $flag = 'ALPHANUMERIC') { $length = (int)$length; if ($length <= 0) return false; switch ($flag) { case 'RANDOM': $num_bytes = ceil($length * 0.75); $bytes = Tools::getBytes($num_bytes); return substr(rtrim(base64_encode($bytes), '='), 0, $length); case 'ALPHANUMERIC': default: $str = 'abcdefghijkmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'; break; } $bytes = Tools::getBytes($length); $position = 0; $result = ''; for ($i = 0; $i < $length; $i++) { $position = ($position + ord($bytes[$i])) % strlen($str); $result .= $str[$position]; } return $result; } public static function getBytes($length) { $length = (int)$length; if ($length <= 0) return false; if (function_exists('openssl_random_pseudo_bytes')) { $bytes = openssl_random_pseudo_bytes($length, $crypto_strong); if ($crypto_strong === true) return $bytes; } if (function_exists('mcrypt_create_iv')) { $bytes = mcrypt_create_iv($length, MCRYPT_DEV_URANDOM); if ($bytes !== false && strlen($bytes) === $length) return $bytes; } // Else try to get $length bytes of entropy $result = ''; $entropy = ''; $msec_per_round = 400; $bits_per_round = 2; $total = $length; $hash_length = 20; while (strlen($result) < $length) { $bytes = ($total > $hash_length) ? $hash_length : $total; $total -= $bytes; for ($i=1; $i < 3; $i++) { $t1 = microtime(true); $seed = mt_rand(); for ($j=1; $j < 50; $j++) $seed = sha1($seed); $t2 = microtime(true); $entropy .= $t1 . $t2; } $div = (int) (($t2 - $t1) * 1000000); if ($div <= 0) $div = 400; $rounds = (int) ($msec_per_round * 50 / $div); $iter = $bytes * (int) (ceil(8 / $bits_per_round)); for ($i = 0; $i < $iter; $i ++) { $t1 = microtime(); $seed = sha1(mt_rand()); for ($j = 0; $j < $rounds; $j++) $seed = sha1($seed); $t2 = microtime(); $entropy .= $t1 . $t2; } $result .= sha1($entropy, true); } return substr($result, 0, $length); } c'est dans le fichier classes/Tools.php Puis dans le fichier adminXXX/password.php trouve la ligne de la forme $pwd = Tools::passwdGen(); et remplace là par $pwd = Tools::passwdGen(10, 'RANDOM'); enfin dans classes/Customer.php $password = Tools::passwdGen(); par $password = Tools::passwdGen(8, 'RANDOM'); Tous le reste ne concerne que pas la "faille" Enfin je voudrais quand même te dire que si tu éprouves des difficultés avec 1 click upgrade il est a parier que tu as des problèmes annexes avec ton shop. J'utilise 1 click upgrade très régulièrement et il fonctionne sans grand problème. Son seul reproche est de ne pas être "bullet proof", donc de ne pas savoir gérer les difficultés. Link to comment Share on other sites More sharing options...
N°6 Posted August 1, 2015 Share Posted August 1, 2015 Merci pour ton aide Doekia, qui va certainement faire gagner des euros à ceux qui sont touchés par ce problème dans la communauté ! Link to comment Share on other sites More sharing options...
P i l o u Posted August 1, 2015 Share Posted August 1, 2015 Bonjour, L'installation du patch me renvoie une erreur sur mon Ps 1.6.0.14 Le lien 'Read this article' arrive sur une page introuvable. Que faire svp ? Link to comment Share on other sites More sharing options...
Mediacom87 Posted August 1, 2015 Share Posted August 1, 2015 (edited) J'affirme donc que tu n'es pas un hacker. Tu comprendras que nous ne pourrons pas révéler plus de details sur l'exploit. Salut, Pas besoin de révéler quoi que se soit. Doekia vous donne tout pour essayer de hacker un site de test pour se faire. Hackez le site et on en parle plus ... Vous avez demandé à la communauté d’essayer d'hacker Prestashop (tiens peut être que c'est à ce moment là que vous avez découvert cette faille, grâce à cette communauté) donc maintenant, à la communauté de vous demander de mettre en application ce que vous avancez. Rappelons les faits : 1 - Si il y a faille c’est très bien de fournir un patch enfin d'essayer de fournir une méthode pour corriger la faille. 2- Par contre que des gens puissent recevoir avant la divulgation de cette faille des mails racoleurs proposant des prestations payantes pour corriger ce soucis de vos partenaire privilégiés payants leur inscription dans ce club tous les ans est juste intolérable pour une solution open source ! Ah, au fait, la PrestaTeam, c'est juste le point 2 qui nous fait honte de soutenir PrestaShop depuis si longtemps. Car cet outil s'appuie clairement sur sa communauté pour avancer et non spécifiquement sur ces partenaires privilégiés. Donc, afin de clore le sujet, comme je l'ai déjà dit, utilisez la faille et hop on passe à autre chose et nous vous soutiendrons grandement pour le déploiement de ce patch de sécurité auprès du plus grand nombre et éviter à Prestashop une pub négative avec tous les sites hacké. Edited August 1, 2015 by Mediacom87 (see edit history) 1 Link to comment Share on other sites More sharing options...
quentin audrain Posted August 3, 2015 Share Posted August 3, 2015 Bonjour à tous, Nous ne souhaitons pas entrer dans le jeu consistant à exploiter la faille sur une boutique pour démontrer notre bonne foi ou notre volonté de sécuriser les boutiques de nos utilisateurs. Nous sommes l'éditeur du logiciel, nous n'allons pas exploiter une faille pour prouver nos dires. Ca n'a juste aucun sens ! À quel moment pensez-vous que c'est une bonne idée pour nous de communiquer sur une faille de sécurité qui serait inexploitable ? Si vous pensez que c'est inexploitable, tant mieux : les marchands sont donc encore plus en sécurité aujourd’hui qu’ils ne l’étaient hier. Encore une fois, et je me répète ici : il n'y a pas d'élite ! Les agences partenaires nous ont aidé à mettre le correctif en place rapidement et à nous assurer de sa bonne implémentation sur toutes les versions ciblées. Nous sommes contractuellement liés à nos agences, et le rapport de confidentialité qu’impliquent ces contrats nous permettait de prendre les devants afin de sécuriser au plus tôt plusieurs milliers de boutiques avant que l’annonce ne devienne publique. Des tests plus longs sur le module, combinés à la malheureuse “fuite” d’une agence partenaire, ont fait que nous n’avons plus étés maîtres de la communication autour de cette mise à jour de sécurité -- ce qui t’a d’ailleurs permis d’avoir le temps d’écrire une nouvelle critique de ton CMS e-commerce préféré, Doekia ! Si des agences partenaires ont proposé de monétiser la mise en place du correctif (grâce à leur contrat de maintenance avec les boutiques dont ils sont responsables), c'est malheureux mais nous ne pouvons pas en être responsables. Mettre à jour une boutique représente un coût humain qui n’est pas forcément négligable (surtout avec parfois plusieurs centaines de boutiques à sécuriser en quelques heures), et chaque agence est libre de faire un geste commercial ou de demander à ses clients de couvrir les frais. N'attendez pas de nous que nous soyons responsables de leurs méthodes de mise à jour. Nous avons proposé plusieurs options pour corriger le problème de sécurité, de la plus simple jusqu’à la plus technique. Toi-même, Doekia, tu indiques ci-dessus que le module de mise à jour en 1 clic “fonctionne sans grand problème” (je te cite) : la première parade aux problèmes de sécurité, à savoir mettre sa boutique à jour, est donc accessible au plus grand nombre. Et, bien que pour l'instant la Communauté n’ait pas reçu de mails, je peux vous affirmer que c'est prévu et que nous l'enverrons en milieu de semaine. Pourquoi un délai entre la publication sur le blog et un avertissement par email ? Les traductions ! Nous souhaitons envoyer ce mail en 8-10 langues pour justement nous assurer que chaque marchand puisse trouver l'info, et ce, dans une langue qu'il comprend et maîtrise. Effectivement, les textes auraient pu être envoyés en traduction il y a longtemps, mais leur rédaction a suivi de près le développement des correctifs et du module… qui n’ont été diffusés qu’une fois pleinement validés. J’en profite pour vous indiquer que le guide de mise à jour technique en français est enfin disponible. Bref, nous n’allons pas nous étendre sur le sujet et répondre à chaque fois les mêmes choses. Tout n’a certes pas été parfait dans la gestion de ce problème de sécurité, et nous en sommes conscients. Nous avons entendu votre point de vue (oui, vraiment !), nous allons faire évoluer nos méthodes. En ce qui nous concerne, le sujet est clos. Si vous avez des problèmes d’application du correctif, n’hésitez pas à lancer un nouveau sujet ! Merci à tous, et bonne semaine, Quentin 1 Link to comment Share on other sites More sharing options...
doekia Posted August 3, 2015 Author Share Posted August 3, 2015 À quel moment pensez-vous que c'est une bonne idée pour nous de communiquer sur une faille de sécurité qui serait inexploitable ? Je ne saurais dire, mais pour paraphraser Galilé - et pourtant elle n'est pas exploitable Si vous pensez que c'est inexploitable, tant mieux : les marchands sont donc encore plus en sécurité aujourd’hui qu’ils ne l’étaient hier. Là je serais du même avis si le fait de parler de faille n'avais pas attiré un nombre notable de kikou-lol pensant être aussi fort que MCGuy de NCIS à tenter dans l'hypothèse où. Toutes les statistiques fail2ban des serveurs que je surveille ayant grimpées depuis l'annonce. Les agences partenaires nous ont aidé à mettre le correctif en place rapidement et à nous assurer de sa bonne implémentation sur toutes les versions ciblées. J'estime que 3 mois c'est pas vraiment rapide - a moins bien sûr de se croire au pays des bisounours dans lequel les hacker attendent gentiment que nous ayons appliqué des patchs avant de tenter de nous pénétrer (pouce les gars je suis pas prêt). Le simple fait de publier un correctif dans la génération des mots de passes est un signal a se demander pourquoi (enfin c'est ce que j'ai fait dès Avril) ... avant que l’annonce ne devienne publique. Pour un hacker l'annonce d'une opportunité potentielle est ici: https://github.com/PrestaShop/PrestaShop/commit/dcb1f8000ecf47437593373091ae56c4ffdf42ac , le 8 avril!! Des tests plus longs sur le module, ... Évident en cas de faille sévère, on ne se contente pas d'émettre un correctif on refait la déco (les 7 correctifs en plus) en même temps ... combinés à la malheureuse “fuite” d’une agence partenaire, ont fait que nous n’avons plus étés maîtres de la communication autour de cette mise à jour de sécurité -- ce qui t’a d’ailleurs permis d’avoir le temps d’écrire une nouvelle critique de ton CMS e-commerce préféré, Doekia ! Ce qui me fait prendre ma plume, c'est d'avoir 3 appels coup sur coup de MES clients ayant reçu des mails d'agences qu'ils ne connaissent pas leur parlant de patch URGENT de sécurité alors que justement je ne suis pas au courant. J'aurai préféré qu'il y ai fuite pour le coup et je considère cela comme de la concurrence déloyale pour le moins avec la bénédiction de PS - me demande si ce n'est pas cela de l'abus de favoritisme, outre le fait que je passe pour un con, je ne dis pas non plus combien je gère de PS tu tomberais par terre. ----8<--------8<--------8<--------8<--------8<--------8<---- J'insiste, il n'y a pas de faille exploitable, vous prétendez avoir pu pénétrer par ce biais je m'inscrit en faux. Le papier duquel sort tout ce patacaisse est le suivant: http://crypto.di.uoa.gr/CRYPTO.SEC/Randomness_Attacks_files/paper.pdf Le cas qui nous incombe est presque intégralement exposé par le cas Joomla (page 24 - en tout point le même code que PS en version 2010+ ) avec ceci de différent pour PrestaShop que le 'config.secret' se nomme COOKEY_KEY et est non pas un 2³² mais un 60⁵⁶. Même en prenant toutes les collisions en compte ça donne plusieurs millions de régénération pour envisager découvrir les 624x32 bits de la machine à état. Si le serveur force les sessions (normalement non avec PS mais admettons), entre les regens et les synchros ça donne des chiffres hors de portées. Il reste ensuite à calculer le seed sachant que pendant ce temps l'administrateur ciblé à reçu un mail avec nouveau mot de passe et ne peux plus se connecter (son mdp ayant changé)... donc si quelqu'un délaisse son système *live* 10 ans, là peut-être. Pour info la découverte du seed avec 10 millions de mt_rand(0,60) lancé il y a 1 semaine, n'a toujours pas aboutie à l'heure qu'il est (encore 5j 7h 53mn), le tout sur un quad Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz - donc 32 thread 196GB de mémoire. (https://github.com/altf4/untwister) Si aucune session ne leak le status des process alors on tombe dans un scénario hollywoodien. C'est strictement impossible. Je me permet d'ailleurs de signaler qu'emprunter un code ne dispense pas de créditer les auteurs initiaux (annexe D p. 34). Finalement comme la https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_par_l%27obscurit%C3%A9 empêche de voir de grosses failles de raisonnement. Donc je peux me tromper, mais je cite mes sources il devrait être aisé à une équipe de gars intelligent et apte sur le sujet de pointer les sophismes qui s'y cache. Quand à prétendre sans preuve ... c'est une épreuve de foi. ----8<--------8<--------8<--------8<--------8<--------8<---- Et puisque nous parlons sécurité j'attends toujours un réponse concernant la faille live_edit 3 Link to comment Share on other sites More sharing options...
fGaillard Posted August 3, 2015 Share Posted August 3, 2015 Duuuuur de bloquer là dessus après tout ce temps et de toujours remettre en question le travail des autres. Si tu n'arrives pas à reproduire c'est pas grave, mais si le patch est sorti c'est pour une bonne raison... Polémiquer autant pour si peu... Il faut avoir du temps à perdre^^ Sur ce, bonne polémique ! Link to comment Share on other sites More sharing options...
doekia Posted August 3, 2015 Author Share Posted August 3, 2015 dixit,un vrai argumentaire! 1 Link to comment Share on other sites More sharing options...
N°6 Posted August 3, 2015 Share Posted August 3, 2015 (edited) @doekia : Laisses tomber , dans ce genre de discussion tu n'auras jamais raison, même si tu as raison @fGaillard : mais si le patch est sorti c'est pour une bonne raison... Au lieu de prendre un ton méprisant avec ceux qui vous payent (et bien oui, c'est grâce à nous, acheteurs de modules et utilisateurs de prestashop que vous pouvez maintenant lever des fonds et payer vos factures), vous feriez mieux de sortir un patch qui fonctionne pour toutes les versions de prestashop, et pas seulement pour les dernières versions des 1.4,1.5 et 1.6. Oui votre module de mise à jour en 1 clic n'est toujours pas abouti et m'a obligé , ainsi que plusieurs autres commerçants de mon entourage, à devoir réinstaller prestashop chaque fois que l'on a tenté une mise à jour, même sur un thème d'origine sans modules supplémentaires. Oui, vous êtes en faute car depuis avril vous saviez déjà que ce problème existait mais bon , apparemment cela ne vous a pas dérangé plus que cela. Alors arrêtez de nous balader avec vos messages, nous ne sommes pas dupes, nous sommes juste devenus "dépendants" de prestashop et nous n'avons apparemment qu'à nous taire. Je trouve cela insultant à la longue en tant que client de votre "solution" e-commerce de nous prendre pour des neuneus. Maintenant si vous souhaitez me bannir pour mes propos allez-y, cela ne fera que confirmer que vous avez perdu au fil du temps ce qui avait fait votre succès : votre âme. Edited August 4, 2015 by N°6 (see edit history) 2 Link to comment Share on other sites More sharing options...
makinero Posted August 26, 2015 Share Posted August 26, 2015 J’en profite pour vous indiquer que le guide de mise à jour technique en français est enfin disponible. J'ajoute qu'il est buggué, CF les commentaires (idem pour la version anglaise). Il manque aussi des précisions comme supprimer le fichier /cache/class_index.php pour que les modifs soient prises en compte ou encore de regarder dans le dossier override si les fichiers à patcher ne sont n'ont pas été surchargés. Sans ces précautions, l'application du patch par remplacement des fichiers par ceux fournis pourraient être inefficaces... voir causer des problèmes. Je regrette également qu'il n'y ait pas plus de versions supportées par les patchs publiés. Vu les modifs à faire, en 2-3h max vous auriez pu mettre à disposition les fichiers pour au moins toutes les versions 1.6 et rendre service à beaucoup de monde !! Link to comment Share on other sites More sharing options...
makinero Posted August 27, 2015 Share Posted August 27, 2015 Dans le cadre d'une application manuelle du correctif, je recommanderais également de comparer les fichiers en question avec les fichiers d'une version non modifiée (téléchargée et toute fraîche). Les fichiers core ont peut-être été modifiés comme un bourrin sans override. Link to comment Share on other sites More sharing options...
ChDUP Posted August 27, 2015 Share Posted August 27, 2015 faut pas non plus tout mettre sur le dos de la team Presta C'est sur que si les fichiers Core en question ont déjà été modifiés .... il faudra ré-appliquer les modifs (et en profiter pour les faire proprement, par overrides) ça tombe sous le sens, ils n'y peuvent rien sur ce coup Link to comment Share on other sites More sharing options...
makinero Posted September 8, 2015 Share Posted September 8, 2015 Pour un développeur aguéri, oui, ça tombe sous le sens mais tout le monde n'est pas dans ce cas ! Et même, c'est toujours bon de le rappeler, ça prend quelques lignes et ne mange pas de pain ! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now