Aide - Recherche - Membres - Calendrier
Version complète : Attention PIRATAGE
Forum osCommerce-fr > Adapter OsCommerce MS2 > Sécurité - Mises à jour
forgiven
Bonjour

Je voudrais comprendre comment on a eu pu entrer dans l'admin, changer mon email (email de l'administrateur) par ZimboMba7@gmail.com

est ce que vous avez une idée sur cette email ZimboMba7@gmail.com

pour le moment j'ai changé les information via la base de donnée, il n'a rien fait de grave, mais est qu'est ce que vous me conseiller de vérifier ou de changer ?


Merci d'avance
Gnidhal
Mettre une protection .htaccess / .htpasswd sur le dossier d'administration.
Comme c'est indiqué dans la FAQ en somme.
brouillard
Citation (forgiven @ 21 Feb 2010, 22:08) *
Bonjour

Je voudrais comprendre comment on a eu pu entrer dans l'admin, ...


Bonjour,

je pense qu'ils sont rentrés comme ça :

-http://www.taboutique.fr/admin/file_manager.php/login.php?action=save HTTP/1.1

j'ai testé sur ma boutique et ça marche, et pas qu'avec file_manager.php, avec tout le reste, on peut même envoyer des mails de ta boutique.

J'ai trouvé cette source en anglais, mais pas d'équivalent en français !

http://forums.oscommerce.com/topic/351671-...ginphp-exploit/
Bonbec
Citation (brouillard @ 26 Feb 2010, 15:59) *
-http://www.taboutique.fr/admin/file_manager.php/login.php?action=save HTTP/1.1
j'ai testé sur ma boutique et ça marche, et pas qu'avec file_manager.php, avec tout le reste, on peut même envoyer des mails de ta boutique.

Cela veut dire que ton dossier admin n'est pas protégé par un htaccess angry.gif ...
brouillard
Voila comment corriger le bug selon la source que j'ai mentionnée plus haut :

Vers la ligne 150 de admin/includes/application_top.php

trouver ce code
CODE
$redirect = true;
}



Coller ce code juste après la "}"
CODE
#correction bug pirate

if (!isset($login_request) || isset($HTTP_GET_VARS['login_request']) || isset($HTTP_POST_VARS['login_request']) || isset($HTTP_COOKIE_VARS['login_request']) || isset($HTTP_SESSION_VARS['login_request']) || isset($HTTP_POST_FILES['login_request']) || isset($HTTP_SERVER_VARS['login_request'])) {
$redirect = true;
}
# fin correction bug pirate



Dans admin/login.php Ligne 11 "après le comentaire"

CODE

Released under the GNU General Public License
*/


Rajouter cette ligne
CODE

$login_request = true;



Testé sur ma boutique, ça marche
brouillard
Citation (Bonbec @ 26 Feb 2010, 16:24) *
Cela veut dire que ton dossier admin n'est pas protégé par un htaccess angry.gif ...


Mon dossier admin ne s'appel plus admin je l'ai rebaptisé depuis belle lurette et il est bien protégé par un htaccess et un mot de passe crypté, malgré cela cette arnaque marche à merveille pour le hackeurs, et si tu es d'accord on peut tester sur ta boutique !
sykaflex
salut brouillard
c'est vrai que tes explications c'est le fog complet tongue.gif
Citation
Mon dossier admin ne s'appel plus admin je l'ai rebaptisé depuis belle lurette et il est bien protégé par un htaccess et un mot de passe crypté, malgré cela cette arnaque marche à merveille pour le hackeurs, et si tu es d'accord on peut tester sur ta boutique !
d'autant plus que d'après toi "l'arnaqeur" utiliserait la combine de bonbec, connaitrait le nouveau nom de ton dossier admin, et malgré .htaccess et .htpassword, déboulerait sur ton file_manager.php que tu aurais viré de ton serveur puisque la prudence et les faq t'ont recommandé de le virer !
donc soit nous nous trouvons devant une nouvelle énorme faille de sécurité de osC, soit c'est le brouillard complet !
il faudrait en fait que tu énumères exactement les opérations de sécurité que tu as réalisé sur ton site et malgré les quelles ton hacker a pu passé au travers.
brouillard

Bonjour sykaflex,

Le hackeur n'a pas visité ma boutique, mais celle du pauvre forgiven, quant à moi j'ai découvert cette faille que j'ai testé moi-même, et non le hackeur, sur ma boutique et j'ai constaté, moi-même et pas le hackeur, qu'elle marche. Après la mise à jour, la faille a disparue et me revoie vers la page de login.php

Mais c'est vrai qu'avec le dossier admin rebaptisé le hackeur a mois de chance de me retrouver.
Bonbec
Citation (brouillard @ 26 Feb 2010, 16:43) *
Mon dossier admin ne s'appel plus admin je l'ai rebaptisé depuis belle lurette et il est bien protégé par un htaccess et un mot de passe crypté, malgré cela cette arnaque marche à merveille pour le hackeurs, et si tu es d'accord on peut tester sur ta boutique !

