Comment une simple balise peut-elle devenir un risque élevé pour une entreprise?

La sécurité avec des exemples réels est toujours intéressante.

Aujourd'hui, nous allons parler de l'attaque SSRF, lorsque vous pouvez forcer le serveur à effectuer des requêtes arbitraires sur Internet via la balise img.



J'ai donc récemment participé à des tests de pénétration sur deux projets simultanément, sur deux d'entre eux cette vulnérabilité a été révélée. Des captures d'écran sont extraites directement des rapports, car toutes les informations supplémentaires sont tachées.

Description de l'attaque

Nom de l'attaque: le serveur envoie des requêtes arbitraires à Internet lors de la génération d'un document PDF.

Description: le PDF est généré côté serveur à partir d'une page html entièrement rendue avec toutes les ressources externes. Les documents contiennent des données saisies par l'utilisateur. Sans filtrage approprié, vous pouvez remplacer vos ressources externes dans le rendu du serveur. Dans ce cas, qu'il s'agisse du fichier it-band.by/10gb.blob (censé avoir une taille de 10 Go).

Pire scénario:

1. Ddos attaque de l'intérieur lorsque le système a besoin de télécharger 100 gigaoctets de données pour le rendu afin de rendre plusieurs documents PDF à la fois. En conséquence, cela conduit à un manque de ressources réseau ou mémoire, ce qui peut entraîner une panne du système.
2. Un utilisateur malveillant peut utiliser le serveur comme plate-forme pour attaquer d'autres ressources.
3. Un utilisateur malveillant obtient les adresses IP externes des serveurs internes pour les attaques directes, en contournant les pare-feu d'applications Web (WAF) et les équilibreurs.

Évaluation des risques (probabilité * impact): moyen (5) * élevé (7) = élevé (35) (dans les deux systèmes, le risque a été jugé élevé, bien qu'avec des ratios différents)

Ce qui est intéressant:

1. Un système a utilisé wkhtmltopdf pour rendre html2pdf, le second a exécuté Firefox, y a chargé la page et a pris une capture d'écran. Dans tous les cas, les deux systèmes affichent immédiatement les deux pages, y exécutent tout le code et ne font ensuite que PDF à partir de cela.
2. La protection du serveur XSS a été installée sur les deux systèmes, mais au lieu d'utiliser l'échappement des données d'entrée, les deux systèmes ont utilisé la purification html, qui effaçait tous les iframes, scripts, css, formulaires, etc. Mais la purification html dans les deux systèmes était considérée comme du code html img src="https://it-band.by/10Gb.blob?t=12345.1"/ sûr.

Maintenant, suivez les étapes et les captures d'écran

1) Créez un tel fichier localement, afin de le remplir ultérieurement en tout ou en partie.



2) Au début, vous devez trouver les champs d'utilisateurs vulnérables.

Système 1. Impossible d'insérer une seule balise img





Système 2. J'ai réussi à insérer environ 20 balises tout de suite



3) Ensuite, nous générons le document PDF.

Système 1. PDF généré



Système 2. PDF généré



4) Et maintenant, nous montons sur notre serveur pour voir s'il y avait des demandes pour notre gros fichier 10Gb.blob.

Système 1. Nous obtenons l'adresse IP du serveur et le logiciel avec lequel le document PDF a été généré, nmap a montré un autre port ouvert, que personne n'avait vu auparavant, par l'adresse IP trouvée.



Système 2. On peut voir que le serveur a essayé de télécharger 20 fichiers de 10 gigaoctets. Nous obtenons également l'adresse d'un des serveurs et la version de Firefox utilisée.



Le résultat. Dans les deux systèmes, des erreurs ont déjà été corrigées. Dans le premier système, au lieu de la purification HTML, l'échappement se fait à la fois lors du traitement des données utilisateur et lors de la génération d'un document PDF; dans le deuxième système, tous les liens absolus avec les ressources externes sont coupés pendant le traitement des données utilisateur.

Mis à jour.

Pendant que j'arrivais à la publication de l'article, des cas de 2 systèmes supplémentaires ont été ajoutés.

Un autre système (appelons System 3) n'a pas réussi la vérification de ce type de vulnérabilité à deux endroits à la fois: via HTML Injection et CSS Injection.

Système 3. Injection HTML avec téléchargement 20 fois d'une image en direct de 13 Mo (au total 260 Mo)



Système 3. Injection CSS



Système 3. Que voit-on sur le serveur attaquant lors du rendu d'un PDF (les 20 téléchargements d'une image de 13 Mo sont réussis)



Quelle était la sortie pour le système 3:

1) A obtenu les adresses des serveurs qui rendent et ce qu'ils utilisent pour le rendu. Dans ce cas, HeadlessChrome.

2) La génération d'un document PDF a pris environ 5 minutes, puis le chrome est simplement tombé. Imaginez, si vous exécutez 10 000 de ces demandes, alors pendant un certain temps, les serveurs de génération cesseront, en principe, de répondre aux demandes d'autres utilisateurs.

Système 4. L' attaque SSRF ici n'a pas été effectuée via la balise img, mais via XSS, lorsque ma charge utile préférée a été exécutée sur le serveur pendant le rendu et que le serveur a lancé un code Javascript arbitraire lors de la génération du document PDF. Par rapport aux cas précédents, il est possible de mener des attaques plus complexes sur d'autres systèmes.



Système 4. PDF rendu avec code JS arbitraire exécuté côté serveur



Prémisse 1. Les systèmes nécessitent le développement non seulement des règles du pare-feu entrant, mais aussi du pare-feu sortant, ou le développement d'une infrastructure avec des segments de réseau ou des serveurs séparés, dont il n'y a généralement pas d'accès à l'extérieur.

Prémisse 2. Lorsque vous recherchez la moindre vulnérabilité, vous devez toujours rechercher les pires scénarios de son utilisation et de son impact sur l'entreprise. Les entreprises ne peuvent travailler qu'avec des risques, le côté technique, malheureusement, les intéresse peu.

Les informations ci-dessus sont fournies uniquement à des fins éducatives et éducatives, comment faire leurs systèmes n'est pas nécessaire.

Denis Koloshko, CISSP, testeur de pénétration