Rapport de test d'intrusion pour l'échange centralisé

Résumé de gestion

L'équipe Centralized Exchange a contacté Sayfer afin d'effectuer des tests de pénétration complets de la boîte noire sur leur application Web et un examen de la boîte blanche pour leur architecture cryptographique en décembre 2021.

Avant d'évaluer les services ci-dessus, nous avons organisé une réunion de lancement avec l'équipe technique de Centralized Exchange et avons reçu un aperçu du système et des objectifs de cette recherche.

Au cours de la période de recherche de 4 semaines, nous avons découvert 10 vulnérabilités dans le système. Les vulnérabilités les plus dangereuses étaient l'injection SQL et les failles de la logique métier.

L'impact sur le système est critique car un attaquant malveillant pourrait exploiter certaines de ces vulnérabilités pour profiter du système, soit en changeant son rôle d'utilisateur en "super_user" via l'injection SQL, soit en abusant du système et en volant de l'argent à l'échange centralisé. en utilisant le mécanisme de mise à jour du système 30s.

Méthodologie d'évaluation de la sécurité

Sayfer utilise OWASP WSTG comme norme technique lors de l'examen des applications Web. Après avoir acquis une compréhension approfondie du système, nous avons décidé quels tests OWASP sont nécessaires pour évaluer le système.

Résultats de l'évaluation de la sécurité

Enregistrement des clés MPC privées de manière non sécurisée

Description

Les échanges centralisés souffrent de pratiques de gestion des clés de mauvaise qualité. Il existe de nombreux exemples de tels cas où les clés ont été perdues ou volées, entraînant la perte par le service de tous les fonds du portefeuille ou le verrouillage complet des fonds.

Lors de notre audit des fichiers de configuration, nous sommes passés en revue le stockage de la gestion des clés. Nous avons constaté que les clés utilisées pour le portefeuille multi-signatures froid ne sont pas stockées dans des emplacements suffisamment distribués.

Il y a 3 clés qui sont utilisées dans la signature de clé MPC. 1 est stocké dans une machine physique protégée. Les 2 autres sont stockés dans la même machine dédiée dans GCP.

Quelques mesures de sécurité ont été prises pour sécuriser ces machines, mais le problème repose sur la distribution. Si la machine déployée sur GCP est compromise, un attaquant peut signer n'importe quelle transaction à partir du portefeuille froid.

Il s'agit d'un endroit à haut risque et sensible où beaucoup ont échoué dans le passé, les meilleures pratiques doivent être strictement suivies.

Atténuation

Utilisez un service de dépositaire tiers pour gérer les portefeuilles chauds et les coffres-forts. Nous nous ferons un plaisir de vous recommander un de nos partenaires.

Ces services gèrent le MPC et la gestion des clés pour vous, avec d'autres couches de sécurité supplémentaires faisant de l'utilisation de ces services le meilleur choix pour les échanges centralisés.

Injection SQL

Description

Une attaque par injection SQL consiste à insérer ou « injecter » une requête SQL partielle ou complète dans l'entrée de données qui est transmise du client à l'application Web. Une attaque par injection SQL réussie peut lire des données sensibles dans la base de données, modifier les données de la base de données (insérer/mettre à jour/supprimer), effectuer des opérations d'administration de la base de données (telles que l'arrêt du SGBD), récupérer le contenu d'un fichier donné sur le système de fichiers du SGBD ou écrire des fichiers dans le système de fichiers et, dans certains cas, envoyer des commandes au système d'exploitation.

Le transaction point final, nous avons pu abuser de la more Paramètre de requête d'URL pour injecter une charge utile SQL malveillante :

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

La charge utile que nous avons utilisée était :

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b – Qui dans ce cas, vérifie si l'instance en cours d'exécution de Postgres est la version 10 ou non.

Un attaquant qui exploite cette vulnérabilité pourrait prendre le contrôle du système. Nous avons pu extraire les schémas de table, mettre à jour le rôle de notre propre utilisateur ou vider toutes les informations enregistrées sur la base de données et même modifier le solde de notre utilisateur sur la base de données.

Atténuation

La vulnérabilité d'injection SQL est facile à corriger mais difficile à atténuer. Un linting fort ou la mise en œuvre de règles de compilation qui imposent les changements futurs sont nécessaires.

L'atténuation des vulnérabilités d'injection SQL est généralement effectuée en suivant un cadre de choix, ce qui signifie que le développeur ne doit jamais concaténer des chaînes dans une instruction SQL complète.

