Les attaques visant la sécurité applicative (injections SQL, XSS, etc.) sont de plus en plus médiatisées et de nombreuses personnes y sont grandement sensibilisées. D’une part,  les outils de programmation sont aujourd’hui très performants pour détecter les potentielles vulnérabilités dans le code et ces pratiques de développement évoluent avec l’adoption d’un cycle de vie de développement logiciel sécurisé (SDLC) mis en place en amont. D’autre part, des outils d’évaluation et de détection de vulnérabilités sont proposés aux équipes d’exploitation (scanners automatiques), ainsi que des outils pour déceler et bloquer des attaques (WAF, IDS, etc.).

Il existe des attaques de logique métier permettent de détourner les fonctionnalités métiers d’une application au profit d’ attaquants. Généralement ils préféreront des cibles applicatives qui exigent moins de compréhension de la technologie sous-jacente (Framework, code, etc.), pouvant ainsi toucher plus de cibles et dont les scénarios d’attaques peuvent  être « amplifiées » par la simulation d’un grand nombre de requêtes malveillantes. Ce type de failles est porteur de plus d’opportunités et de gains pour les attaquants. Les vulnérabilités de logique métier s’inscrivent dans ce type de vecteurs d’attaque. Notons qu’elles ne sont pas nouvelles, mais s’avèrent généralement difficiles à appréhender.

Les attaques de logique métier

La logique métier regroupe les algorithmes fonctionnels (règles métier et workflows) qui gèrent l’échange d’information entre les bases de données et les interfaces utilisateurs d’une application.

Une vulnérabilité de logique métier cible le flux de traitement d’une requête légitime de l’application de manière à ce qu’un risque soit engendré pour la sécurité de l’application.

À titre d’exemple, les vulnérabilités de logique métier pourraient être un abus de fonctionnalité, un blocage insuffisant de l’automatisation, une validation insuffisante de processus, une fuite d’informations ou une élévation de privilèges.

Le tableau suivant résume les différences majeures entre les attaques techniques et les attaques de logique métier :

Vulnérabilités logique métier des applications 3

Comment identifier les failles de logique métier?

À l’inverse des attaques techniques, il n’existe pas d’outils « clic bouton » pour identifier ce type de vulnérabilités, car tout simplement elles sont dissimulées dans le fonctionnement de l’application.  De plus, les vulnérabilités de logique métier n’ont pas une signature ou un « pattern » détectable par des outils de scan de vulnérabilités. Il faut donc procéder à un audit manuel et surtout que l’auditeur analyse au maximum les fonctionnalités de l’application et leur rôle afin d’en détecter les faiblesses.

Pour plus d’efficacité, l’auditeur pourrait, selon le contexte de l’audit,  demander à être assisté par le responsable de l’application lors de l’analyse de fonctionnalités très complexes.
Enfin, l’auditeur devra également :

  • Tester des scénarios, surtout les plus imprévisibles par le workflow,
  • Analyser les requêtes et les flux,
  • Déduire le comportement de l’application à partir des réponses retournées par l’application.

Quels sont les risques ?

Puisque ces attaques ciblent directement le métier, les risques pourraient être pesants sur la sécurité des données métiers ou sur le niveau de service de l’application.

Parmi les risques probants de ces attaques, nous recensons le préjudice financier, la dégradation de la qualité de service (QoS), les impacts sur l’exploitation de l’application (modification de données), la fuite d’informations, le déni de service (DoS), l’atteinte à l’image de marque et à la réputation de l’entreprise.

Exemple basique : abus d’une fonctionnalité

Dans le contexte d’une application qui fournit une fonctionnalité de recherche, un attaquant pourrait altérer la variable qui contrôle le nombre de résultats à retourner (nombreLigne).

La requête ci-dessous  permet une recherche du mot-clé « LEXSI » avec un nombre de résultats altéré par l’attaquant :

Requête HTTP :

Vulnérabilités logique métier des applications 2

Puisque la variable de cette requête HTTP a pour conséquence une requête SQL sur la base de données, le traitement de la requête SQL pourrait engendrer des temps de traitement très longs et consommateurs de ressources.

Soulignons également que la réponse HTTP peut aussi être très volumineuse puisque de nombreux résultats seront retournés (Content-Length: 99999).

Réponse HTTP:

Vulnérabilités logique métier des applications 1

Si en plus nous imaginons que l’attaquant lance la même requête depuis plusieurs clients Web (script d’automatisation, botnets, etc.), le risque du déni de service est très probable.