Je viens de tester sur ma boutique et çà ne passe pas, mon htaccess joue bien son rôle. blush.gif
forgiven
Merci pour vos réponses

j'ai changé le nom du dossier admin depuis un an déjà.

le problème est que maintenant il utilise mon smtp pour envoyé des spam

il a réussit, et je ne sais pas du tout comment faire un nettoyage.

j'ai vérifié par date les modifications apporté au fichier et dossier et je n'ai trouvé auncun rajout de fichier ni de dossier, ni modification de mes fichiers.

Je viens de rajouter le htacess dans l'admin, je vais suivre aussi les conseils de ce post

Si vous avez d'autres conseils ca serai super

pour info, je n'ai pas trouvé
Citation
$redirect = true;
}
dans admin/includes/application_top.php ni de variable $redirect

Merci
brouillard
Citation (forgiven @ 27 Feb 2010, 08:08) *
Merci pour vos réponses
....

pour info, je n'ai pas trouvé
Citation
$redirect = true;
}
dans admin/includes/application_top.php ni de variable $redirect

Merci


Si tu n'as pas le même code dans application_top que celui-là, c'est que tu as une autre version de osc ou ton code a été modifié
CODE
<?php
/*
$Id: $

osCommerce, Open Source E-Commerce Solutions
http://www.oscommerce.com

Copyright © 2007 osCommerce

Released under the GNU General Public License
*/

// Start the clock for the page parse time log
define('PAGE_PARSE_START_TIME', microtime());

// Set the level of error reporting
error_reporting(E_ALL & ~E_NOTICE);
// error_reporting(E_ALL | E_STRICT);