Chaque entrée utilisateur doit être filtrée dans un exécuteur SQL plutôt que d'être utilisée comme une simple chaîne de requête SQL.

Pour plus d'informations sur la perfection de l'injection SQL, veuillez consulter le SQL IAide-mémoire sur la prévention des injections.

Références d'objet directes non sécurisées

Description

Les références d'objet directes non sécurisées (IDOR) sont un type de vulnérabilité de contrôle d'accès qui survient lorsqu'une application utilise une entrée fournie par l'utilisateur pour accéder directement aux objets. En raison de cette vulnérabilité, les attaquants peuvent contourner l'autorisation et accéder directement aux ressources du système, par exemple, les enregistrements ou les fichiers de la base de données.

Nous avons découvert que l'API █████████ permet à un attaquant de voir les informations du tableau de bord d'autres utilisateurs, y compris toutes les données financières de cet utilisateur.
La vulnérabilité repose sur le paramètre d'identification du tableau de bord qui est un entier devinable. Exemple de demande pour un seul tableau de bord (pour un tableau de bord qui n'appartient pas à l'utilisateur actuel) :

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

Cela indique que le /dashboard/DASHBOARD_ID le point de terminaison ne vérifie pas l'autorisation pour la ressource demandée. Un attaquant authentifié pourrait gratter chaque tableau de bord contenant des informations sur les fonds de l'utilisateur et les transactions passées.

Atténuation

Il existe plusieurs façons d'atténuer les vulnérabilités IDOR, dans ce cas, il semble que la solution pourrait être de vérifier l'autorisation pour chaque demande.

Cela signifie que chaque clé de requête ne pourra récupérer que les tableaux de bord de son compte

Authentification plus faible dans le canal alternatif

Description

Même si les mécanismes d'authentification principaux n'incluent aucune vulnérabilité, il se peut que des vulnérabilités existent dans d'autres canaux d'utilisateurs légitimes d'authentification pour les mêmes comptes d'utilisateurs.

Cette vulnérabilité fait partie d'une chaîne de 2 vulnérabilités qui nous a permis de prendre en charge n'importe quel compte avec juste une adresse e-mail.

Dans le cadre de notre phase de reconnaissance où nous essayons de trouver un vecteur d'attaque plus large en énumérant les principaux sous-systèmes cibles, nous avons trouvé une interface d'administration sous le sous-domaine ██████████████████. Il est possible de se connecter à l'interface d'administration en utilisant un utilisateur normal de l'application, mais pour presque toutes les requêtes réseau que nous avons inspectées lors du chargement de la page principale, le serveur renvoie une erreur 401.

[IMAGE_REDACTED]

Nous avons procédé à une rétro-ingénierie du fichier bundle main.js qui contient le code frontal de l'application et avons trouvé tous les points de terminaison potentiels avec lesquels un administrateur peut interagir.

Nous ne pourrions exploiter que le point final de api/updateUser. Le point de terminaison nous a permis de modifier n'importe quel e-mail d'utilisateur, et ce faisant, nous avons pu réinitialiser le mot de passe de la victime et reprendre le compte

[IMAGE_REDACTED]

Atténuation

Il est fortement recommandé de mettre en place un mécanisme d'authentification ou un VPN pour le débogage ou pour les services d'administration du système afin d'empêcher la présence d'applications publiques non sécurisées pouvant être exploitées par un attaquant.

De plus, il existe un mécanisme d'autorisation dans l'interface d'administration, mais cela sort du cadre de ce projet.

Examiner les métafichiers du serveur Web pour détecter les fuites d'informations

Description

Dans le cadre de nos recherches sur la cible et ses sous-domaines, nous avons trouvé des métafichiers qui ne devraient pas être publics, ou du moins pas sans le mécanisme d'authentification approprié.

• ████████████████████████.gitignore
• ██████████████████████████████/docker-compose.yml
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

Nous avons trouvé trois types de fichiers qui peuvent nuire aux services ████████, .gitignore, swagger-ui et par docker-compose.yml dossier. Ces trois fichiers révèlent des données sensibles

sur l'architecture des services. Un acteur malveillant peut utiliser ces informations pour augmenter son vecteur d'attaque sur la cible.

Atténuation

Si possible, retirez ces fichiers du service public ou mettez en place un mécanisme d'autorisation qui n'accorde l'accès qu'aux utilisateurs privilégiés.

En-tête de politique de sécurité de contenu manquant

Description

La politique de sécurité du contenu (CSP) est une couche de sécurité supplémentaire qui permet de détecter et d'atténuer certains types d'attaques, notamment les attaques de script intersite (XSS) et d'injection de données.

