Divulgation d'informations
dans Squid Proxy

CVE-2025-62168 est une vulnérabilité de type Information Disclosure affectant le proxy HTTP Squid dans les versions antérieures à 7.2.

Lorsqu'une erreur HTTP est générée, certaines pages d'erreur de Squid peuvent inclure des informations sensibles non correctement nettoyées — comme des identifiants d'authentification, des jetons de session ou des données internes de la requête. Cette vulnérabilité est exploitable à distance sans aucune authentification préalable.

• Exposition d'identifiants HTTP (Basic Auth, Proxy-Authorization headers).
• Divulgation de tokens de session ou de paramètres d'authentification sensibles.
• Risque d'accès non autorisé aux services internes protégés par le proxy.
• Facilitation d'attaques secondaires — replay d'authentification, pivot vers le réseau interne.

Un attaquant distant peut provoquer des erreurs HTTP spécifiques via des requêtes malformées ou spécialement construites. Dans certaines configurations, Squid inclut alors des informations sensibles dans les pages d'erreur générées.

Aucune authentification préalable n'est nécessaire — l'attaque peut être réalisée via une simple interaction HTTP avec le proxy exposé, ce qui la rend particulièrement accessible à un large spectre d'attaquants.

• Mettre à jour vers Squid 7.2 ou une version supérieure corrigée.
• Désactiver l'option vulnérable en attendant la mise à jour (voir ci-dessous).
• Limiter l'accès au proxy — restreindre le port 3128 aux seules machines autorisées via pare-feu.
• Restreindre les ACL et les règles d'accès dans squid.conf.

Désactivation immédiate de l'option vulnérable :

# Ouvrir le fichier de configuration Squid
sudo nano /etc/squid/squid.conf

# Ajouter ou modifier la directive suivante
email_err_data off

# Redémarrer le service pour appliquer le changement
sudo systemctl restart squid

• Politique de mise à jour régulière — planifiez des mises à jour de sécurité mensuelles pour tous les services exposés, dont Squid.
• Segmenter le proxy dans une DMZ — hébergez Squid dans une zone réseau isolée pour limiter l'impact en cas de compromission. Consultez les guides LXC et Nginx.
• Supervision continue des logs — analysez régulièrement les logs d'accès Squid pour détecter des comportements anormaux (requêtes malformées, erreurs HTTP répétées).
• WAF ou IDS — déployez un pare-feu applicatif pour détecter et bloquer les requêtes anormales avant qu'elles atteignent Squid.

# Surveillance en temps réel des logs Squid
tail -f /var/log/squid/access.log
tail -f /var/log/squid/cache.log

# Rechercher les erreurs HTTP inhabituelles (potentielles tentatives d'exploitation)
grep -i "TCP_ERROR\|ERR_" /var/log/squid/access.log | tail -50

# Analyser les IPs générant le plus d'erreurs
grep -i "error" /var/log/squid/cache.log | awk '{print $3}' | sort | uniq -c | sort -rn | head

En cas de compromission suspectée :

• Analyser les logs pour identifier des requêtes suspectes et les IPs sources.
• Vérifier si des identifiants HTTP ont été exposés dans les réponses d'erreur.
• Forcer la rotation immédiate des mots de passe et tokens potentiellement exposés.
• Mettre à jour Squid vers la version corrigée et redémarrer le service.
• Effectuer un audit des accès aux services internes protégés par le proxy.