Trois signes d'une attaque d'application que les développeurs doivent connaître
Les applications sont assiégées. Les attaques se produisent à une fréquence alarmante – toutes les 39 secondes selon une étude menée par l’Université du Maryland – avec une probabilité de réussite inquiétante.
Les développeurs, qui assument de plus en plus la responsabilité de sécuriser ces applications, sont bien conscients de la menace. Une enquête menée fin 2017 auprès des développeurs Node.js par NodeSource et Sqreen a révélé que « plus d’un tiers des personnes interrogées (34 %) estiment qu’il existe une forte probabilité que leur organisation soit la cible d’une attaque à grande échelle au cours des six prochains mois ». Compte tenu de nos propres conclusions selon lesquelles le vecteur d’attaque initial dans 86 % des attaques est soit l’application elle-même, soit les identités, cette croyance est plus que raisonnable.
Il peut être dérangeant de découvrir alors que « 35 % des personnes interrogées ne savent pas comment identifier une attaque au moment où elle se produit ». Ils s'attendent à une telle catastrophe, mais ne savent pas comment la reconnaître lorsqu'elle survient. Si vous ne savez pas comment identifier une attaque en cours, il est extrêmement difficile de l’arrêter.
Cela rend les 23 % de développeurs Node.js (23 %) qui n'utilisent aucune forme de protection en temps réel contre les attaques encore plus inquiétants.
La bonne nouvelle est que, d'après nos propres recherches sur l' état de la distribution des applications, 2018, la plupart des organisations utilisent une sorte de protection en temps réel contre les attaques. Quatre sur cinq utilisent deux technologies ou plus, notamment le pare-feu d'application Web (57 %), l'autoprotection des applications d'exécution (11 %) et l'analyse du comportement des utilisateurs (26 %).
La caractéristique commune à toutes ces technologies est ce qui manque souvent aux développeurs : la visibilité. La visibilité est nécessaire car pour détecter (et, espérons-le, identifier) une attaque, vous devez être capable de reconnaître un comportement anormal.
Les applications et leurs services ont des modèles d’utilisation assez prévisibles. Par exemple, les applications d’authentification unique (SSO) ont tendance à être très utilisées le lundi matin et peu utilisées le vendredi après-midi. Les applications financières ont tendance à être très utilisées juste avant les événements financiers : jours de paie, fins de période fiscale et clôtures d’exercice.
Même les applications destinées aux consommateurs ont des modèles d’utilisation prévisibles qui peuvent être utilisés pour aider à détecter un comportement inhabituel (et potentiellement dangereux). Par exemple, en avril 2017 , Malauzai Software a publié l'un de ses rapports mensuels « petites données » basé sur les données d'utilisation collectées auprès de plus de « 435 banques et coopératives de crédit, couvrant 13,2 millions de connexions de 730 000 utilisateurs actifs d'Internet et de services bancaires mobiles ». On y apprend que « 100 % des utilisateurs finaux voient leur solde et examinent l’historique des transactions récentes. C'est parce que les soldes et l'historique récent s'affichent sur la page de destination pour que tout le monde puisse les voir. Et c'est pour ça qu'ils viennent. 77% du temps. 77 % du temps, tout ce que fait un utilisateur est de vérifier les soldes et l'historique. Seulement 23 % des interactions globales dans le secteur bancaire numérique vont au-delà des soldes et de l’historique pour effectuer une autre tâche.
On pourrait alors en déduire qu’un intérêt soudain pour d’autres types de transactions pourrait être le signe d’une attaque.
Malheureusement, ces statistiques ne sont pas toujours facilement disponibles pour chaque application. C’est pourquoi la visibilité (surveillance) est importante, afin de pouvoir établir une base de référence par rapport à laquelle les anomalies deviennent évidentes. Bien entendu, toutes les anomalies ne sont pas le signe d’une attaque. Un pic d'utilisation du service SSO en milieu de semaine peut être dû à une date limite pour modifier les mots de passe d'entreprise, ou parce que lundi et mardi étaient des jours fériés et que personne n'était au bureau. Néanmoins, disposer d’une base de référence vous donne une longueur d’avance pour identifier le comportement qui peut vous indiquer qu’une attaque est en cours.
Assurez-vous de vérifier ces trois modèles d’utilisation anormaux au cas où ils constitueraient en fait une attaque. Parce que c’est souvent le cas.
1. Augmentation spectaculaire des connexions. Peut-être que vous venez de devenir viral, mais il y a de fortes chances qu’il se passe autre chose. Lorsque vous constatez une augmentation significative des taux de connexion, il est judicieux de vérifier immédiatement s’il y a une augmentation correspondante du trafic réseau. Sinon, vos sens d’araignée devraient être en éveil car il s’agit d’une attaque potentielle. Les attaques GET Floods sont les plus faciles à perpétrer de toutes les attaques DDoS basées sur HTTP, car elles reposent simplement sur la pulvérisation d'une tonne de HTTP GET sur une application et rien d'autre. Souvent, ils n’essaient même pas d’accéder à de véritables URL, car le but est simplement de consommer autant de connexions que possible et de vous forcer à une situation de surcharge.
Si l'augmentation cible spécifiquement les URL ou les services qui fournissent des connexions, vous pourriez être victime d'une attaque par force brute pour obtenir l'accès.
Recherchez des erreurs de serveur, des performances de plus en plus dégradées et un épuisement des ressources comme signes d’une attaque en cours.
2. Taille de la réponse sortante. Une réponse sortante soudainement importante peut indiquer une attaque d’exfiltration réussie dans laquelle l’attaquant a obtenu l’accès à des données auxquelles il n’aurait pas dû avoir accès. Il s’agit de l’un des principaux signaux d’alarme d’une attaque SQLi réussie, car les attaquants utilisent souvent des caractères génériques pour obtenir un accès non autorisé aux données. On pourrait penser que SQLi est un vecteur d’attaque tellement bien compris que nous aurions désormais couvert ce sujet. Mais SQLi figure régulièrement parmi les attaques les plus réussies chaque année dans un certain nombre de rapports sectoriels.
Fondamentalement, l’attaque est conçue pour contourner les restrictions d’accès aux données. Ainsi, au lieu de recevoir un seul enregistrement (ou même seulement quelques-uns), l'attaque pourrait en recevoir des milliers . Une attaque réussie sera alors perceptible car la quantité de données renvoyées sera considérablement plus importante que la norme.
Toute différence significative dans la taille de la réponse devrait être suffisante pour justifier une enquête immédiate.
3. Crashes et échecs. Bien que ces erreurs puissent s'expliquer par des défauts ou des entrées « erronées » par accident, elles peuvent également indiquer des tentatives de dépassement des tampons dans des bibliothèques tierces ou des plates-formes de serveurs Web (ou votre application) dans l'espoir d'exploiter une nouvelle (ou ancienne) vulnérabilité. Même s’il est agréable que les systèmes puissent simplement « redémarrer » d’eux-mêmes aujourd’hui, il n’est pas agréable d’ignorer la raison pour laquelle ils ont eu besoin d’être redémarrés .
Même s’il peut être tentant d’ignorer un accident occasionnel, ne le faites pas.
N’ignorez pas les pannes et les pannes et envisagez des architectures qui vous permettent de mettre en quarantaine les systèmes défectueux jusqu’à ce que vous puissiez les examiner.
Il ne s’agit évidemment pas d’une liste exhaustive, mais c’est un bon début pour pouvoir identifier quand une application est susceptible d’être attaquée – et l’arrêter dans son élan.
Soyez prudent!