$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. Durée de vie trop longue. Une année entière, c'est beaucoup. Si le cookie est piraté avec succès, un accès long au compte utilisateur par l'attaquant est possible.
2. Drapeau httpOnly manquant. S'il est défini sur TRUE, les cookies ne seront accessibles que via le protocole HTTP. Autrement dit, les cookies dans ce cas ne seront pas disponibles pour les langages de script comme JavaScript.
3. Aucun hachage de cookie.
4. Absence de définition du drapeau sécurisé. L'indicateur sécurisé indique qu'un cookie doit être envoyé par le client via une connexion HTTPS sécurisée. S'il est défini sur TRUE, le cookie du client sera envoyé au serveur uniquement si une connexion sécurisée est établie.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

La première question avec laquelle le questionnaire a rencontré les futurs stagiaires concerne les principales vulnérabilités du Web. La seule difficulté ici est la nécessité de les voir dans le code source en PHP. Cependant, personne n'a défini la tâche de «cacher les bogues».

Voici une liste des vulnérabilités qui peuvent être détectées dans cette liste par ordre de fréquence de leur détection:

Le hachage de mot de passe utilisant l'algorithme MD5 a été remarqué même par des candidats éloignés du Web. Cependant, il y avait aussi des nuances intéressantes, par exemple, de nombreux candidats ont utilisé des termes très incorrects, essayant de décrire les problèmes dans leurs propres mots. Les «vulnérabilités des algorithmes», les «fonctions à sens unique», «l'existence de collisions» et d'autres virages étranges sont entrés en bataille, après un examen plus approfondi, ils s'avèrent n'être rien de plus qu'un ensemble de grands mots qui ne révèlent pas l'essence. Bien sûr, nous sommes allés ici à une réunion et nous n'avons pas trouvé à redire à ces personnes qui se préparent à se lancer sur la voie de l'apprentissage de la sagesse de la sécurité de l'information. Pour obtenir une "compensation", il suffit de mentionner la menace, en cas de compromission de la base de données, les hachages md5 peuvent être triés par un attaquant dans un délai acceptable et des mots de passe (ou des chaînes équivalentes) peuvent être obtenus en texte clair. Et, bien sûr, beaucoup ont mentionné le manque de sel et de force brute basé sur l'utilisation de tables arc-en-ciel. Nous avons également perçu ces commentaires de façon positive, surtout si le répondant a expliqué pourquoi il s'agissait d'une menace.

Injection SQL potentielle. Il est difficile d'ajouter quelque chose; lors de l'appel à la base de données, la saisie de l'identifiant et du mot de passe par l'utilisateur est directement concaténée avec la demande. S'il est peu probable que vous puissiez manipuler la valeur du mot de passe à ce stade (un hachage en est extrait), l'introduction d'une injection dans le nom d'utilisateur ne sera pas difficile pour un attaquant potentiel.

Sortie d'informations de débogage inutiles conduisant à une attaque XSS. En lisant attentivement la liste, on pourrait prêter attention à l'appel d'écho, qui affiche la demande générée à la base de données dans les commentaires HTML sur la page. Bien entendu, une telle conclusion d'informations supplémentaires sur la page est complètement facultative et, très probablement, simplement oubliée par le développeur après avoir effectué les tests. Ces informations supplémentaires sont très bénéfiques pour l'attaquant et permettent une bien meilleure compréhension du fonctionnement de l'application. Cependant, malheureusement, ce n'est que la moitié du problème. Le fait est qu'un attaquant peut manipuler le contenu de la variable de requête, et que son contenu ne peut pas être filtré ou échappé avant d'être affiché à l'utilisateur - il existe une attaque XSS potentielle. Cependant, son exploitation peut s'avérer être encore un casse-tête en raison de la fonction strtoupper mal située. Le vecteur injecté par l'attaquant sera en majuscule, et si ce n'est pas un problème pour les balises HTML, Javascript est très offensé par un tel appel. Cela peut être facilement vérifié à l'aide de la console du navigateur.



Eh bien, au moins, apparemment, l'attaquant devra se tourner vers les soi-disant «attaques sans script» ou des techniques sophistiquées pour contourner le filtrage (dans ce cas, JSFUCK le ferait), donc le fait d'un risque de sécurité n'annule pas cela.

Une erreur dans la logique du mécanisme de gestion de session était la partie la plus intéressante de la tâche. Sa découverte a nécessité non seulement de lire la source ligne par ligne, mais aussi de comprendre la logique de l'ensemble du listing. On pouvait sentir que quelque chose n'allait pas en remarquant la configuration d'un cookie contenant l'ID utilisateur encodé en base64 dans le bloc Remember-me. Une analyse plus approfondie de la logique de ce mécanisme nous amène à la réflexion: «Il s'avère qu'un attaquant qui connaît ou passe par l'identifiant peut se connecter à n'importe quel compte sans entrer de nom d'utilisateur et de mot de passe?!». Oui, en effet, un attaquant peut générer indépendamment un utilisateur de cookie de son côté et lui attribuer toute valeur d'ID codée par base64. L'envoi d'une demande avec un tel cookie sans nom d'utilisateur et mot de passe déclencherait la fonction do_login et se connecterait au compte de quelqu'un d'autre.