// check support for register_globals
if (function_exists('ini_get') && (ini_get('register_globals') == false) && (PHP_VERSION < 4.3) ) {
exit('Server Requirement Error: register_globals is disabled in your PHP configuration. This can be enabled in your
php.ini configuration file or in the .htaccess file in your catalog directory. Please use PHP 4.3+ if register_globals cannot be
enabled on the server.');
}

// Set the local configuration parameters - mainly for developers
if (file_exists('includes/local/configure.php')) include('includes/local/configure.php');

// Include application configuration parameters
require('includes/configure.php');

// Define the project version
define('PROJECT_VERSION', 'osCommerce Online Merchant v2.2 RC1 W3C Valid FR');

// some code to solve compatibility issues
require(DIR_WS_FUNCTIONS . 'compatibility.php');

// set php_self in the local scope
$PHP_SELF = (isset($HTTP_SERVER_VARS['PHP_SELF']) ? $HTTP_SERVER_VARS['PHP_SELF'] : $HTTP_SERVER_VARS['SCRIPT_NAME']);

// Used in the "Backup Manager" to compress backups
define('LOCAL_EXE_GZIP', '/usr/bin/gzip');
define('LOCAL_EXE_GUNZIP', '/usr/bin/gunzip');
define('LOCAL_EXE_ZIP', '/usr/local/bin/zip');
define('LOCAL_EXE_UNZIP', '/usr/local/bin/unzip');

// include the list of project filenames
require(DIR_WS_INCLUDES . 'filenames.php');

// include the list of project database tables
require(DIR_WS_INCLUDES . 'database_tables.php');

// customization for the design layout
define('BOX_WIDTH', 125); // how wide the boxes should be in pixels (default: 125)

// Define how do we update currency exchange rates
// Possible values are 'oanda' 'xe' or ''
define('CURRENCY_SERVER_PRIMARY', 'oanda');
define('CURRENCY_SERVER_BACKUP', 'xe');

// include the database functions
require(DIR_WS_FUNCTIONS . 'database.php');

// make a connection to the database... now
tep_db_connect() or die('Unable to connect to database server!');

// set application wide parameters
$configuration_query = tep_db_query('select configuration_key as cfgKey, configuration_value as cfgValue from ' . TABLE_CONFIGURATION);
$config_flag_in = array('Oui', 'Non');
$config_flag_out = array('true', 'false');
while ($configuration = tep_db_fetch_array($configuration_query)) {
$configuration['cfgValue'] = str_replace($config_flag_in, $config_flag_out, $configuration['cfgValue']);
define($configuration['cfgKey'], $configuration['cfgValue']);
}

// define our general functions used application-wide
require(DIR_WS_FUNCTIONS . 'general.php');
require(DIR_WS_FUNCTIONS . 'html_output.php');

// initialize the logger class
require(DIR_WS_CLASSES . 'logger.php');

// include shopping cart class
require(DIR_WS_CLASSES . 'shopping_cart.php');

// check to see if php implemented session management functions - if not, include php3/php4 compatible session class
if (!function_exists('session_start')) {
define('PHP_SESSION_NAME', 'osCAdminID');
define('PHP_SESSION_PATH', '/');
define('PHP_SESSION_SAVE_PATH', SESSION_WRITE_DIRECTORY);

include(DIR_WS_CLASSES . 'sessions.php');
}

// define how the session functions will be used
require(DIR_WS_FUNCTIONS . 'sessions.php');

// set the session name and save path
tep_session_name('osCAdminID');
tep_session_save_path(SESSION_WRITE_DIRECTORY);

// set the session cookie parameters
if (function_exists('session_set_cookie_params')) {
session_set_cookie_params(0, DIR_WS_ADMIN);
} elseif (function_exists('ini_set')) {
ini_set('session.cookie_lifetime', '0');
ini_set('session.cookie_path', DIR_WS_ADMIN);
}

// lets start our session
tep_session_start();

if ( (PHP_VERSION >= 4.3) && function_exists('ini_get') && (ini_get('register_globals') == false) ) {
extract($_SESSION, EXTR_OVERWRITE+EXTR_REFS);
}

// set the language
if (!tep_session_is_registered('language') || isset($HTTP_GET_VARS['language'])) {
if (!tep_session_is_registered('language')) {
tep_session_register('language');
tep_session_register('languages_id');
}

include(DIR_WS_CLASSES . 'language.php');
$lng = new language();

if (isset($HTTP_GET_VARS['language']) && tep_not_null($HTTP_GET_VARS['language'])) {
$lng->set_language($HTTP_GET_VARS['language']);
} else {
$lng->get_browser_language();
}

$language = $lng->language['directory'];
$languages_id = $lng->language['id'];
}

// redirect to login page if administrator is not yet logged in
if (!tep_session_is_registered('admin')) {
$redirect = false;

$current_page = basename($PHP_SELF);

if ($current_page != FILENAME_LOGIN) {
if (!tep_session_is_registered('redirect_origin')) {
tep_session_register('redirect_origin');

$redirect_origin = array('page' => $current_page,
'get' => $HTTP_GET_VARS);
}

$redirect = true;
}


if ($redirect == true) {
tep_redirect(tep_href_link(FILENAME_LOGIN));
}

unset($redirect);
}

// include the language translations
require(DIR_WS_LANGUAGES . $language . '.php');
$current_page = basename($PHP_SELF);
if (file_exists(DIR_WS_LANGUAGES . $language . '/' . $current_page)) {
include(DIR_WS_LANGUAGES . $language . '/' . $current_page);
}

// define our localization functions
require(DIR_WS_FUNCTIONS . 'localization.php');

// Include validation functions (right now only email address)
require(DIR_WS_FUNCTIONS . 'validations.php');

// setup our boxes
require(DIR_WS_CLASSES . 'table_block.php');
require(DIR_WS_CLASSES . 'box.php');

// initialize the message stack for output messages
require(DIR_WS_CLASSES . 'message_stack.php');
$messageStack = new messageStack;

// split-page-results
require(DIR_WS_CLASSES . 'split_page_results.php');

// entry/item info classes
require(DIR_WS_CLASSES . 'object_info.php');

// email classes
require(DIR_WS_CLASSES . 'mime.php');
require(DIR_WS_CLASSES . 'email.php');

// file uploading class
require(DIR_WS_CLASSES . 'upload.php');

// calculate category path
if (isset($HTTP_GET_VARS['cPath'])) {
$cPath = $HTTP_GET_VARS['cPath'];
} else {
$cPath = '';
}

if (tep_not_null($cPath)) {
$cPath_array = tep_parse_category_path($cPath);
$cPath = implode('_', $cPath_array);
$current_category_id = $cPath_array[(sizeof($cPath_array)-1)];
} else {
$current_category_id = 0;
}

// default open navigation box
if (!tep_session_is_registered('selected_box')) {
tep_session_register('selected_box');
$selected_box = 'configuration';
}

if (isset($HTTP_GET_VARS['selected_box'])) {
$selected_box = $HTTP_GET_VARS['selected_box'];
}

// the following cache blocks are used in the Tools->Cache section
// ('language' in the filename is automatically replaced by available languages)
$cache_blocks = array(array('title' => TEXT_CACHE_CATEGORIES, 'code' => 'categories', 'file' => 'categories_box-language.cache', 'multiple' => true),
array('title' => TEXT_CACHE_MANUFACTURERS, 'code' => 'manufacturers', 'file' => 'manufacturers_box-language.cache', 'multiple' => true),
array('title' => TEXT_CACHE_ALSO_PURCHASED, 'code' => 'also_purchased', 'file' => 'also_purchased-language.cache', 'multiple' => true)
);

// check if a default currency is set
if (!defined('DEFAULT_CURRENCY')) {
$messageStack->add(ERROR_NO_DEFAULT_CURRENCY_DEFINED, 'error');
}

// check if a default language is set
if (!defined('DEFAULT_LANGUAGE')) {
$messageStack->add(ERROR_NO_DEFAULT_LANGUAGE_DEFINED, 'error');
}

if (function_exists('ini_get') && ((bool)ini_get('file_uploads') == false) ) {
$messageStack->add(WARNING_FILE_UPLOADS_DISABLED, 'warning');
}
?>
Rik2009
alors juste pour info j'ai essayer la ligne que tu donne:
-http://www.taboutique.fr/admin/file_manager.php/login.php?action=save HTTP/1.1

avec un autre fichier que file_manager et un autre nom que admin puisque tout cela à été changer et mon htaccess fait aussi très bien sons boulot puisqu'il me demande le mot de passe.
Maintenant si j'enlève le htaccess il est clair qu'il y à un accès au fichier demander et ta solution fonctionne très bien, une fois que l'on insère ton code on à un retour direct sur le login.php
alors comme je suis plutôt du genre à pensé que 2 solutions valle mieux qu'une on sais jamais.
ngmsky
Citation (brouillard @ 26 Feb 2010, 17:13) *
Bonjour sykaflex,

Le hackeur n'a pas visité ma boutique, mais celle du pauvre forgiven,
...
Après la mise à jour, la faille a disparue et me revoie vers la page de login.php

Mais c'est vrai qu'avec le dossier admin rebaptisé le hackeur a mois de chance de me retrouver.


Bonjour a tous.
Brouillard, si j'ai bien compris, il y'a une mise à jour qui corrige cette faille de sécurité.
Pourrai-je savoir de quelle mise à jour sagit-il ?
De même, pourrai-je savoir la version que tu utilisait juste avant cette mise à jour ?

De plus, je ne comprends pas comment cette faille arrivait à fonctionner chez toi alors qu'il y'avait le htaccess + htpassword ?

Logiquement, même si ta version n'tait pas sécurisée, mais rien que la présence du htacces bien configuré devrait suffir pour empéché ce type de hack, même sans rebatiser le admin, n'est -ce pas ?

Je suis loin d'être un expert en sécurité mais d'après ce qu'on sait tous sur htccess, je suis très très surpris d'aprendre qu'il peut laisser un accès libre a une ressources qu'il est censé protéger.

Merci infiniment pour tes reponses et pour ta solution complémentaire (isset...) c'est toujours bien d'être doublement sécurisé.
ngmsky
Citation (sykaflex @ 26 Feb 2010, 17:01) *
...
d'autant plus que d'après toi "l'arnaqeur" utiliserait la combine de bonbec, connaitrait le nouveau nom de ton dossier admin, et malgré .htaccess et .htpassword, déboulerait sur ton file_manager.php que tu aurais viré de ton serveur puisque la prudence et les faq t'ont recommandé de le virer !


Bonjour sykaflex,
J'aimerai savoir si tu peux me donner le lien de la FAQ qui remcommande de virer le file_manager.php.

Je savais qu'on devrait renommer, mieux encore virer le dossier install, juste après l'installation de la boutique, je savais aussi qu'il était conseillé de renommer d'autres dossiers et fichiers (ex: admin, htacces, etc.)
Et je suis surpris de savoir qu'il y'avait d'autres fichiers qu'on devrait virer !

Merci donc pour me donner un lien de cette recommandation.


Citation (Rik2009 @ 28 Feb 2010, 04:05) *
alors juste pour info j'ai essayer la ligne que tu donne: ...

----------
osCommerce MS2 RC1FRW3C + Pacth RC2aFRW3C (pour mon nouveau site) pour l'autre osCommerce MS2 RC1FRW3C


Bonjour Rik2009,
Peux tu me donner le lien du patch que tu as cité dans ta signature ?
En faite, sur la page des téléchargements, je ne trouve "aucun" patch pour Osc v2.2 RC1 W3C Valid FR v3 Mais seulement des patch pour l'ancienne version de Osc (MS2 d'origine).

