Mon Institut Beauté Posted February 13, 2017 Share Posted February 13, 2017 Bonjour, Nous avons récemment été piratés pour la deuxième fois. Nous avons tout remis en ordre (sauvegarde snapshot OVH) + nettoyage de fichiers. Nous aimerions savoir si : - certains modules ouvrent des portes non sécurisées ? (smartsupp, colissimo, paypal, klikandpay, payplug, promo panier, seo expert, shopping- flux,- avez vous eu es problèmes avec certains modules ? - comment avez-vous sécurisé prestashop ? Merci Link to comment Share on other sites More sharing options...
doekia Posted February 13, 2017 Share Posted February 13, 2017 Si tu as été pénétré pour la 2éme fois, alors il est certain que: - soit ton nettoyage à oublié quelques porte dérobées qui ont été installées lors de la 1er attaque. - soit qu'un module contient un faille en effet. De nombreux module ont été répertoriés en Juin/Juillet 2015 comme ayant des failles et on en retrouve de temps en temps au grès de nouvelle methode d'attaque. Il faut identifier la manière avec laquelle itls ont procédé pour definitivement régler le problème. C'est un travail de fourmi, long et pénible Link to comment Share on other sites More sharing options...
_tech Posted February 14, 2017 Share Posted February 14, 2017 Bonjour, Je confirme il est fort possible qu'un de vos modules possède une faille. Je peux vous aider à trouver la "porte d'entrée" si vous le souhaitez, j'aime le travail long et pénible. Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 14, 2017 Author Share Posted February 14, 2017 Bonjour, Merci pour vos réponses rapides ! Sachez également que nous avons supprimé tous les modules que nous n'utilisons pas. Voici la liste des modules que nous utilisons : smartsupp, colissimo, paypal, klikandpay, payplug, promo panier, seo expert, shopping- flux. Link to comment Share on other sites More sharing options...
_tech Posted February 14, 2017 Share Posted February 14, 2017 Merci pour vos précisions cependant trouver des failles avec des noms de modules c'est un peu mince :-) Il faut étudier le code source et la configuration. Je suis disponible en message privé ou sur mon site si vous le souhaitez. Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 14, 2017 Author Share Posted February 14, 2017 Si tu as été pénétré pour la 2éme fois, alors il est certain que: - soit ton nettoyage à oublié quelques porte dérobées qui ont été installées lors de la 1er attaque. - soit qu'un module contient un faille en effet. De nombreux module ont été répertoriés en Juin/Juillet 2015 comme ayant des failles et on en retrouve de temps en temps au grès de nouvelle methode d'attaque. Il faut identifier la manière avec laquelle itls ont procédé pour definitivement régler le problème. C'est un travail de fourmi, long et pénible Comment identifier la manière dont ils ont procédé ? Link to comment Share on other sites More sharing options...
doekia Posted February 14, 2017 Share Posted February 14, 2017 Analyses des logs ... Link to comment Share on other sites More sharing options...
BeComWeb Posted February 14, 2017 Share Posted February 14, 2017 D'une manière générale les thèmes et les modules distribués via le store officiel de Prestashop ne sont pas sensés avoir de faille de sécurité puisqu'avant d'y être proposés ils doivent passer un "contrôle qualité" strict faits par les équipes de PS. On ne peut pas en dire autant des thèmes trouvés sur Template Monster et autres, ou des modules gratuits ou payants trouvés à droite à gauche (y compris sur ce forum). Link to comment Share on other sites More sharing options...
doekia Posted February 14, 2017 Share Posted February 14, 2017 @BeComWeb Totalement faux en ce qui concerne les modules "officiels", d'ailleurs des pénétrations de l'été dernier plus de 75% avaient pour cause des modules non seulement officiel "addons", mais écris par la team elle-même. Pour un hacker il est plus facile de cibler des modules largement répandus que de trouver au coup par coup une faille qui ne sera exploitable que sur 2 boutiques dans l'univers Link to comment Share on other sites More sharing options...
BeComWeb Posted February 14, 2017 Share Posted February 14, 2017 @BeComWeb Totalement faux en ce qui concerne les modules "officiels", d'ailleurs des pénétrations de l'été dernier plus de 75% avaient pour cause des modules non seulement officiel "addons", mais écris par la team elle-même. Pour un hacker il est plus facile de cibler des modules largement répandus que de trouver au coup par coup une faille qui ne sera exploitable que sur 2 boutiques dans l'univers D'où l'utilisation de termes comme "D'une manière générale" ou "ne sont pas sensés". Ca permet d'exprimer la nuance Après ton argument du "plus c'est répandu plus c'est susceptible d'être attaqué" est vrai. En revanche le fait que la team PS ne valide pas un module si les mesures nécessaires ne sont pas prises contre les injections SQL (par exemple) est un garantie de sécurité supplémentaire qu'un utilisateur n'aura pas forcément avec un module "non officiel". Ce qu in'enlève rien au fait qu'il existe des modules non-officiels de très bonne qualité et dont la sécurité est aussi solide que celle d'un officiel. 1 Link to comment Share on other sites More sharing options...
Eolia Posted February 15, 2017 Share Posted February 15, 2017 On parle en l'air là^^ Un nettoyage, ça commence par mettre le site hors-ligne. Je n'ai pas dit "Mode Maintenance" qui n'empêche pas l'appel direct à un fichier donné, mais hors-ligne ce qui signifie, renommage du www et mise en place d'une page statique sur un autre www Autrement, pendant que vous "nettoyez" les scripts automatiques ou les hackers eux-mêmes sont en train d'en remettre sur les premiers qui ont été nettoyés... Sauvegarde/snapshot de quand ? les hacks ont commencé le 8 juillet 2016, ça m'étonnerait que vous ayez une sauvegarde antérieure et même si c'était le cas, vous perdez toutes les données de cette date jusqu'à aujourd'hui Un prestashop c'est environ 40 000 fichiers et 300 000 lignes de code. Pour avoir nettoyé une 40aine de boutique depuis juillet je peux vous dire que les formes de hacks sont toutes différentes même si on retrouve des similitudes. - hack de l'adminLogin - hack des modules "officiels" - création de sitemaps - usurpation de propriétaire webmastertools - ajout de fausses images dans le répertoire img/p - détournement des interfaces de paiement - Ajout de faux- modules - phpmailers - fishing - ajout de site complet en plus du Prestashop - modification des index - etc... Quand tous ces points auront été contrôlés et que tous les codes ajoutés/modifiés auront été identifiés, je pense que vous pourrez parler de nettoyage et remettre votre site en ligne. 1 Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 15, 2017 Author Share Posted February 15, 2017 Merci pour toutes ces pistes ! Nous avons effectué déjà pas mal de choses en ce sens et continuons. Avez-vous également des modules ou des techniques / tutos pour sécuriser prestashop et/ou le thème ? Link to comment Share on other sites More sharing options...
BeComWeb Posted February 15, 2017 Share Posted February 15, 2017 On parle en l'air là^^ Totalement Et Mon Institut Beauté, je pense que vous avez trouvé l'homme de la situation. Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 15, 2017 Author Share Posted February 15, 2017 (edited) En plus du nettoyage en profondeur des fichiers, j'ai rajouter les sécurités suivantes : - blocage du dossier admin (qui est renommé, rassurez-vous) - blocage de l'accès aux fichiers tpl du thème Me conseillez-vous des modules de sécurité ou non ? Nous sommes hésitants sur ce point, car nous avons entendu dire que les modules de sécurité peuvent ouvrir des portes (vu qu'ils sont eux-même des modules...) Merci Edited February 15, 2017 by Mon Institut Beauté (see edit history) Link to comment Share on other sites More sharing options...
Eolia Posted February 16, 2017 Share Posted February 16, 2017 On continue à parler dans le vide, mais bon... Bloquer l'admin, ha ha ha ! (Excusez-moi) Si le hacker est déjà sur le ftp et a déposé son wso, ben...vous ne bloquez rien du tout^^ Idem pour les tpl Modules de sécurité ? Peau de balle, on reste en php donc à moins de lancer des crons toutes les minutes pour savoir si un fichier a été modifié, vous n'arriverez à rien à part ralentir encore plus votre shop. Si sécurité il y a c'est au niveau d'apache et réseau, autrement dire: inaccessible sur un mutu Ensuite cela veut dire, ne pas installer n'importe quoi, surtout les modules "gratuits" ou "intégrés" dans les thèmes Surveiller ses logs (surtout error.log) et les $_POST de l'access.log tous les jours 2 Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 16, 2017 Author Share Posted February 16, 2017 Merci ! Par wso, vous parlez d'un fichier ".wso" ? C'est un peu désemparant, je commence à avoir l'impression qu'on ne peut pas faire grand chose : - le tris au niveau des modules a été fait (avec suppression des fichiers) - nous faisons toujours attention à ne pas acheter/installer n'importe quel module - si les blocages tpl & htpasswd ne sont pas si efficaces, pourquoi les mettre en place ? Nous souhaitons également mettre en place des actions pour contrer les attaques XSS Le soucis, c'est que nous sommes sur un hébergement mutualisé. Je suis conscient que la cybersécurité est un jeu éternel chat-souris, mais surveiller les logs est vraiment la seule chose à faire ? Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 17, 2017 Author Share Posted February 17, 2017 Bonjour, J'ai rajouté de nombreuses mesures de protection contre des attaques XSS, injection SQL ou autres. J'ai cependant une dernière question concernant une mesure où je suis pas très sûr de vouloir mettre en place : il est possible de modifier les droits en lecture/écriture des dossiers du serveur. Cependant, à quels dossiers/fichiers est-ce que je peux attribuer les droits suivants ? - 404 ou 444 (lecture et non écriture pour les fichiers) - 505 ou 555 (lecture et non écriture pour les dossiers) Il me parait évident qu'il faut laisser les droits d'écriture pour le cache vu qu'il change très souvent, mais pour les autres dossiers ? - le dossier admin - classes - config - controllers - core ..... Je ne suis pas certains de quels fichiers et dossiers sont utilisés ou non4 Merci Link to comment Share on other sites More sharing options...
_tech Posted February 17, 2017 Share Posted February 17, 2017 Bonjour, J'ai rajouté de nombreuses mesures de protection contre des attaques XSS, injection SQL ou autres. Pouvez vous nous dire à quel niveau (et comment) vous avez mis en place ces mesures de protection s'il vous plaît ? Link to comment Share on other sites More sharing options...
doekia Posted February 17, 2017 Share Posted February 17, 2017 (edited) Comment dire. Changer tes permissions, ça va plus t'embeter toi que les hacker. J'ai, je dirais 100+ installations et elle ont toutes 755 sur les dossiers et 644 sur les fichiers - toi c'est OVH donc traduire en 705 et 604. Si les hacker ont posés une porte, ils ont de quoi lancer un chmod donc tu ne gène que les Kevins, - ceux qui pètent ton shop que tu vois immédiatement grace a des pages arbres de Noël. Les Kévins ils viennent ils pètent, tu regarde les logs, tu trouve vite comment ils sont rentrés, tu ferme et basta. D'ailleurs les Kévins ne pénètrent pas les prestashop en général mais ton PC. Les vrais hackeur, eux se font discret, revendent de la bande passant de ton hébergement pour des spams Collectent des données bancaire avec des pages phishing, ... Si tu ne surveille pas et que personne ne remonte le pb, ça peut être là depuis des mois à ton insu. --- Toi par contre en changeant tes permissions, tu va devoir regarder tous modules pour vérifier qu'ils n'ont pas besoin d'écrire, des logs, des configs, etc Impossible de faire de traduction de module sans te prendre la tête Impossible d'installer un module sans te prendre la tête === Mais pour répondre à ta question, tout cache, themes/*/cache, tout img ont impérativement besoin des permissions d'écriture. Ajouter la racine pour les fichiers .htacces, sitemapXXX, robots Mais je si devais te hacker, un simple chmod -R a+rwx . et j'ai résolu mon problème sur l'intégralité de ton site ~~~~~~~~ Pour les puristes, oui ce que je raconte ici est plein de simplifications extrême, et donc, chaque phrase affirmation est à mettre entre guillemet. Edited February 17, 2017 by doekia (see edit history) 1 Link to comment Share on other sites More sharing options...
Mon Institut Beauté Posted February 20, 2017 Author Share Posted February 20, 2017 Merci pour toutes ces infos, même si elles ne sont pas forcément rassurantes ! (surtout le dernier point) Link to comment Share on other sites More sharing options...
Eolia Posted February 20, 2017 Share Posted February 20, 2017 C'est sûr que tant que vous resterez sur un mutualisé, des outils puissants comme failtoban vous restent inaccessibles. Mais si c'est votre choix... Link to comment Share on other sites More sharing options...
.png.022b5452a8f28f552bc9430097a16da2.png)
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