Cette entrée est divisée en deux parties. Dans le premier, je publie une description de la vulnérabilité que j’ai pu identifier dans le cadre du « EY GDS Poland Cybersecurity Challenge ». Dans le second, je décris mes réserves quant à la forme de ladite « défi » et j’explique pourquoi je le fais.
Partie 1 – Erreurs de sécurité détectées
1. Scriptage croisé reflected
Score CVSSv3: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravité: Critique
Trouver:
La vulnérabilité de script croisé réflecté a été trouvé au cours du test. Il permet d’injecter et d’exécuter le code JavaScript dans le contexte de l’application. Le code JavaScript n’est réflecté que par le serveur, qui est différent du script croisé stocké qui stocke le code dans l’application de façon permanente. Cette vulnérabilité est surtout exploitée pour détourner les sessions des utilisateurs authenticés. Il peut également être utilisé pour redistribuer les utilisateurs vers des sites Web malveillants ou pour diriger les clés de l’utilisateur de l’application.
Preuve:
Demande:
GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Référence: http://192.168.140.129/index.php?page=login
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connexion: procheRéponse:
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:04:34 GMT
Serveur: Apache/2.4.6 (CentOS) HTML/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: sans magasin, sans cache, must-revalidate, post-check-0, pré-check-0
Pragma: sans cache
Contenu-Longueur: 1248
Connexion: proche
Type de contenu: texte/html; charset-UTF-8<html>
<head>
<title>Système de chat interne</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
<a href="/">
<img src="ey-logo.png" height="72" alt="EY">
</a>
<div style="margin-top:50px;">
<nav>
<a href="/index.php?page=messages">mes messages</a>
<a href="/index.php?page=new_message">Envoyer un message</a>
<a href="/index.php?logout">Logout</a>
</nav>
</div>
<div style="margin-top:20px;">
<div class='message_error'>Échec de login</div>
<form target="_self">
<div class="container">
<label for="login"><b>Connexion</b></label>
<input type="text" placeholder="Enter login" name="login" id="login"
value="testhqw60"><script>alert(1)</script>k9nju » required>
<label for="psw"> <b>Mot de passe</b></label></div></form></div></div></body></html>Recommandation:
Le problème est issu d’un manque de vérification des entrées et d’un manque de classification des entrées. Il est fortement recommandé d’incorporer à la fois des règles strictes d’assainissement des entrées et des enquêtes sur les sorties. Les caractères spéciaux HTML comme '<' and="" '="">' doent être html-encodés (remplacés par '<' and="" '="">' respectivement) dans toutes les données lues à partir des entrées, bases de données et fichiers de l’utilisateur.</'> </'> Les mêmes avantages pour les personnages comme " (qui devrait être remplacé par « ) et ' (qui devrait être échappé avec un signe de réaction ). En tournant, l’assainissement strict des entrées signifie une approche différente pour la validation des entrées. Par instance, si une variable est tenue de tenir un numéro, il est préférable de vérifier s’il s’agit en fait d’un numéro (comme s’il s’agit d’une expression régulière ou d’une distribution d’entier) au lieu d’essayer de comprendre tous les mauvais caractères possibles à filtrer. La validation d’entrée qui se trouve sur le côté serveur est obligatoire, tandis que la validation sur le côté client ( HTML/JavaScript, navigateur Web, qui est contrôlé par l’utilisateur) devrait être présentée la plupart du temps pour l’utilisation de l’usage, mais aussi en ordre de prévenir ce qu’on appelle le script de site croisé basé sur DOM. Si une variable fournie par un utilisateur est écrite dans le document de base de données/fichier/HTML sans aseptisation préalable, puis affichée à d’autres utilisateurs, une telle vulnérabilité devient un XSS stocké, ce qui est beaucoup plus dangereux car il peut être utilisé contre les utilisateurs authentiques sans aucune action prise sur leur côté. En plus de cela, en utilisant l’échelle d’une attaque XSS stockée est plus étrange que dans le cas d’un réflecté, comme plusieurs utilisateurs peuvent être touchés.
Références:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md
2. SQL Injection
Score CVSSv3: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Gravité:
Trouver:
Flaw d’injection SQL a été trouvé dans l’application. Cette vulnérabilité permet à un attaquant potentiel d’exécuter des requêtes SQL directes sur la base de données sous-jacente. Un attaquant peut par exemple récupérer toutes les informations de la base de données vers laquelle l’utilisateur actuel de la base de données a accès. Il permet également de dégrader le site Web, d’exécuter XSS en les surpeuant sur les données de base de données ou en exécutant les commandes du système.
Preuve :
En fonction du fait que l’application n’utilise pas la paramétrisation, presque tous les paramètres de l’application sont vulnérables à l’injection de SQL.
Demande:
GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Référence: http://192.168.140.129/index.php?page=login
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connexion: procheRéponse:
HTTP/1.1 302 Trouvé
Date: Tue, 05 Jan 2021 17:15:25 GMT
Serveur: Apache/2.4.6 (CentOS) HTML/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: sans magasin, sans cache, must-revalidate, post-check-0, pré-check-0
Pragma: sans cache
Lieu: /index.php?loggedin
Contenu-Longueur: 666
Connexion: proche
Type de contenu: texte/html; charset-UTF-8<html>
<head>
<title>Système de chat interne</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
<a href="/">
<img src="ey-logo.png" height="72" alt="EY">
</a>
<div style="margin-top:50px;">
<nav>
<a href="/index.php?page=messages">mes messages</a>
<a href="/index.php?page=new_message">Envoyer un message</a>
<a href="/index.php?logout">Logout</a>
</nav>
</div>
<div style="margin-top:20px;">
<div class='message_success'>Utilisateur logé dans</div></div></div></body></html>
Recommandation : Chaque
caractère spécial dans les utilisateurs qui entrent des données doit être filtré ou/et aseptisé sur le côté serveur pour prévenir les vulnérabilités d’injection sql. Les valeurs plus fragiles ne devraient pas être traités comme des valeurs à cordes et doivent être desséchées en tant qu’entier avant d’être mises en œddessus. La meilleure pratique consiste à utiliser des déclarations préparées (paramétrées) dans tous les cas où les requêtes de base de données sont présentées.
Références:
CWE-89
http://cwe.mitre.org/data/definitions/89.html
OWASP
https://www.owasp.org/index.php/SQL_Injection
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md
3. Scriptage cross-site magasiné
Score CVSSv3: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravité: Critique
Trouver:
Stored Cross Site Scripting vulnérabilités ont été trouvés au cours du test. Il est surtout exploité pour détourner les sessions des utilisateurs authenticés. Le problème se résorpe d’un manque de verification d’entrée approprié et d’un manque de revêtement de sortie approprié. Un XSS stocké prend place lorsque chaque utilisateur fourni une variable vulnérable est écrit à la base de données / fichier, puis affiché à d’autres utilisateurs. Le XSS stocké par Hence est beaucoup plus dangereux car il peut être utilisé contre d’autres utilisateurs sans action sur leur côté comme l’hameçonnage. Il peut être extrêmement utile pour les utilisateurs infectés avec l’utilisation d’exploits de navigateur Web, abusant de la confiance de l’application piratée.
Preuve:
Demande:
GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q-0.9,image/avif,image/webp,image/apng,*/*;q-0.8,application/signed-exchange;v=b3;q=0.9
Référent: http://192.168.140.129/index.php?page=register
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connexion: proche
Réponse avec le point d’exécution:
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:25:52 GMT
Serveur: Apache/2.4.6 (CentOS) HTML/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: sans magasin, sans cache, must-revalidate, post-check-0, pré-check-0
Pragma: sans cache
Connexion: proche
Type de contenu: texte/html; charset-UTF-8
Contenu-Longueur: 15252<html>
<head>
<title>Système de chat interne</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
<a href="/">
<img src="ey-logo.png" height="72" alt="EY">
</a>
<div style="margin-top:50px;">
<nav>
<a href="/index.php?page=messages">mes messages</a>
<a class="active" href="/index.php?page=new_message">Envoyer un message</a>
<a href="/index.php?logout">Logout</a>
</nav>
</div>
<div style="margin-top:20px;">
<div class='message_success'>Message envoyé</div>
<form target="_self">
<div class="container">
<h1>Envoyer un nouveau message</h1>
<p>S’il vous plaît sélectionner l’utilisateur et fournir du texte de message</p>
<hr>
<label for="login"><b>Utilisateur</b></label>
<select type="text" name="login" id="login" required="">
<option value="1">admin
<option value="2">utilisateur
<option value="4">prrrsihv Prrrsihv
<option value="5">0
<option value="6">0
<option value="7">0
<option value="8">0
<option value="9">test »
<option value="10">ykq1o3wmfv
[...]
value="14">testgl11i"> <script>alert(1)</script> y9e06
<option
[…]</select></div></form></div></div></body></html>
Recommandation : Il
est fortement recommandé d’incorporer à la fois des règles strictes d’assainissement des entrées et des enquêtes sur les sorties. Les caractères spéciaux HTML comme '<' and="" '="">' doent être html-encodés (remplacés par '<' and="" '="">' respectivement) dans toutes les données lues à partir des entrées, bases de données et fichiers de l’utilisateur.</'> </'> Les mêmes avantages pour les personnages comme " (qui devrait être remplacé par « ) et ' (qui devrait être échappé avec un signe de réaction ). En tournant, l’assainissement strict des entrées signifie une approche différente pour la validation des entrées. Par instance, si une variable est tenue de tenir un numéro, il est préférable de vérifier s’il s’agit en fait d’un numéro (comme s’il s’agit d’une expression régulière ou d’une distribution d’entier) au lieu d’essayer de comprendre tous les mauvais caractères possibles à filtrer. La validation d’entrée qui se produit à la fois sur le côté serveur et sur le côté client est obligatoire. La validation sur le côté client ( HTML/JavaScript, navigateur Web, qui est contrôlé par l’utilisateur) prévente DOM basé cross site scripting de se produit. La validation sur le site serveur prévente à partir de la norme (non-DOM) Cross-Site Scripting. Si la sécurité se lie uniquement sur la validation côté client, il n’est pas difficile pour l’attaquant de créer une interface alternative et d’envoyer des données maliciely artisanales au serveur, réussissant à détacher une telle sorte de mécanisme. Il est toujours nécessaire d’implémenter une validation d’entrée stricte sur le côté serveur et le côté client en effet. Si une variable fournie par un utilisateur est écrite à la base de données/fichier, puis affichée à d’autres utilisateurs, une telle vulnérabilité devient un XSS stocké, ce qui est beaucoup plus dangereux car il peut être utilisé contre les utilisateurs authentiques sans aucune action prise sur leur côté. Aussi en utilisant l’échelle d’une attaque XSS stockée est plus étrange que dans le cas d’un réflecté.
Références:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md
4. Détachement d’autorisation
Score CVSSv3: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity: High
Trouver:
Il a été révélé que l’application a une mise en œuvre d’autorisation pauvres. Un utilisateur qui connaît le chemin direct vers la ressource ou une URL pour appeler une fonction particulière, peut y accéder sans avoir une subvention de rôle approprié. Le contournement d’autorisation permet d’exécuter certaines actions sans avoir l’autorisation de le faire. Par exemple, un utilisateur non autorisé peut être enable pour exécuter des fonctions administratives comme l’ajout d’un autre utilisateur administrateur.
Preuve:
En utilisant l’url directe pour le message que toute personne peut lire un message qui ne lui appartient pas en changeant simplement l’id de message sur l’url beuglée: http://192.168.140.129/index.php?page=messages&message1
Recommandation:
Chaque demande de ressource ou de fonction doit être vérifiée à juste titre si l’utilisateur qui a pris cette action a les autorisations nécessaires. L’implémentation de mécanisme comme ACL (Access Control List) avec des éléments par URL/module/fonction et une politique DENY par défaut est fortement recommandée.
Références:
CWE-285
http://cwe.mitre.org/data/definitions/285.html
OWASP
https://www.owasp.org/index.php/Broken_Access_Control
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md
5. Crédits d’utilisateur par défaut ou facilement guessables
Score CVSSv3: 8.6
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Severity: High
Trouver:
Les credentiels utilisateur par défaut ou facilement devinables sont très dangereux pour la sécurité des applications. Un attaquant sans effort peut accéder à la section privée de l’application. Le mot de passe Devined/cracked peut être utilisé pour se connecter à la section privée de l’application et pivoter les attaques vers les utilisateurs autorisés. Maintenant, un attaquant ont beaucoup plus de terrain pour exploiter l’application.
Preuve :
Pentester a trouvé un mot de passe petit dans l’application. En outre, l’application utilise une méthode de hachage md5 faible.
passe de hachage de connexion
admin d8578edf8458ce06fbc5bb76a58c5ca4 qwerty
utilisateur 7815696ecbf1c96e6894b779456d330e asdRecommandation : Tous
les mots de passe par défaut de l’application doivent être changés. L’application devrait également employer une politique de mot de passe forte.
Références:
OWASP
https://www.owasp.org/index.php/Insecure_Configuration_Management
6. Données sensibles envoyées sur le canal non crypté
Score CVSSv3: 7.5
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Gravité: High
Trouver:
Cette vulnérabilité se produit lorsque des données sensibles sont envoyées sur le protocole HTTP qui n’implémente aucun chiffrement de données. Toutes les données qui sont envoyées sur ce canal est susceptible de renifler et d’apaiser.
Preuve :
Les mots de passe sont envoyés à l’aide d’un canal non crypté à l’aide d’une méthode dangereuse – obtenir le type de demande :
Demande à l’aide d’un utilisateur enregistré, envoyée via http:
GET /index.php? login-aaaa-psw-aaaa-psw-repeat-aaaa-page-register HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Référent: http://192.168.140.129/index.php?page=register
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connexion: procheDemande à l’aide de l’utilisateur de connexion, envoyée via http:
GET /index.php? connexion-test-test-page-login HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Référence: http://192.168.140.129/index.php?page=login
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connexion: procheRecommandation : Le
protocole HTTPS doit être mis en œuvre pour protéger les données sensibles. Veuillez également noter que lorsque le protocole HTTPS sera mis en œuvre, les cookies doivent être protégés avec le drapeau sécurisé. Cela prévente l’envoyer des cookies sur HTTP.
Références:
CWE-319
http://cwe.mitre.org/data/definitions/319.html
OWASP
https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md
7. Messages d’erreur Verbose
Score CVSSv3: 6.5
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/N
Severity: Medium
Trouver:
Au cours du test, il a été révélé que dans le cas de certaines demandes, le serveur lance une exception d’erreur. Le message d’exception peut contenir beaucoup d’informations techniques détaillées, y compris des nom de fichiers, des chemins absolus, mais aussi des bibliothèques, des classes et des méthodes utilisées. Cette information pourrait être cruciale pour se lancer dans d’autres attaques critiques (comme la lecture de fichiers arbitres, l’exécution de codes ou des attaques spécifiques à la plate-forme). Ces informations détaillées ne devraient être disponibles que pour les développeurs d’applications et les administrateurs système et ne devraient jamais être révélées à l’utilisateur fin.
Preuve:
Demande:
GET /index.php?login-admin'%20or%20'1'-psw-xyz-page=login HTTP/1.1
Hôte: 192.168.140.129
Mise à niveau-Insecure-Demandes: 1
Agent utilisateur: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ( HTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accepter : text/html,application/xhtml,application/q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Référence: http://192.168.140.129/index.php?page=login
Accepter-encoder: gzip, dégonfler
Langue d’acceptation : fr-PL,fr-q-0.9,fr-US;q-0.8,fr;q-0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connexion: procheRéponse:
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:13:52 GMT
Serveur: Apache/2.4.6 (CentOS) HTML/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: sans magasin, sans cache, must-revalidate, post-check-0, pré-check-0
Pragma: sans cache
Contenu-Longueur: 753
Connexion: proche
Type de contenu: texte/html; charset-UTF-8<html>
<head>
<title>Système de chat interne</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
<a href="/">
<img src="ey-logo.png" height="72" alt="EY">
</a>
<div style="margin-top:50px;">
<nav>
<a href="/index.php?page=messages">mes messages</a>
<a href="/index.php?page=new_message">Envoyer un message</a>
<a href="/index.php?logout">Logout</a>
</nav>
</div>
<div style="margin-top:20px;">
<br />
<b>Erreur fatale</b>: Appelez un membre de fonction fetch () sur un objet non dans <b>/var/www/html/login.php</b> en ligne <b>7</b><br /></div></div></body></html>
Recommandation : Les
erreurs verbose ne devraient pas être fournies aux utilisateurs finaux. Des pages d’erreurs statiques amicales devraient être fournies à la place. Erreur de cause doit être enquêtée dans le code.
Références:
OWASP
https://www.owasp.org/index.php/Information_Leakage
CWE-209
http://cwe.mitre.org/data/definitions/209.html
CWE-200: Information Exposure
http://cwe.mitre.org/data/definitions/200.html
Kingdom: Environment
http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md
8. Divulgation d’informations
Score CVSSv3: 5.3
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Gravité: Faible
Trouver:
La divulgation d’informations sur la vulnérabilité se produit lorsque des informations sensibles sont divulguées de quelque façon que ce soit par l’application. Par exemple, la configuration du serveur ou de l’application est exposée. La gravité de ce problème se détend sur les informations qui sont fuite.
Preuve :
Les fichiers ci-dessous ne devraient pas être accessibles au public :http://192.168.140.129/info.php
http://192.168.140.129/adminer.php
Disque de serveur et de version dans l’en-tête:Serveur: Apache/2.4.6 (CentOS) HTML/5.4.16
Utilisé logiciel et divulgation de version dansle cookie: Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version =4.7.8
Recommandation : Toute
information supplémentaire ne devrait pas être fuite. Informations seulement selon lesquelles l’utilisateur doit être disponible/fourni.
Références:
CWE-200
http://cwe.mitre.org/data/definitions/200.html
OWASP
https://www.owasp.org/index.php/Information_Leakage
https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure
Partie 2 – Mises en garde à « EY GDS Poland Cybersecurity Challenge via Challenge Rocket »
Parfois, dans le cadre de l’élargissement des connaissances et des compétences, je participe à toutes sortes de cours, de formations et de défis liés à la sécurité. L’un d’eux était le « EY GDS Poland Cybersecurity Challenge » organisé sur la plate-forme https://challengerocket.com/ey-cybersecurity-challenge/ . Selon la description, il s’est fié à la réalisation d’un audit de sécurité – citant les organisateurs de « Linux et le portail Web ». Ensuite, un rapport devrait être établi sur la base de ses résultats. Il contient une description des vulnérabilités constatées qui menacent la sécurité du système et des recommandations sur la façon d’améliorer le niveau global de sécurité. Il a été souligné que la notification doit être brève, concise et contenir une brève description des lacunes et des preuves de leur existence. On peut donc dire que tout devait se faire selon la procédure standard d’essais pénétrateurs.
L’image réelle du concours et l’approche des organisateurs à l’égard de la question de l’explication des doutes qui y sont liés m’ont surpris de manière peu positive. Mon rapport a été évalué à 0 points, sous-cotation, citant les jurés « les résultats du scanner ne sont pas un rapport pentecôtique. »
Il s’agit d’une évaluation blessante pour moi, et j’ai essayé de clarifier la question plus en détail (la cause probable au point 6 des objections), mais, en bref, en dehors des courriels hebdomadaires (pendant près d’un mois), le type – « un jour, nous pourrons y répondre, » je n’ai pas obtenu d’explication.
D’où cette entrée, dans laquelle je partage le rapport de la « direction du pays » et mes réserves quant à son organisation et à sa forme de mise en œuvre. Les manquements se sont un peu retrouvés.
Malgré tout, j’espère que mes mauvaises expériences sont le résultat d’une « série d’événements malheureux » plutôt que d’un manque de bonne volonté. Je ferme les objections sous forme de liste et j’espère qu’elles serviront le cycle de William Edwards Deming:
- Tout le plaisir était limité dans le temps – 2h. Je pense que c’est beaucoup trop peu de temps pour effectuer deux tests de pénétration et préparer un rapport complet sur la base de ces tests.
- Pour participer à la direction du réseau, il fallait télécharger et monter une image de deux machines virtuelles (en utilisant le temps disponible de 2h). Ce n’est pas toujours possible pour des raisons techniques prosaïques. Il serait plus facile, à mon avis, pour les participants si l’accès aux machines était possible à l’aide de LA VPN et que les participants n’avaient pas à les configurer de leur côté.
- La restriction de 2h aurait pu être malhonnêtement omise – accéder aux tâches en créant un compte pour de fausses données. Le seul point de protection contre cela était l’inscription dans les règles: « 4. Un participant peut s’inscrire à la compétition et prendre les tâches de compétition uniquement une fois. Après avoir commencé le test, le participant doit le compléter dans le délai donné. Une fois le test terminé, il ne sera pas possible de le reprendre. Les participants qui essaieront de s’inscrire à la compétition à partir de plusieurs comptes et de passer le test plus que jamais seront disqualifiés. » La plate-forme ne se protège pas contre de telles activités. C’est comme dire qu’il n’est pas nécessaire de créer des applications sécurisées, car leur piratage est illégal.
- Les mots de passe d’accès à l’une des machines n’ont pas fonctionné/ont été mal indiqués. Après l’avoir signalé, j’ai reçu cette réponse: « En ce qui concerne l’accès à la machine – peut-être que vous avez utilisé les données incorrectes d’une manière inappropriée. Il y a une machine très différente et beaucoup plus accessible qu’une autre. Je ne suis pas en mesure de dire la justesse de cette opinion. J’ai suivi les étapes indiquées dans le manuel et j’ai essayé d’utiliser les mots de passe qui y sont indiqués. J’ai obtenu des informations d’autres participants qu’ils ont également reçu des « crayons » n’a pas fonctionné. L’accès à la machine aurait pu être obtenu d’une autre manière – via le service FTP. Dans ce cas seulement, pourquoi une instruction trompeuse?
- Le « portail Web » était cousu avec un script qui contactait un serveur Internet externe surnommé « ey-logger ». C’était une situation si étrange qu’il s’appelait au moment de l’inscription sur le « portail Web » et lui envoyait la connexion et le mot de passe utilisés. En outre, ce faisant, il a accédé à l’adresse IP des personnes impliquées dans le jeu. Quelqu’un at-il cousu un keylogger malveillant dans l’application? J’ai évalué cette question comme un vestige après les tests qui s’y sont retrouvés par hasard. Cependant, l’organisateur a déclaré qu’il était là exprès, cependant: « en revanche, sur la question du script – ce n’est pas un script de test, et délibérément un « bizarre » prospectifs script avec la vulnérabilité XSS-Persistance (qui est l’une des failles de sécurité à détecter. L’adresse n’est pas pour le serveur EY, mais seulement pour un rasoir insignifiant et non fonctionnen à Azur. »
- Une fois le test de pénétration terminé et en cliquant sur le champ avec la transition vers l’ajout du rapport, il s’est avéré que cela ne pouvait être fait que dans la fenêtre d’accueil du texte propre, sans aucune mise en forme. Le rapport final était donc dépourvu de lisibilité et de possibilité d’inclure des graphiques. Je pense que c’est là que l’évaluation erronée de mon rapport en tant que « résultat du scanner » apu être réalisée. Je n’ai pas tout à fait expliqué cela, car, comme je l’ai rappelé, je n’ai pas obtenu de réponse de fond depuis un mois.
- L’organisateur n’a pas publié les résultats du défi à temps réglementaire. Après avoir dépassé le délai réglementaire et demandé quand les résultats arriveraient, il a subrepticement modifié les dates dans le contenu du règlement:
8. L’organisateur a révélé les noms des participants, malgré l’inscription dans les règles de procédure que cela n’arriverait pas – « 4. Les résultats détenus par les participants à la compétition seront publiés après la fin de la compétition sans publier les noms et surnames des participants. Est-ce une violation du GDPR?