Et d'une manniere globale, j'aimerai savoir quelle est la derniere mise à jour valide à ce jour ?
Je ne comprends plus rien. J'ai comme l'impression qu'il y'a plein de petites mise à jour (patch) (depuis la MS2.2 rc1 w3c-3) mais elles ne sont pas répertoriées dans le même endroit et j'ai du mal à les trouver.

En passant j'ai trouvé une autre boutique oscommerce pirater par la même personne (même adresse mail) et il a envoyé des mails etc.

voici le lien


un autre site en englais qui explique la faille est ici

Merci de m'aider à trouver la dernière mise à jour
Gnidhal
C'est la raison pour laquelle nous conseillons d'ajouter un .htaccess à la section admin en plus de la protection par session.
Avec un .htaccess et un .htpasswd il est impossible d'attaquer directement les scripts de ce répertoire. Il n'y a donc plus aucune faille potentielle.
ngmsky
Merci pour ce rappel sur l'utilité presqu'obligatoire du .htaccess et .htpassword

Sinon que penses tu de cette déclaration de brouillard (en attendant sa réponse à ma question) ?
Ce n'est pas pour vous confronter à une difficulté, mais juste que c'est un peut difficile à digérer.
D'une part, connaissant, la réputation du couple .htaccess et .htpassword et d'autre part, un membre déclare que même avec ce couple, l'accès à ces ressources est toujours possible à n'importe qui, ça fait quand même réfléchir.

