Comment retracer une intrusion dans un panneau d'administration ?
Lorsqu'on voit du texte d'une autre langue humaine ou du JavaScript insérer dans un article, on comprendra bien que ce n'est pas apparu par magie. Et naturellement, les journalistes entrant le contenu n'ont rien à voir là-dedans. De plus, vous retrouvez des traces dans des milliers d'articles. Sachant cela, on sait pertinemment qu'il y a quand même forcément soit un système automatique ou un être humain ayant rentré l'information.
Par où commencer ?
S'il s'agit d'un site Web, la première place à vérifier c'est le fichier d'accès de journal de bord (access_log en Apache,...). Il faut aller visualiser toutes les requêtes URL bizarres. Utiliser par exemple une commande grep de Linux pour trouver la chaîne de caractères suspects retrouver dans vos articles. Ensuite, si vous ne voyez rien, il peut avoir exploité des paramètres légitimes dans l'URL et les avoir remplacer par quelque chose d'inusité, rechercher par un mot comme "SELECT" avec grep, il a peut-être réussi à s'infiltrer en utilisant un technique d'Injection SQL. Que vous pouvez détecter avec la requête semblable suivante :
| grep "SELECT" -i access_log |
Des pistes possibles
Si vos serveurs tombent brusquement à certains moments dans la journée ou que vous avez des pics inexpliqués de trafic à certains moments, vous devriez surveiller à ce moment qu'est-ce qu'il se passe (au niveau de l'utilisation des ressources et du journal de bord). Il cherche peut-être à faire tomber votre site pour déterminer le type de serveur pour enfin cibler une intrusion ciblée en fonction des informations retournées. Les serveurs sont souvent trop loquasse et devienne par le fait même vulnérable. Si vous offrez la possibilité d'utiliser une API comme celle de WordPress (XML-RPC) de l'extérieur de votre Site Web passé à soit la désactiver ou soit restreindre l'intervalle d'IP autorisé au serveur ou au poste de travail légitime.
Les situations plus compliquées
Lorsqu'un brillant administrateur système a l'idée géniale de désactiver le journal de bord (les log) pour économiser de l'argent sur l'hébergement. Aussi bien le dire, il a économisé jusqu'à mais maintenant ça va coûté beaucoup plus cher que ce qu'il a économisé. Ainsi, si le journal de bord est désactivé, vous êtes cuit ! Là vous allez devoir carrément deviner ce qui c'est passé, c'est à dire, supposer que vous avez des versions obsolètes et qu'il faut la mettre à jour votre site Web. Utiliser un logiciel de test de faille de sécurité sur votre site pour détecter les brèches et supposer qu'il est rentré par là.
Le pourquoi ils font cela ?
À l'origine, il cherchait a promouvoir le côté reproducteur de l'humain, mais maintenant, ils sont sournois et l'utilisant par exemple pour fabriquer des Blockchains et des mineurs. Dans le premier cas, il s'agit d'une attaque nous sollicités, tandis que la deuxième, il s'agit d'un attaque par ralentissement de serveur et ralentissement du navigateur Web.
Remarques
- Limitation du journal de bord : Les access_log enregistrent toutes les requêtes d'URL utilisant des méthodes GET mais les valeurs des méthodes POST, par le fait même, vous pourriez ne voir passer les données d'une attaque s'il utilise la méthode POST.
- Mise à jour : Avoir la dernière mise à jour de sécurité n'empêche pas une intrusion, elle empêche seulement le dernier type d'attaque connu et documenté par des spécialistes.
- Interprétation vs cloner : Une des plus grandes menaces découle du fait que la plupart des systèmes informatiques actuels son basé sur des chaînes de caractères du langage de programmation C, lequel malheureusement à un problème fondamentale, il interprète le contenu de cette chaîne de caractères. Par exemple, la chaîne de caractères du C utilise un caractère ASCII 0 pour indiquer la fin de la chaîne de caractères. De plus, des fonctions comme printf effectue un formatage par-dessus cette première interprétation et ainsi de suite jusqu'à atteindre les niveaux des plus des langages de programmation comme PHP, Perl, AWK avec des caractères d'échappement par exemple. Dans des langages de programmation comme le Pascal, un octet ou 2 octets ou 4 octets sont réservés pour indiquer la longueur de la chaîne de caractères, il n'y a donc aucune transformation, donc, une personne malveillante ne peut pas exploiter cette lacune. De façon concrète, un code malveillant peut se cacher après un code ASCII 0 car il est perçu comme un contenu étant situé après la fin de la chaîne de caractères et passera inaperçu avec une fonction strlen par exemple. Ainsi, le prix des transformations du C rendra le code plus court que le Pascal, mais augmente le risque de faille de sécurité pour les développeurs.