La sécurité des objets connectés est un sujet d’actualité, cependant les tests d’intrusion IoT sont encore loin d’être une pratique généralisée. La plupart des constructeurs priorisent d’abord les fonctionnalités et le design du produit. Cependant, même avec une approche « security by design », le test d’intrusion reste incontournable pour connaître les risques de sécurité réels, puis pour prendre les mesures nécessaires.
Nous conduisons régulièrement des pentests d’ingénierie sociale pour nos clients. Nos pentesters (experts en cybersécurité) ont testé différentes techniques, différents scénarios et prétextes.
Nous avons tiré des leçons de notre expérience, et nos clients nous ont fait part ce qu’ils ont appris également ; ce que nous vous partageons ci-dessous.
L’un et l’autre sont considérés comme les meilleurs alliés des RSSI (et en général des personnes en charge de la sécurité). Ils sont toutefois deux outils différents dans une stratégie de sécurité. Quelles sont les différentes caractéristiques d’un pentest (test d’intrusion) et d’un scanner de vulnérabilités ?
C’est une question que nous entendons souvent. Malheureusement, nous n’avons pas de formule ROI toute faite à vous révéler. Le retour sur investissement d’un test d’intrusion est complexe à évaluer. Cependant, nous vous donnons 4 clés pour démontrer l’intérêt financier d’un pentest. La sécurité ne sert pas seulement à éviter d’éventuels problèmes, elle crée surtout de la valeur pour faciliter les ventes et renforcer la confiance de vos clients.
Qu’est-ce qu’une attaque Cross Site Request Forgery ?
L’attaque CSRF (ou en français falsification de requête intersite) est une attaque qui oblige un utilisateur final à exécuter des actions non désirées et sans qu’il s’en rende compte sur une application web dans laquelle il est actuellement authentifié.
Les attaques CSRF visent spécifiquement les demandes de modification et non le vol de données, car l’attaquant n’a aucun moyen de voir la réponse à la demande falsifiée. Le résultat des actions est ce qui intéresse l’attaquant.
Ce type d’attaque s’appuie sur le fait que lorsqu’un utilisateur est authentifié sur une application, celle-ci lui fournit la plupart du temps un identifiant de session, stocké dans un cookie sur son navigateur.
A chaque fois que l’utilisateur envoie une requête vers le serveur, le navigateur envoie également automatiquement ce cookie de session. Vous trouverez dans l’article lié plus d’informations à propos des attaques CSRF.
Notez bien qu’il suffit que l’utilisateur soit resté connecté (sans avoir une page ou un onglet du site ouvert) pour qu’une attaque CSRF fonctionne.
Interface d’administration, back-office, tableau de bord (dashboard), panneau administrateur… plusieurs noms pour la même chose : l’endroit où les organisations gèrent leurs données, supervisent leur activité sur une plateforme web, répondent aux demandes de leurs clients, activent les comptes utilisateurs, configurent des articles pour une plateforme e-commerce…
Lorsque l’on pense à la sécurité des plateformes web, le back-office n’est pas forcément la priorité, pour plusieurs raisons. L’accès à ce type d’application est normalement restreint, aux services internes de l’organisation, et parfois à des tiers, supposés de confiance.
Nous pensons souvent qu’un pare-feu suffisamment restrictif protège l’accès aux services non ouverts. Nous croyons aussi que seule une machine compromise peut donner accès au reste du réseau interne.
Et bien nous avons tort, et c’est ce que nous allons voir avec une vulnérabilité des applications web : le Server-Side Request Forgery (SSRF).
Qu’est-ce que les SSRF ?
A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts.
La sécurité, c’est primordial, et vous êtes d’accord avec ça. D’ailleurs, vous voulez faire un test d’intrusion (ou pentest) sur votre solution d’ici peu… Voici 7 questions pour vous aider à obtenir le meilleur d’un test d’intrusion.
1 – Faut-il réaliser le test d’intrusion sur l’environnement de production ?
Réaliser un test d’intrusion sur l’environnement de production a un avantage certain : l’audit est effectué dans les conditions réelles d’utilisation de votre site web, application web, API… avec les dernières évolutions mises en place.
« Tout le succès d’une opération réside dans sa préparation », Sun Tzu. Déjà vraie au VIe siècle av J-C, cette maxime l’est toujours au XXIe siècle. Et les pirates informatiques l’ont bien intégrée à leur stratégie.
Avant de lancer leur attaque, ils vont ainsi répertorier toutes les informations disponibles sur internet concernant leur cible. En effet, la transformation numérique apporte des avantages à une organisation, mais elle rend également de nombreuses informations visibles depuis l’extérieur à qui sait où chercher, ou même simplement regarder. Ces informations aident ensuite les personnes mal intentionnées à adapter leurs attaques à la cible.
Heureusement, cette situation n’est pas une fatalité. Chaque entreprise peut cartographier son empreinte numérique, pour ensuite contrôler et limiter les informations visibles. C’est ce à quoi consiste un audit de reconnaissance.
Mis à jour 1. Déc 2020
Plus de 2 ans après l’entrée en vigueur du RGPD (le 25 mai 2018), des sanctions ont été prononcées par plusieurs organismes de protections des données. Ces sanctions ont des répercussions importantes, économiques mais surtout pour l’image des entreprises concernées, car elles sont communiquées publiquement.
Si les grands principes du RGPD sont généralement connus, les mesures techniques principales à mettre en place pour sécuriser un site ou un système d’information restent encore parfois floues. Pour y remédier, nous détaillons dans cet article tous les aspects de sécurité technique du RGPD.
A la suite d’un audit de sécurité, des vulnérabilités vous ont été signalées. Faille critique, importante, moyenne : savez-vous comment cela est établi ? Nous vous détaillons notre méthodologie, basée sur celle de OWASP*, pour estimer la sévérité des risques d’une vulnérabilité.
Le phishing a beaucoup évolué. Alors que l’email frauduleux était auparavant facilement repéré par ses nombreuses fautes d’orthographe et par les demandes ou menaces exagérées (versement immédiat d’argent, compte intégralement effacé, etc.), il reprend aujourd’hui les codes d’organismes de confiance. De plus, le phishing implique désormais des demandes personnalisées ou des interlocuteurs connus de la personne attaquée (responsables hiérarchiques par exemple), ce qui le rend plus difficile à détecter.
Le phishing consiste à interagir avec des emails piégés. Il s’agit de la méthode la plus couramment utilisée pour l’ingénierie sociale, une branche de la cyber-criminalité.
L’ingénierie sociale cible le comportement humain. Elle a pour but d’amener un utilisateur à dévoiler des informations confidentielles et à réaliser des actions néfastes pour soi-même ou pour un organisme auquel il appartient. Vous pouvez sensibiliser vos équipes à ce risque en réalisant un audit d’ingénierie sociale.
Nous verrons dans cet article comment déjouer les différents stratagèmes du phishing, qui peuvent échapper même aux utilisateurs avertis et vigilants.
Durant nos audits il nous arrive encore très souvent de rencontrer des énumérations utilisateurs qui pourraient avec les bonnes méthodes être facilement évitées. Dans cet article, nous traiterons des énumérations d’utilisateurs sur les formulaires de connexion, de réinitialisation de mot de passe et de création de compte. Cependant, les énumérations utilisateur peuvent se trouver sur d’autres fonctionnalités, telles que, par exemple, des formulaires de recherches ou des envois de messages.