Les données d'entreprise sont souvent un secret commercial. Les fuir peut porter atteinte à la réputation, des pertes financières ou même la faillite. Par conséquent, les exigences de sécurité pour un produit B2B doivent être très élevées. Création d'un nouveau produit - Corporate Mail Mail.ru - nous avons accordé une attention particulière à la question de sa sécurité.
Corporate Mail Mail.ru est une version sur site du courrier B2C familier Mail.ru. Par rapport à lui, il contient un certain nombre de modifications pour travailler dans un nouvel environnement - le circuit client.
Pour que nos clients aient confiance en la sécurité, nous avons décidé de nous soumettre à un audit dans une société tierce et de corriger toutes les lacunes constatées avant de proposer le produit sur le marché. Pour ce faire, ils se sont tournés vers l'une des entreprises les plus réputées dans le domaine de la sécurité de l'information - la sécurité numérique.
Les résultats de l'audit sont sous la coupe.
Exécution de code à distance dans uWSGI
Il existe différents frameworks pour créer des applications Web Python. En règle générale, l'interface de passerelle du serveur Web Python (WSGI) est utilisée pour communiquer entre l'application Web et le serveur Web. De plus, l'utilisation de WSGI vous permet d'implémenter des composants middleware.
Pour standardiser la communication entre une application Web Python et un serveur Web tel qu'Apache ou Nginx, PEP 0333 a été développé, suivi de PEP 3333, qui décrit l'interface WSGI. Nous ne nous attarderons pas sur le fonctionnement de WSGI, mais vous parlerons d'un serveur populaire prenant en charge l'interface WSGI - uWSGI.
Le serveur uWSGI peut fonctionner à la fois en mode serveur Web normal et en "mode WSGI", en échangeant des données avec un autre serveur Web, tel que Nginx. Dans le même temps, Nginx utilise le protocole binaire du même nomuwsgi , qui est intéressant pour les cybercriminels en raison de sa riche fonctionnalité. Lors de l'analyse des «composants internes» de la solution, un serveur uWSGI a été trouvé, auquel tous les composants internes du produit avaient accès.
Le problème était que dans le protocole uwsgi, vous pouvez utiliser des variables dites magiques qui vous permettent de configurer dynamiquement le serveur uWSGI. Parmi ces variables, il y en a
UWSGI_FILEune qui vous permet de charger une nouvelle application dynamique si vous spécifiez le chemin d'accès au fichier dans la variable. En fin de compte , uwsgi-serveur peut gérer les différents circuits de cette manière, par exemple section, fd, callou le plus intéressant - exec. Ainsi, vous pouvez passer la variable comme valeurexec://<cmmand>pour exécuter une commande bash arbitraire. Un exploit a été écrit pour analyser ce problème et est disponible sur github .
Un exemple de requête qui exécute une commande.
Cette vulnérabilité ne pourrait être exploitée que si l'attaquant:
- Est déjà sur le réseau interne du produit, par exemple, l'un des composants a été compromis. Cela pourrait lui permettre de détourner un nouveau composant, d'accéder à de nouvelles données et de poursuivre l'attaque.
- A SSRF avec la capacité d'envoyer des données arbitraires sur TCP (par exemple en utilisant
gopher://). Dans ce scénario, un attaquant peut accéder à l'intérieur du produit.
Il convient de noter que les implémentations d'interfaces CGI pour d'autres langages de programmation ou frameworks peuvent également être vulnérables, par exemple, un exploit du même référentiel pour FastCGI. Cela ne veut pas dire qu'il s'agit d'une vulnérabilité au sens habituel du terme, mais plutôt d'une fonctionnalité des serveurs CGI, vous devez donc limiter autant que possible l'accès à ces serveurs.
Contournement de la protection CSRF
Avec l'introduction de divers mécanismes de sécurité dans les navigateurs, les attaques côté client sur le Web moderne disparaissent progressivement. Cela s'applique également à CSRF: les navigateurs ont déjà implémenté la prise en charge du cookie SameSite, bien que s'il est mal configuré, il peut encore y avoir des failles. De plus, de nombreux frameworks populaires permettent aux développeurs de configurer facilement la protection CSRF, mais quelques bogues ou vulnérabilités non critiques peuvent conduire à une attaque CSRF. De telles erreurs ont été trouvées dans l'application de calendrier incluse avec notre produit.
L'application dispose d'une API qui vous permet d'effectuer des actions sur les événements et les calendriers des utilisateurs, par exemple: les modifier, les afficher ou les supprimer. Pour faire référence à l'objet, le paramètre UID est passé dans le chemin de l'URL, qui est responsable de l'ID du calendrier ou de l'événement. Cela ressemble à ceci:
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
Par défaut, l'UID est généré aléatoirement et ne peut pas être influencé par l'utilisateur. Mais dans l'application, deux emplacements ont été trouvés dans lesquels l'utilisateur peut modifier l'UID.
La première consiste à importer des fichiers au format ICS (un format spécial pour les calendriers et les événements), ils ont un champ UID spécial que l'utilisateur contrôle lors de l'importation. Dans ce cas, après l'importation des événements, leurs UID resteront les mêmes que ceux qu'ils ont été transférés dans le fichier. De plus, ce paramètre n'a pas de filtrage. Ainsi, l'utilisateur peut créer un événement avec un UID arbitraire.
Le second est la possibilité de changer le calendrier UID lors de sa modification. Cela pourrait être fait en interceptant la demande de modification du calendrier et en modifiant simplement le champ UID. Il n'y avait pas non plus de filtrage ici.
Autre caractéristique importante: cette API implémente la protection CSRF; pour cela, un paramètre spécial est passé dans les paramètres GET, qui joue à la fois le rôle d'une clé pour l'API et d'un jeton CSRF. Il est ajouté via JavaScript à toutes les demandes d'API. Il est déconseillé de transmettre des jetons CSRF dans les paramètres GET.Dans ce cas, les jetons peuvent fuir via le référent, les journaux d'application ou l'historique du navigateur.
Mettre tous ensemble. Un attaquant peut contrôler les UID d'objet dans une application et partager l'accès aux événements et aux calendriers avec d'autres utilisateurs. Dans ce cas, les utilisateurs verront le même UID, et lorsqu'ils commenceront à travailler avec un tel objet, les requêtes seront exécutées avec l'UID contrôlé par l'attaquant. En utilisant cela, un attaquant peut créer un objet avec un UID comme:
../../../AnyPathTo?anyparam=value&
Désormais, lorsque l'utilisateur effectue une action sur l'objet, une requête sera générée:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
Ensuite, un token lui sera également ajouté, jouant le rôle d'un token CSRF:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
Et enfin, en faisant la demande, le navigateur normalise la séquence "
../", en conséquence, la demande sera envoyée à
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
Désormais, un attaquant peut forcer un utilisateur à envoyer une requête à l'application le long d'un chemin arbitraire avec des paramètres arbitraires et avec le jeton CSRF correct. Il reste à comprendre quelles méthodes de requête nous pouvons exécuter.
Cela s'est avéré simple: lors de l'édition, un PUT est envoyé, lors de la suppression, un DELETE, et lors de la visualisation, un GET (POST est utilisé pour la création, et nous ne pouvons pas forcer la victime à l'utiliser). En utilisant DELETE, un attaquant peut forcer le navigateur de l'utilisateur à exécuter une requête pour supprimer un objet de l'utilisateur. Un autre bonus pour un attaquant est que lorsqu'un utilisateur modifie un objet, une requête PUT est envoyée avec le corps de la requête. Lors de la modification d'un calendrier, le corps de la requête contiendra JSON, qui contient tous les paramètres du calendrier actuel. Autrement dit, l'attaquant qui a créé le calendrier «malveillant» contrôle ces paramètres. Si un attaquant réussit à rediriger une demande d'édition du calendrier «malveillant» vers le calendrier privé de l'utilisateur, alors toutes les propriétés du calendrier «malveillant» seront appliquées aux propriétés du calendrier de l'utilisateur victime.Cela peut remplacer l'accès au calendrier car il s'agit de l'une des propriétés de calendrier spécifiées dans JSON.
Capacité d'attaque MITM
La pénétration d'un intrus dans le réseau interne de l'entreprise est une situation dangereuse aux conséquences graves. Par conséquent, lors de l'audit du produit, l'une de nos tâches était de trouver des failles dans l'architecture du système qui pourraient aider un intrus à se déplacer dans le domaine ou améliorer les attaques externes.
L'une des principales caractéristiques du produit est l'intégration avec Active Directory. Il est implémenté pour l'authentification via LDAP et la collecte des messages du serveur Exchange, dans cet exemple nous nous concentrerons sur ActiveSync. Pour un attaquant, il s'agit d'une cible très intéressante car les comptes utilisateurs et les mots de passe sont passés entre le produit et Active Directory lors de la connexion. En accédant aux connexions, un attaquant pourra détourner des comptes et sera un pas de plus vers la compromission du domaine.
Dans les solutions internes et sur les serveurs des entreprises, il y a souvent un problème d'utilisation incorrecte de TLS ou de son absence du tout, alors qu'il n'est pas difficile d'implémenter TLS pour un service. Cela est généralement dû au fait que le réseau interne de l'entreprise est considéré comme plus sécurisé et que les administrateurs de l'entreprise ne passent pas de temps à créer la bonne infrastructure PKI et à émettre des certificats pour tous les serveurs.
L'attaque la plus courante à l'intérieur des réseaux d'entreprise est MITM. Ce type d'attaque permet le plus souvent d'accéder à l'Active Directory d'une entreprise. Dans le même temps, il n'est pas toujours possible pour un attaquant d'attaquer l'interaction serveur à serveur au sein du réseau de l'entreprise; le plus souvent, lors des tests de pénétration, lui ou son modèle tombe dans un segment de réseau utilisateur dans lequel il n'y a pas de serveur Exchange ou de contrôleur de domaine. De plus, dans notre cas, le produit n'utilise pas de protocoles de résolution de noms de diffusion tels que NBNS, LLMNR, mDNS, donc l'usurpation de ces protocoles ne permettra pas la mise en œuvre de MITM. Ainsi, pour un MITM réussi entre la solution et les autres serveurs, il est nécessaire que l'attaquant ait accès au réseau où l'un de ces composants est installé. Il est parfois possible d'atteindre cet objectif - il existe des routeurs ou des serveurs vulnérables,qui vous permettent finalement d'accéder à un réseau particulier.
Dans notre cas, lors de l'analyse, il s'est avéré que l'intégration avec Active Directory est vulnérable aux attaques MITM.
Lorsque l'utilisateur entre un nom d'utilisateur et un mot de passe, le système envoie deux demandes LDAP au contrôleur de domaine. La première demande renvoie une liste d'adresses e-mail, et si la connexion de l'utilisateur est présente dans cette liste, la deuxième demande est envoyée, qui est l'authentification LDAP simple. Les données sont transmises en texte clair sans utiliser SSL / TLS, ou plutôt, LDAPS (LDAP sur SSL) n'est pas utilisé. Cela permet à un attaquant, même en cas d'attaque passive MITM, d'obtenir des comptes utilisateurs actuellement autorisés dans le produit.
Le deuxième problème: lors de la connexion au serveur Exchange en utilisant le protocole ActiveSync pour collecter les messages entrants, le système n'a pas vérifié l'authenticité du certificat TLS du serveur. Dans ce cas, un attaquant pourrait implémenter une attaque MITM active, à la réception d'une connexion, il pourrait donner un certificat auto-signé, établir une connexion et envoyer les données par proxy au serveur Exchange; alors MITM sera invisible, et un attaquant peut obtenir les informations d'identification de l'utilisateur, qui sont transmises dans le protocole ActiveSync.
En exploitant ces vulnérabilités, un attaquant pourrait théoriquement obtenir des comptes utilisateurs, puis les utiliser dans une attaque sur un domaine Active Directory. Par ailleurs, il convient de noter que l'utilisation correcte de TLS est une tâche nécessaire pour l'entreprise qui met en œuvre la solution.
Résultat
Nous sommes constamment confrontés à des attaques de hackers et avons acquis une solide expérience dans la manière de les combattre. Nous pensons que les produits que nous mettons dans le périmètre du client doivent être aussi sûrs que possible, y compris sur la base des résultats de contrôles indépendants. Corporate Mail Mail.ru est un tel produit.
Nous avons été confrontés à une tâche laborieuse: transférer une grande base de code avec de nombreux microservices vers l'infrastructure du client, afin que le courrier fonctionne seul la plupart du temps, sans échecs et interventions de l'administrateur.
Nous avons demandé aux auditeurs d'accorder la plus grande attention à l'autorisation modifiée (Corporate Mail utilise l'AD du client) et à l'API de messagerie principale - le code source de ces composants a été analysé en détail. En conséquence, les lacunes constatées étaient principalement liées à la modification de la topologie du réseau et aux modifications spécifiques à la solution sur site.
Pour le reste des composants (calendrier, Mail.ru pour l'interface d'administration commerciale), un modèle de boîte grise a été utilisé: les auditeurs interagissaient avec le service avec les privilèges des utilisateurs ordinaires, mais pouvaient se connecter au conteneur avec l'application en cours d'exécution, possédaient partiellement le code source de l'API et pouvaient clarifier les détails avec les développeurs.
L'audit nous a été très utile. Nous avons trouvé un certain nombre de défauts dans certains composants, que nous avons rapidement corrigés pour mettre un produit sûr sur le marché. Dans le même temps, nous avons été convaincus du haut niveau de sécurité de la plupart des autres composants. Nous prévoyons de mener de tels audits sur une base régulière - nous voulons que notre produit soit toujours au top des solutions nationales les plus sûres, non seulement à notre avis, mais aussi à l'opinion des auditeurs indépendants.
La sécurité de Corporate Mail est la combinaison de la sécurité du produit lui-même et de l'infrastructure du client. Autrement dit, la responsabilité de la sécurité des données d'entreprise incombe à nous, le développeur et le client lui-même. De plus, nous avons formulé des recommandations de bonnes pratiques pour protéger l'infrastructure des failles et toujours conseiller les clients lors de l'installation de notre produit.