Citation (brouillard @ 26 Feb 2010, 16:43) *
...
Mon dossier admin ne s'appel plus admin je l'ai rebaptisé depuis belle lurette et il est bien protégé par un htaccess et un mot de passe crypté, malgré cela cette arnaque marche à merveille pour le hackeurs, et si tu es d'accord on peut tester sur ta boutique !




Et que penses tu de ceci ?
Citation (sykaflex @ 26 Feb 2010, 17:01) *
...
d'autant plus que d'après toi "l'arnaqeur" utiliserait la combine de bonbec, connaitrait le nouveau nom de ton dossier admin, et malgré .htaccess et .htpassword, déboulerait sur ton file_manager.php que tu aurais viré de ton serveur puisque la prudence et les faq t'ont recommandé de le virer !




Je savais qu'on devrait supprimer le dossier maboutique.com/install, juste après l'installation de la boutique, je savais aussi qu'il était conseillé de renommer d'autres dossiers et fichiers (ex: admin, htpasword ou l'heberger dans un autre dossier sécurié ou sur un autre serveur , etc.)

Et je suis surpris de savoir qu'il y'avait d'autres fichiers (comme file_manager.php) que la FAQ nous conseil de virer !

Confirmes tu cette affirmation ?
Si oui, pourras tu nous faire un lien, stp vers cette information ? car j'en ai jamais vu dans la FAQ.


Pour finir, j'en profite de ta présence dans ce sujet pour savoir si il faut installer une mise à jour (patch) quelconque après l'install de "Oscommerce MS2.2 RC1 W3C-3" ?
j'ai consulté la page de téléchargement mais il n'y a pas de patch pour cette derniere version, seulement pour la MS2 d'origine (l'ancienne), J'ai lu également les sujet dans la rubrique sécurité et mise à jour, et je suis un peu perdu.

Autrement, j'aimerai demander, actuellement quelque est la version de oscommerce ainsi que du patch le plus à jour ?

Merci infiniment à toi et au reste de l'équipe, pour votre assistance et vos efforts démésurés.
Soyez bénit
Bonbec
Citation (ngmsky @ 29 Mar 2010, 15:12) *
D'une part, connaissant, la réputation du couple .htaccess et .htpassword et d'autre part, un membre déclare que même avec ce couple, l'accès à ces ressources est toujours possible à n'importe qui, ça fait quand même réfléchir.

Il devait avoir l'accès à son administration dans son cache, en vidant le cache l'accès est impossible d'accéder à l'administration sans passer par l'.htaccess.
Pour ma gouverne personnelle, quelle est la réputation du couple .htaccess et .htpassword ?
ngmsky
Citation (Bonbec @ 29 Mar 2010, 15:36) *
Il devait avoir l'accès à son administration dans son cache, en vidant le cache l'accès est impossible d'accéder à l'administration sans passer par l'.htaccess.

Bonjour cher ami et merci pour ta réponse.

J'avais aussi pensé au cache mais j'avais tout de suite écarté cette hypothese. je m'explique :
si le cache a en mémoire la page : monsite.com/page1.php?action=abcd, il mettra à nouveau la page monsite.com/page1.php?action=abcd&&var=x, même si les deux pages contiennent exactement le même code html. En résumer, c'est le nom complet de la page qui est pris comme parametre pour le cache.
Or en lisant brouillard il a utilisé ce lien pour tester cette vulnérabilité :
[Lien supprimé]
Et je ne pense pas que ce lien soit le même que celui qui s'affiche qu'on on est dans la page d'admin de la boutique.
Je vous laisse vérifier, sinon je le ferai de mon côté car pour l'instant je me renseigne avant d'installer et testester Oscom.
Je veux dire par là que ceci n'est qu'une supposition que je vais vérifier d'ici quelque minutes (après l'installation) ou que vous pourrez vous vérifier de votre côté.

Et si cette adresse est celle utilisée dans l'admin, je serrai d'accord que c'est le cache qui avait répondu mais dans le cas contraire, qu'est ce qui s'est passé ... ???

Citation (Bonbec @ 29 Mar 2010, 15:36) *
Pour ma gouverne personnelle, quelle est la réputation du couple .htaccess et .htpassword ?

Sans hésiter, je suis sûre à 99,99% que tu trouvera la recommandation d'utiliser ce couple dans plus de 70% des sites qui parlent de comment sécuriser son site web, en commençant par la FAQ d'oscommerce, ici même.

En même temps, je reconnais que ce couple n'est pas la garantie d'une sécurité à 100% mais elle rendra la vie des hacqueurs encore plus difficile.
De plus, je pense que les mots de passe sont et les données sont envoyé en claire à travers le reseau d'ou la néccéssité de le compléter par du une solution de criptage de donnés (come SSL) pour avoir du httpS dans le navigateur (cryptage du mot de passe et des données entre le client et le serveur).


Je reste receptif et à l'écoute donc n'hésitez surtout pas de me corrigez si j'ai raconté des salades. car on est là avant tout pour apprendre et quand on apprends, les erreurs sont possibles.