La mention de ces 4 vulnérabilités dans la réponse des candidats a directement influencé leurs scores.

Cependant, beaucoup dépendait de la qualité de la réponse. Mentionner des moyens de rectifier la situation, des commentaires sur des facteurs supplémentaires affectant la faisabilité d'une attaque, l'utilisation des bons termes et la capacité de structurer vos pensées, des commentaires sur des faiblesses supplémentaires ou des menaces potentielles - tout cela nous a réchauffé le cœur et conduit à une augmentation de la note finale.

Dans le travail de l'auditeur doivent souvent faire face aux nouvelles technologies, et la capacité de les comprendre est très importante. En incluant cette question dans le questionnaire, nous avons supposé que la plupart des candidats avaient à peine entendu parler de la technologie des jetons JWT, à l'exception du nom. Par conséquent, cette question, tout d'abord, visait la capacité de rechercher et d'analyser des informations provenant de sources publiques. En conséquence, une personne qui a raté l'émission de Google à la demande de «JWT» et «vulnérabilité jwt» pourrait tirer les conclusions suivantes:

1. Ce jeton n'a pas d'algorithme de signature, donc un attaquant est en mesure de modifier tous les champs à l'intérieur du jeton, ce qui n'est pas supposé par le concept de jetons JWT.

2. Les champs à l'intérieur du jeton contiennent le mot de passe de l'utilisateur en texte clair, le stockage de ces informations dans le jeton est, au minimum, une mauvaise pratique. Dans la plupart des cas, vous pouvez refuser une telle décision et ainsi augmenter votre niveau de sécurité.

3. En se souvenant de l'absence de signature et de notre capacité à modifier les champs à l'intérieur du jeton, il est logique de supposer que la modification de la valeur de isAdmin peut augmenter nos privilèges en privilèges d'administrateur.

4. Une autre idée intéressante que peu de personnes ont mentionnée dans leur réponse concerne le fait même de la possibilité de transférer les entrées des utilisateurs dans les champs d'un jeton JWT. Dans une situation normale, un attaquant ne peut en aucune façon influencer les données du jeton, ce qui signifie que les développeurs peuvent souvent négliger l'introduction de vérifications supplémentaires dans le code des gestionnaires. Cela demande une idée simple: mais essayons de mener des attaques classiques non pas à travers les paramètres GET / POST, mais à travers les champs de jetons. Cela peut donner un bon résultat inattendu. Une telle approche créative avec la justification correcte de nos actions a été très appréciée par nous dans l'évaluation de cette question et d'autres.

De nombreux candidats dans leurs réponses ont organisé une brève explication de la façon dont le jeton JWT est structuré et où il est utilisé, c'était intéressant pour nous de lire, et pourtant, tout d'abord, nous avons évalué les aspects de la réponse concernant la sécurité.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

Considérons, dans l'ordre, quels sont les principaux problèmes visibles sur les requêtes données:

1) En effet, l’identifiant numérique de l’utilisateur «10012» étant observé dans la requête, la première étape consiste à vérifier s’il est possible de changer le mot de passe d’un autre utilisateur? Puis-je spécifier suffisamment l' identifiant de quelqu'un d'autre ?
Les vulnérabilités de la classe IDOR sont assez faciles à exploiter et présentent souvent une criticité élevée.

2) La demande de changement de mot de passe se produit par la méthode POST, le jeton CSRF n'est pas respecté et le type de contenu est «texte / simple». Il est possible de truquer une telle demande.

Par conséquent, pour changer le mot de passe de la victime, il suffit à l’attaquant de le convaincre de simplement visiter le lien «malveillant».

3) Dans les en-têtes de réponse, le serveur révèle la version du logiciel utilisé . Cela peut être appelé une vulnérabilité à la longue, mais il est préférable de masquer de telles bannières - les attaquants peuvent facilement y trouver des exploits connus d'un jour, plus la valeur du logiciel utilisé simplifie considérablement la planification d'autres attaques.

4) Nous serions très heureux de voir la phrase "Que se passera-t-il si nous changeons le format de données de JSON en XML ?"

Le fait est que les cadres modernes sont intelligents, omnivores et peuvent traiter des données dans différents formats. Et lors de l'analyse de XML, une vulnérabilité XXE dangereuse est souvent autorisée. Avec son aide, l'intrus peut "aller" sur le réseau interne, lire les fichiers de configuration du serveur et parfois exécuter RCE.

5) Je voulais également voir une remarque comme «Pourquoi la connaissance de l'ancien n'est-elle pas vérifiée lors du changement de mot de passe?»

