Comment traiter les vulnérabilités à faible niveau de risque ? Petits problèmes, gros problèmes…
Disclaimer : Cette histoire est une fiction, toute ressemblance avec des personnes et des réseaux réels, vivants ou morts, n’est que pure coïncidence…. ou pas.
Attendez ! Votre responsable informatique s’appelle-t-il Jean ? 😉
La chronologie de l’histoire
Novembre 2016
Votre entreprise se développe, vous n’êtes plus une start-up et vous avez de nouveaux besoins et de nouvelles exigences. Avec Jean, votre responsable informatique, vous avez décidé d’installer un nouveau serveur dans le nuage afin d’améliorer la communication de l’entreprise avec vos consultants.
Le projet est assez simple: Mettre à la disposition de vos consultants des données non sensibles déjà présentes sur votre intranet.
Jean est très préoccupé par la sécurité. Il sait que l’application intranet a été développée il y a longtemps et il refuse d’exposer le serveur au grand méchant Internet.
Actions :
- Il décide donc de placer le serveur intranet dans une DMZ, et de limiter l’accès à cette DMZ à un seul serveur sur lequel est installé un CMS (connu pour être sécurisé).
- En outre, pour s’assurer que cette nouvelle marque d' »ouverture » ne met pas votre entreprise en danger, Jean prévoit un pentest par une société de sécurité bien connue (Approach ?).
Résultats : Le résultat du test de pénétration est vraiment bon et ne signale qu’une seule vulnérabilité (non, ce n’est pas Approach ! à vous de choisir…) :
Le niveau de risque étant » faible « , vous n’accordez pas trop d’importance au rapport et votre responsable informatique poursuit ses activités quotidiennes …
15 décembre 2018 – nouveau besoin …
La fin de l’année approche et vous souhaitez organiser une journée de travail pour réunir vos consultants.
Vous avez besoin d’une sorte de gribouillis sur le CMS pour récolter les disponibilités de votre équipe pour l’événement, mais le responsable informatique est surbooké et délègue la tâche de développement à son stagiaire.
20 décembre 2018 – impact ….
Vous recevez un appel téléphonique de l’autorité chargée de la protection des données : le dumping complet de votre base de données intranet a été trouvé sur le darknet. Y compris des informations sensibles sur les clients et les contrats.
Que s’est-il passé ?
Votre stagiaire a fait une petite erreur en codant la requête de base de données dans le plugin et a introduit une vulnérabilité d’injection SQL.
Un pirate pouvait l’exploiter en utilisant la requête SQL » SELECT INTO OUTFILE « . Il a ainsi pu exécuter du code PHP et des commandes système.
- Pour ce faire, il a injecté un code SQL similaire :
- Ensuite, il peut exécuter des commandes système à partir de son navigateur :
Vous pensez probablement que c’est la faute de l’étudiant. Après tout, c’est lui qui a introduit l’injection SQL !
En fait, c’est un peu plus complexe : pour transformer l’injection SQL en une injection de code à distance, l’attaquant devait connaître le chemin d’accès complet au répertoire web… et vous lui avez donné cette information !
Vous souvenez-vous de cette question de « bas » niveau dans le rapport ?
Tout ce que le pirate avait à faire, une fois le serveur web possédé, était d’attaquer votre ancien et très vulnérable serveur intranet et de vider sa base de données.
Et l’histoire se termine, du moins c’est ce que vous aimez penser :
Vous étiez une petite start-up il y a seulement deux ans, le temps passe et vous n’avez pas pris le temps de mettre en place un bon système de suivi.
Vous ne saurez donc probablement jamais ce qui est arrivé à votre réseau interne, mais …
La morale de l’histoire est la suivante :
En matière de sécurité, rien ne doit être laissé de côté. Cette attaque aurait pu être atténuée de nombreuses façons, depuis le renforcement des serveurs jusqu’à l’installation et la maintenance de pare-feu d’application web.
Approach offre tous les services dont vous pourriez avoir besoin pour sécuriser votre infrastructure :