juste en passant, quelqu'un peut-il me dire quelle est la derniere mise à jour (patch) qu'il faut prendre pour la MS2.2 RC1 w3c-3 ? Je veux installé Osc mais j'aimerai etre sûre que la version que je vais installer est bien stable et que j'ai bien le dernier patch de sécurité à ce jour.

Je suis désolé mais j'ai du mal me retrouver dans le forum et je préfère être sûre car on ne plaisante pas avec la sécurité.

Merci à tous
Gnidhal
Cher ngmsky :
Non, il n'y a pas de patch complémentaire à la version francophone téléchargeable ici car elle ne présente pas de faille.
Mais rien n'est inviolable, même des banques ou le Pentagone se sont vus visités par des pirates, par simple jeu parfois : quel challenge pour un hacker de dire "j'ai fait x mois de prison à la demande du FBI pour avoir hacké le Pentagone"

Non soyons sérieux : si ton admin est renommée, protégée par .htaccess/.htpasswd les risques de voir ton site hacké sont ridicules.
Toutefois, si le hacker assez malin a placé un script espion dans ton admin auparavant, le piratage reste possible.
Il sera informé de ton mot de passe et du nouveau chemin grâce à son petit script. En bref c'est comme un virus. Solution : effacer le dossier et le recréer ailleurs à partir d'une sauvegarde antérieure à l'intrusion.

Alors on peut délirer tant qu'on veut, hors de ce cas de figure, la protection par htaccess ne peut être cassée que de deux manières :
1/ la force brute : cela consiste à placer script sur un ordinateur qui tentera tous les couples log/mot de passe possibles
2/ l'espionnage préalable : cela consiste à connaitre la cible, ses habitudes et/ou avoir accès à son ordinateur pour utiliser du premier coup le bon log d'accès.
2bis/ l'espionnage des connexion vers le site (oui, s'il n'y a pas de certificat ssl sur l'admin, le log et le mot de passe sont envoyés en clair via le net)
Je mets 2bis car cette option se rapproche de la précédente et il est possible de l'éliminer en plaçant ton admin dans une zone SSL

Sinon c'est de la magie noire.

Pour le premier cas, il est possible de bloquer une attaque de ce type avec un nombre limité d'essai. Google te donnera les réponses pour cette procédure.
Pour le second, il suffit d'être prudent. Exemple: il ne sert à rien de fermer la porte à clé si tu glisses la clé sous le paillasson ou sous le pot de fleur à coté.

Don pas la peine de se prendre la tête, une sécurité d'accès ça se gère dès le début et il ne sert à rien de chercher un responsable en dehors de celui qui a mis en place le site. Que ce soit dans la FAQ ou pas, il faut protéger son administration.

Maintenant je commence à trouver que la redondance des question et des réponses dans ce post tourne au troll (comme d'habitude sur ce genre de sujet)
Alors continue à reposer les même questions et ce post ne sera pas fermé, mais sera nettoyé : j'ai le chiffon et la bouteille de javel!
NoZic
Bonjour,

Le .htaccess a ses limites, les get post (limit get post smile.gif ).

Effectivement le .htaccess est cassable si il n'est pas maintenu correctement.
Ca fait un bail que Julietta a remonté l'info ici : Créer un .htaccess et un .htpasswd (à lire le lien super intéressant remonté par Juju : http://www.segmentationfault.fr/securite-i...limit-get-post/ - tiens c'est marrant, il y a les mêmes en-têtes de requètes en HTTP/1.1... biggrin.gif )

L'info a même intégré la FaQ : Comment finaliser l'installation, régler les chmods et sécuriser OsCommerce?

Maintenant, si on fait les choses correctement, il n'y a pas de raison. Mon admin n'est pas accessible. Et tu peux essayer de la casser avec des méthodes si "légères", ça passera pas.
Et je n'ai pas passé la correction proposée. Mais sur mon site, ça ne fonctionne pas de base, sans la correction. Le htaccess fait son taff.

Maintenant je ne testerais pas avec le limit get post dans le .htaccess... à mon avis ça passe...

Bah oui faut se mettre à la page de la sécurité de ses outils. Ce que n'a pas du faire brouillard. Son .htaccess doit toujours avoir les limit get post. C'est pour ça que ça passe chez lui.

Bonne journée