Quant à la «variante n ° 2», elle contient un «piège» - les en-têtes CORS sont utilisés ici et le type de contenu de la demande est déjà défini sur «application / json».

L'erreur que la grande majorité des candidats a faite est la réponse du formulaire "-C'est l'astérisque dans Allow-Origin, ce qui signifie que vous pouvez envoyer des demandes depuis n'importe quel site!"

Non, tu ne peux pas. Tout d'abord, l'en-tête Allow-Credentials: True est manquant, ce qui signifie que le navigateur doit exécuter la demande «avec des cookies», de sorte que la demande serait anonyme, sans session. Et deuxièmement, même si un tel en-tête était présent, le navigateur interdirait toujours d'envoyer des cookies - simplement à cause de l'astérisque. Leur combinaison est interdite et le navigateur est ignoré.

L'objectif de la question était de déterminer la familiarité du stagiaire avec les techniques modernes (et pas si) pour mener des attaques MitM. Examinons les scénarios potentiels basés sur un vidage de trafic existant:

1) Usurpation ARP
L'usurpation ARP est le moyen le plus ancien et le plus simple de mettre en œuvre des attaques MitM. Elle consiste à envoyer une requête ARP gratuite à l'hôte A.

L'adresse IP de l'hôte B est l'adresse IP et notre adresse MAC est l'adresse MAC. Une telle demande vous permet de modifier la table ARP sur l'hôte A, le forçant à envoyer des demandes à notre appareil lorsque vous essayez de contacter l'hôte B. L'hôte B est généralement la passerelle par défaut.

Outils recommandés: bettercap, arpspoof

2) Usurpation LLMNR, NBNS
Link-Local Multicast Name Resolution et NetBIOS Name Service sont les protocoles utilisés pour résoudre les noms d'hôtes sur le réseau local. Contrairement au protocole DNS, il n'y a pas de serveur dédié qui stocke toutes les informations; à la place, la demande est diffusée à tous les hôtes du réseau, si le nom d'hôte dans la demande correspond au nom d'hôte du périphérique, il enverra une réponse.

Comme cela a été correctement noté dans la réponse, l'attaquant peut répondre à de telles demandes en envoyant son adresse IP dans la réponse, ce qui conduira à l'avenir à ce que la victime contacte l'appareil de l'attaquant, au lieu de l'appareil dont le nom d'hôte est apparu dans la demande. De plus, un attaquant peut demander l'authentification NTLM à la victime, ce qui oblige le périphérique victime à envoyer un hachage NTLM, qui peut ensuite être utilisé pour la force brute.

Outils recommandés: Répondeur

3) Usurpation de WPAD
L'usurpation WPAD peut être attribuée à un cas spécial d'usurpation LLMNR et NBNS. Le protocole Web Proxy Auto Discovery est utilisé pour configurer automatiquement un serveur proxy HTTP.

Le périphérique envoie une demande LLMNR / NBNS avec le nom d'hôte wpad, reçoit l'adresse IP correspondante et essaie d'accéder au fichier wpad.dat via HTTP, qui stocke des informations sur les paramètres du proxy.

En conséquence, l'attaquant peut effectuer une usurpation LLMNR / NBNS et fournir à la victime son fichier wpad.dat, par conséquent, tout le trafic HTTP et HTTPS passera par l'attaquant.

Outils recommandés: Répondeur, mitm6

4) Publicité du routeur
Comme vous pouvez le voir sur le vidage, il existe des périphériques avec IPv6 activé sur le réseau. Sur le réseau, vous pouvez essayer d'envoyer des messages à l'annonce du routeur IPv6 victime afin de changer la passerelle ou le serveur DNS par défaut.

Les messages d'annonce de routeur (RA) font partie du mécanisme SLAAC (Stateless Address Autoconfiguration), qui est nécessaire pour obtenir automatiquement des adresses IPv6 sur un réseau, sans utiliser de serveur DHCPv6 ou conjointement avec lui. Ceci est réalisé en envoyant périodiquement des messages RA de multidiffusion au routeur, qui contiennent l'adresse de passerelle par défaut, le préfixe de réseau, l'adresse du serveur DNS, le préfixe de domaine.

Outils recommandés: paquet brut

5) Usurpation DHCP
En outre, dans un vidage, les demandes de découverte DHCP du même périphérique sont répétées à certains intervalles. Vous pouvez tirer des conclusions sur l'absence d'un serveur DHCP dans ce réseau et répondre à la prochaine demande Discover en spécifiant la victime comme passerelle par défaut vers le périphérique.

Outils recommandés: Yersinia

6) Usurpation HSRP
De plus, les paquets HSRP peuvent être vus dans le vidage. Le protocole de redondance d'UC peut augmenter la disponibilité des routeurs qui agissent comme passerelle par défaut. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . Mais! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

Exemple

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . Mais. , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)