Exemple historique : DDo$

Nous allons présenter un exemple historique de ces attaques. Il s’agit de la fameuse « Distributed Denial of Dollar Attack (DDo$) » ou l’attaque de déni de dollar distribué. C’est une campagne qui a été proposée par le fondateur du site « The Pirate Bay » en 2009 contre le cabinet d’avocats de ses parties adverses. L’objectif était de profiter d’erreurs dans la conception des fonctionnalités métiers et dans le processus de validation des virements.

Le modèle de l’attaque était le suivant :

  • Les activistes du site « The Pirate Bay» savaient que la banque qui détenait le compte bancaire des avocats n’offrait seulement que 1000 transferts gratuits, ensuite tous les transferts supplémentaires coutaient 2 SEK au cabinet d’avocats (couronne suédoise équivalente à  0,11 euro)
  • Les activistes se sont mobilisés et ont envoyé des micro-dons en masse de 1 SEK au compte bancaire du cabinet. Ainsi ils ont pu effectuer des milliers de virements dépassant largement les 1000 virements gratuits.
  • La banque facturait 2 SEK de frais sur chaque transaction après les 1000 premiers virements, l’impact financier pour le cabinet d’avocats fut conséquent.
  • Il aurait été suggéré aux activistes d’annuler ces virements (cela est possible en droit suédois).

Résultat : Au-delà des premiers 1000 virements, chaque virement-annulation coûterait 2 couronnes au cabinet d’avocat (2 couronnes de frais et aucun gain puisque les activistes ont annulé leurs virements).
Etant donné qu’un activiste pouvait participer plusieurs fois en réalisant plusieurs virements de micro-dons, le préjudice financier pour le cabinet d’avocat fut encore plus important.

Catégories de tests selon l’OWASP

L’OWASP (Open Web Application Security Project) est un projet communautaire traitant  de la sécurité des applications web. L’OTG (OWASP Testing Guide) est un des projets de l’OWASP qui introduit dans sa dernière version (v4 septembre 2014) un exemple d’approche pour auditer les applications contre les vulnérabilités de logique métier. L’OTG regroupe les tests en 9 catégories :

  • Test de validation des données de logique métier
  • Test de la possibilité de forger ou prédire des requêtes
  • Test des vérifications de l’intégrité et les éléments de preuve
  • Test du processus de Timing
  • Test de la limite de l’utilisation d’une fonction
  • Test pour le contournement du workflow
  • Test des protections contre le détournement de l’application
  • Test de téléchargement de type imprévu de fichiers
  • Test de téléchargement de fichiers malveillants

Conclusion

Les failles de logique métier sont le résultat d’une mauvaise conception de la sécurité des cheminements applicatifs : il n’y a pas de vulnérabilité applicative dans le code lui-même, il s’agit uniquement de problématiques d’abus de fonctionnalités liées à un contrôle insuffisant des entrées utilisateurs.
Ces vulnérabilités sont faciles à détecter manuellement par un attaquant comprenant les fonctionnalités de l’application, ce qui peut engendrer un risque important. Ce dernier est accentué car généralement les vulnérabilités de  logique métier resteront en grande partie indétectables en phase de recette, par la quasi-totalité des outils de scans de vulnérabilité ou d’intrusion.
Il est donc primordial de réaliser des audits de sécurité avec l’intervention de consultants (tests d’intrusion /audits applicatifs) et de ne pas se contenter des résultats des scans de vulnérabilités automatisés.

Références
• « OWASP Testing Guide v4 », consultable en ligne : https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
• « OWASP Business Logic Security Cheat-sheet », consultable en ligne: https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet
• « Real world AppSec flaws: examples and countermeasures », Sydney WebApps Meetup, March 2013
• [Bikash Barai], « Anatomy of business logic vulnerabilities », iViZ Security, Jan 2013
• [Sumit Siddharth, Richard Dean], « The Art Of Exploiting Logical Flaws in Web Applications », Blackhat Briefings Abu Dhabi – December 2012
• [Filippos Georgiadis], « Identification & Exploitation of Business Logic Flaws in Web Applications », FR-HACK Conf, 2009.
[Mats Lewan], « Lawyer in Pirate Bay case facing ‘DDo$’ attack », May 13, 2009, consultable en ligne : http://www.cnet.com/news/lawyer-in-pirate-bay-case-facing-ddo-attack/