[EDIT] Oo ouuups... j'ai confuse... désolé, le lien super intéressant est remonté par Illeriane, rendons à César... ninja.gif
Bonbec
Bonjour,
Merci NoZic pour la piqûre de rappel. Mes .htaccess sur mes différents sites ne contiennent pas les <limit></limit> (mais je ne me souvenais plus de cette faille potentielle rolleyes.gif
Gnidhal

Donc un simple :
Code
AuthName "Zone Protégée "
AuthType Basic
AuthUserFile /.htpasswd
require valid-user
est blindé contre toute entrée sans mot de passe.
pelforth
Simple question : A quoi sert "?action=save HTTP/1.1"

Même sans le rajouté à la fin de "file_manager.php/login.php" cela marche quand même, donc à quoi sert cette variable précisement??
NoZic
Bonjour,

Il faut lire l'article (re)cité.

Ce n'est pas une utilisation normale de la barre d'adresse ni du tableau des get d'ailleurs.
En fait, cela fait partie d'une entête du protocole http (port 80). Tu ne le vois pas mais avant de s'envoyer des trames de données, le serveur et le client (ton pc) font les présentations, parlent du beau temps et discutent un peu. Puis ils s'envoyent les trames et comme ils sont polis, ils se disent au revoir.

En passant ça par la barre d'adresse tu similes un début de présentation de ton pc en gros.
Donc tu contournes le fait de passer par un get ou un post pour discuter avec le serveur.
Donc si il subsiste les limit get post dans ton .htaccess, bah ça passe car ce n'est pas soumis à la limitation des get et post...
Malin ce hack, tout de même... se baser sur une erreur commune d'utilisation des .htaccess. Et quand je dis commune, c'est commune.
Les miens étaient comme ça et je les avaient fait avec un tuto d'un site relatif à la sécurité web...

Mais la documentation d'apache précise qu'il ne faut pas faire ce genre de limitation, donc encore une fois, il fallait lire la doc...
Comme toujours...
RTFM
smile.gif
Madmaxx
Citation (Gnidhal @ 30 Mar 2010, 07:56) *
Donc un simple :
Code
AuthName "Zone Protégée "
AuthType Basic
AuthUserFile /.htpasswd
require valid-user
est blindé contre toute entrée sans mot de passe.

heu pas tout a fait
en faite en terme de sécurité informatique ou de piratage (au choix) le fait de laissé le .htpassword dans le eme rep et une faillle

on peut atteindre le .htpassword et ensuite casser le cryptage soit en local avec une machine dédié a cela
soit il ya des site qui te permette de le faire

alors 2 sécurités de plus:

la premiere consiste a ne pas nommé ton fichier en ".htpassword" mais en ".foutlecamps " par exemple
nom que tu repercute dans ton .htaccess
et la deuxieme secu consite a le placé ailleurs
Code
AuthUserFile /mon/chemin/sur/mon/server/htdocs/mon rep (admin ou autre)/encore un rep/.foutlecamps
AuthName "Authentification requise"
AuthType Basic
require valid-user

on est sur le meme code mais avec un petit plus

et pour finir
le tout chmod en 400 ou 440 ou 444
bref aucune ecriture possible dessus
sachant qu'en 400 seul le owner peut lire le fichier (soit le server et toi par ton client ftp)
mais pour le modifier faut le remettre en 600, 640 ou encore 644
dernier point tres important qui est une faille connu depuis la nuit des temps
ne pas laissé d'espace inutile dans ce genre de fichier

dans le rep password par exemple pas de retour chariot a la fin de la ligne on laisse le curseur sur le dernier caractere ecrit
et ceci est valable dans le .htaccess aussi

entre cela et le fait de renommer son admin oui c'est blindé
cela est encore mieux si on heberge l'admin sur un autre server ou un sous domaine ( qui est dans un rep different) la ca devient quasi impossible de retrouver le path

@+
brouillard
Citation (NoZic @ 30 Mar 2010, 06:38) *
Bonjour,

....... Bah oui faut se mettre à la page de la sécurité de ses outils. Ce que n'a pas du faire brouillard. Son .htaccess doit toujours avoir les limit get post. C'est pour ça que ça passe chez lui.

Bonne journée

[EDIT] Oo ouuups... j'ai confuse... désolé, le lien super intéressant est remonté par Illeriane, rendons à César... ninja.gif



Bonjour, @NoZic, je suppose que c'est de moi qu'il s'agit, et bien sache que cette faille je la connais, et que mon .htaccess n'a ni limit post ou ni get. Alors s'il te plait, n'insulte pas mon intelligence, je suis passé pour aider et non pour me faire insulter.
ps : voici un lien pour mieux comprendre cette faille
faille htaccess get post
brouillard

Lis le 5em post pour la mise à jour de cette faille.
ma boutique c'est la dernière version de osc

Sur l'un des posts avant le 5em j'ai mis un lien vers la source originale (en anglais).

S'il n'y avait pas de faille, pourquoi sur le forum osc anglais on met cette correction ?!!

1) Pour le fun !
2) Cela les amusent des trouver des non-failles de non-sécurité ?!!!
3) Pour faire C... le monde !!!
4) Ils sont pointilleux sur la sécurité, et il existe vraiment une faille de sécurité dans la dernière version d'osc
chrislabricole
Bonsoir,

La solution de brouillard (à la première page) fonctionne sur ma boutique.
Mais la meilleure solution reste de renommer son répertoire admin, ainsi que d'y placer un .htaccess...

J'ai trouvé le code de l'exploit ici :
www.milw0rm.com/exploits/9556
Je l'ai testé avant la correction de brouillard : vulnérable
Après : Pas vulnérable

Version : 2.2 RC2a

Merci wink.gif
brouillard

Merci chrislabricole pour ton soutien, moi j'ai adopté les 2 solutions pour ma boutique.
NoZic
Bonjour,