Nous n'avons trouvé d'en-tête CSP dans aucune des réponses du serveur.

[IMAGE_REDACTED]

En utilisant les administrateurs de sites Web CSP, ils ajoutent une autre ligne de défense contre les attaques XSS ou de détournement de clics, ce faisant, le système sera sécurisé même si de futures modifications non sécurisées sont apportées au code source.

Une politique CSP de base doit au moins décrire les domaines par défaut sur liste blanche pour les fichiers statiques (tels que les scripts, les images et les CSS). Et frame-ancestors pour empêcher les attaques par détournement de clic.

Plus d'infos:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

Atténuation

Ajout du Content-Security-Policy: [policy] sur chaque réponse où le chargement de ressources externes pourrait être dangereux

Nous vous recommandons vivement de l'utiliser et de le tester d'abord avec la variante "Report-Only" pour tester votre politique avant de la mettre en production :

Content-Security-Policy-Report-Only: [policy]

Test des en-têtes de sécurité

Description

1. Les navigateurs prennent en charge de nombreux en-têtes HTTP qui peuvent améliorer la sécurité des applications pour se protéger contre une variété d'attaques courantes, les en-têtes sont échangés entre un client Web (généralement un navigateur) et un serveur pour spécifier les détails liés à la sécurité de la communication HTTP.

En regardant les en-têtes de sécurité de ████████, il manque ce qui suit :

• Options de type de contenu X

Définir cet en-tête empêchera le navigateur d'interpréter les fichiers comme autre chose que ce qui est déclaré par le type de contenu dans les en-têtes HTTP.

• Strict-Transport-Sécurité

HSTS est un mécanisme de politique de sécurité Web qui aide à protéger les sites Web contre les attaques de dégradation de protocole et le détournement de cookies. Il permet aux serveurs Web de déclarer que les navigateurs Web ne doivent interagir avec lui qu'en utilisant des connexions HTTPS sécurisées, et jamais via le protocole HTTP non sécurisé.

• Politique de parrainage

L'en-tête Referer est un en-tête de requête qui indique le site d'où provient le trafic. S'il n'y a pas de prévention adéquate en place, l'URL elle-même, et même les informations sensibles contenues dans l'URL, seront divulguées au site d'origine croisée.

• Contrôle d'accès-Autoriser-Origine

L'en-tête a la valeur "*" qui expose l'API pour chaque site Web, ce n'est peut-être pas le résultat souhaité.

Atténuation

Ajout des en-têtes mentionnés ci-dessus à tous les services back-end.

Examiner les métafichiers du serveur Web pour détecter les fuites d'informations

Description

Lors de la recherche de la cible avec DevTool, nous avons pu afficher le code source frontal sans aucun obscurcissement. Cette vulnérabilité se produit parce que les bundles JS sont livrés avec des cartes source en production, ce qui permet de lire le code source d'origine avec des commentaires susceptibles de révéler des informations, par exemple, le fichier paths.ts suivant :

█████████████████████/paths.ts [IMAGE_REDACTED]

En disposant de la carte source, un attaquant peut en savoir plus sur la base de code, lire les commentaires et trouver des parties de code obsolètes qui peuvent ensuite être utilisées pour trouver des vulnérabilités.

Atténuation

N'expédiez pas les cartes source à la production, la plupart des systèmes de journalisation et de traçage des erreurs sont d'avis de télécharger les cartes source vers un système de back-office. Une autre approche serait de servir les cartes source uniquement aux utilisateurs authentifiés via VPN ou d'autres mécanismes.

Serveur Web d'empreintes digitales

Description

Bien que les informations de serveur exposées ne constituent pas nécessairement une vulnérabilité en elles-mêmes, ce sont des informations qui peuvent aider les attaquants à exploiter d'autres vulnérabilités qui peuvent exister. La plupart des points de terminaison ne divulguent aucune information sur le serveur via des en-têtes HTTP ou des pages d'erreur.
En utilisant la requête HTTP mal formée suivante, nous avons pu identifier un serveur Nginx via une réponse 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

Le corps de la réponse est :
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

Atténuation

Il existe différentes manières d'obscurcir les en-têtes de serveur Web, les méthodes les plus couramment utilisées sont :

1. Serveurs proxy inverses qui se situent entre l'internet mondial et l'interne
2. Configurez chaque serveur Web pour supprimer ces en-têtes.

Annexe A : Correctifs d'évaluation de la sécurité

Sera mis à jour par l'équipe Sayfer après la première révision.