Bah brouillard, tu t'enflammes tout seul... je n'insulte pas ton intelligence (quelle parano dis donc... blink.gif relis un peu mon post...).

Je faisais juste remarquer pour compléter la réponse de Gnidhal que les .htaccess ne sont pas sans faille.
La FaQ ayant été corrigée il n'y a pas si longtemps, tout ceux qui l'ont suivi il y a longtemps n'ont pas fait la MaJ du .htaccess (car ce n'est pas marqué explicitement que le .htacces a changé, il y a juste le correct, pas l'ancien et la comparaison des deux, ni l'explication du pourquoi).
Je remontais l'info, quoi, pour les retardataires. Donc comme toi, ça part d'un bon sentiment...

Par contre, il est certain qu'avec un .htaccess sans limite sur les post et get (et une demande de mot de passe évidemment), cette "faille" (qui n'en est plus une du coup) ne passe pas. C'est testé.
Donc c'est plus :
5) ce n'est pas une faille si on a la version d'osc d'ici et qu'on a appliqué toutes les FaQ d'ici à la lettre
smile.gif

D'ailleurs, c'est sympa de relinker le lien de mon premier post, celui qui explique pourquoi, cool. wink.gif
Merci d'appuyer mes dires à ce point. happy.gif

Et merci pour la remontée, que j'ai appliquée à mon site aussi, au fait.

[EDIT d'auto-censure pour réenflammage du post, je vannais mais vu la susceptibilité de brouillard, je préfère enlever mes conneries... dry.gif ]
[EDIT2] tant qu'on est dans les politeses, merci Juju et Illeriane pour les corrections de la FaQ et le link très très intéressant, tellement que brouillard l'a remis, des fois que... biggrin.gif
brouillard
Il y en a qui ont du temps à perdre!

À bon entendeur, salut !
Gnidhal
Citation (brouillard @ 14 Apr 2010, 09:35) *
Il y en a qui ont du temps à perdre! À bon entendeur, salut !
Y aurait-il un peu énervement ?
Bon reprenons, Forgiven dit que son site a été piraté, et il cherche à savoir comment
Brouillard répond qu'il existe une faille dans le système de login de l'admin elle est connue, source le forum international anglophone osCommerce.

Alors oui, cette possibilité de passer outre la protection par session existe bien. D'ailleurs une protection par session est très insuffisante sur un dossier d'administration qui de plus n'a pas été renommé. C'est la voie royale pour les hackers.

Répondu dès le début que nous préconisons ici sur le forum francophone une protection par .htaccess/.htpasswd sur un dossier admin renommé.

Si ce conseil est appliqué, il ne peut plus y avoir de faille de sécurité et le hack cité par brouillard est sans objet, il buttera sur la protection Apache.

Le "kit osCommerce" n'est pas en l'état un outil de commerce en ligne directement exploitable sans quelques légères modifications. Mais il est vrai que les utilisateurs sont tellement habitués à ce que tout soit pré-maché voire pré-digéré que quand le système ne fonctionne pas en "plug & play" on crie au scandale.
Chacun est responsable de sa sécurité et ne pas intégrer dans le pack livré plus de sécurité que le minimum de base est un moyen aussi d'obliger l'utilisateur à se soucier de la sécurité de son site plutôt que de faire une confiance aveugle aux systèmes tout-faits.

Quant à l'expression "à bon entendeur, salut!" elle signifie en effet "qui comprend bien est protégé des conséquences" ce qui au delà de la sémantique est aussi une menace de représailles pour qui ne tiendrait pas compte de l'avertissement. Attention aux dérapages smile.gif
NoZic
Bonjour,
Salut Gnidhal,

Perso, j'entend bien :
Citation
Et merci pour la remontée, que j'ai appliquée à mon site aussi, au fait.
Mais pourquoi tant d'énervement sur un post intéressant en plus ?

Commande une petite tisane à Syka, ça va te détendre.
biggrin.gif
demoalt
Voici mon fix

Dans application_top.php

trouvez la ligne dans:

Code
$PHP_SELF = (isset($HTTP_SERVER_VARS['PHP_SELF']) ? $HTTP_SERVER_VARS['PHP_SELF'] : $HTTP_SERVER_VARS['SCRIPT_NAME']);


la commentez et remplacez par:

Code
$PHP_SELF = basename($_SERVER['SCRIPT_FILENAME']);


puis testez. ce fix peut ne pas fonctionner sur certains serveurs dont cette variable auraient été désactivés.


Citation (Bonbec @ 26 Feb 2010, 15:24) *
Citation (brouillard @ 26 Feb 2010, 15:59) *
-http://www.taboutique.fr/admin/file_manager.php/login.php?action=save HTTP/1.1
j'ai testé sur ma boutique et ça marche, et pas qu'avec file_manager.php, avec tout le reste, on peut même envoyer des mails de ta boutique.

Cela veut dire que ton dossier admin n'est pas protégé par un htaccess angry.gif ...

Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2024 Invision Power Services, Inc.