VulnHunter - Détection et analyse des vulnérabilités de sécurité

Une compétence d'audit de sécurité complète pour identifier les APIs dangereuses, les patterns footgun, les configurations sujettes aux erreurs et rechercher les variantes de vulnérabilités dans les bases de code. Inspirée par les méthodologies sharp-edges et variant-analysis de Trail of Bits.

Aperçu

VulnHunter combine deux puissantes techniques d'analyse de sécurité :

Détection des Sharp Edges - Identifier les APIs sujettes aux erreurs, les comportements par défaut dangereux et les conceptions footgun
Variant Analysis - Trouver des vulnérabilités similaires dans les bases de code en utilisant l'analyse basée sur les patterns

Quand utiliser VulnHunter

Activez cette compétence quand :

Vous menez des revues de code ou des audits de sécurité
Vous examinez les dépendances tierces pour détecter les patterns dangereux
Vous recherchez des variantes de vulnérabilités connues
Vous évaluez la conception d'une API pour détecter les footguns de sécurité
Vous faites une reconnaissance préalable audit d'une base de code inconnue

Détection des Sharp Edges

Catégories de Sharp Edges

1. Configurations dangereuses par défaut

Recherchez les configurations qui sont non sécurisées par défaut :

- CORS : Access-Control-Allow-Origin: *
- Modes de débogage activés en production
- Credentials ou clés API par défaut
- Permissions de fichiers permissives (777, 666)
- Vérification SSL/TLS désactivée
- Paramètres de désérialisation non sécurisés

2. APIs sujettes aux erreurs

Sécurité mémoire :

// Dangereux : pas de vérification de limites
strcpy(), strcat(), sprintf(), gets()
memcpy() sans validation de taille

// Alternatives plus sûres
strncpy(), strncat(), snprintf(), fgets()
memcpy_s() avec taille explicite

Footguns cryptographiques :

- Chiffrement en mode ECB
- MD5/SHA1 pour des fins de sécurité
- IVs ou salts en dur
- Implémentations cryptographiques personnalisées
- Aléatoire sans CSPRNG (Math.random pour les tokens)

Problèmes de concurrence :

- Race conditions dans les opérations de fichier
- Time-of-check to time-of-use (TOCTOU)
- Anti-patterns double-checked locking
- Opérations d'incrémentation/décrémentation non atomiques

3. Footguns spécifiques au langage

JavaScript/TypeScript :

// Patterns dangereux
eval(), new Function(), setTimeout(string)
innerHTML, outerHTML, document.write()
Object.assign() pour clone profond (shallow uniquement !)
== au lieu de === (coercition de type)

Python :

# Patterns dangereux
pickle.loads(untrusted)  # Vecteur RCE
yaml.load(untrusted)     # Utiliser safe_load
exec(), eval()
os.system(), subprocess avec shell=True

Rust :

// Patterns nécessitant un examen attentif
unsafe { }
.unwrap() dans le code de production
mem::transmute()
déréférence de pointeur brut

Solidity/Smart Contracts :

// Patterns à haut risque
tx.origin pour l'authentification  // Vulnérable au phishing
delegatecall vers untrusted        // Collision de storage
selfdestruct                        // Destruction permanente
block.timestamp pour l'aléatoire   // Manipulable par le miner

Liste de contrôle Sharp Edges

Lors de la revue de code, vérifiez systématiquement :

[ ] Contournements d'authentification - Vérifications d'auth manquantes, credentials par défaut
[ ] Flaws d'autorisation - Escalade de privilèges, patterns IDOR
[ ] Vecteurs d'injection - SQL, Command, Template, XSS
[ ] Faiblesses cryptographiques - Algorithmes faibles, gestion inadéquate des clés
[ ] Épuisement de ressources - Boucles non bornées, allocation mémoire
[ ] Race conditions - TOCTOU, modification d'état concurrent
[ ] Divulgation d'information - Erreurs bavards, endpoints de débogage
[ ] Désérialisation - Unmarshaling de données non fiables
[ ] Path traversal - Chemins de fichiers contrôlés par l'utilisateur
[ ] Vecteurs SSRF - URLs contrôlées par l'utilisateur, redirects

Variant Analysis

Le processus de chasse aux variantes

Identifier la cause racine - Comprendre POURQUOI la vulnérabilité existe
Extraire le pattern - Quelle structure de code l'active ?
Généraliser le pattern - Créer des patterns regex/AST
Rechercher dans la base de code - Chasser les structures similaires
Valider les résultats - Confirmer que chaque variante est exploitable

Templates d'extraction de pattern

Template 1 : Pattern de validation manquante

Bug original : entrée utilisateur se déplace vers requête SQL sans sanitisation
Pattern : [user_input] -> [sink_function] sans [validation_function]

Rechercher :
- Appels directs à la base de données avec concaténation de strings
- Méthodes raw query ORM avec paramètres utilisateur
- Flux de données similaires dans les modules adjacents

Template 2 : Contournement d'authentification

Bug original : endpoint sans middleware d'auth
Pattern : définition de route sans décorateur/middleware d'auth

Rechercher :
- Routes définies après celle vulnérable
- Patterns API similaires dans d'autres modules
- Endpoints admin/internes

Template 3 : Race condition

Bug original : check-then-act sans atomicité
Pattern : if (check_condition()) { act_on_condition() }

Rechercher :
- Vérifications d'existence de fichier suivies d'opérations de fichier
- Vérifications de permission suivies d'actions privilégiées
- Vérifications de solde suivies de transferts

Stratégies de recherche

Recherche basée sur Grep

# Trouver les injections SQL potentielles
grep -rn "execute.*%s" --include="*.py"
grep -rn "query.*\+" --include="*.js"

# Trouver les désérialisation dangereuses
grep -rn "pickle.loads\|yaml.load\|eval(" --include="*.py"

# Trouver les vecteurs d'injection de commande
grep -rn "os.system\|subprocess.*shell=True" --include="*.py"

Recherche sémantique (basée sur AST)

Pour un matching plus précis, utilisez les outils basés sur AST :

Semgrep - Semantic grep cross-language
CodeQL - Analyse sémantique de GitHub
tree-sitter - Parser universel

Template de rapport Variant Analysis

## Rapport Variant Analysis

### Résultat original
- **ID** : FINDING-001
- **Sévérité** : High
- **Cause racine** : [Description]
- **Fichier affecté** : path/to/file.ext:line

### Pattern extrait
[Code pattern ou regex]

### Variantes découvertes

| # | Localisation | Sévérité | Statut | Notes |
|---|--------------|----------|--------|-------|
| 1 | file.ext:42 | High | Confirmée | Même cause racine |
| 2 | other.ext:100 | Medium | Suspectée | Nécessite validation |

### Recommandations
[Approche de correction systématique]

Workflow

Phase 1 : Reconnaissance

Identifier la stack technologique et les langages
Cartographier les points d'entrée (APIs, CLI, entrées de fichier)
Localiser la logique d'authentification/autorisation
Trouver les opérations cryptographiques
Identifier les intégrations externes

Phase 2 : Scan Sharp Edges

Parcourir la liste de contrôle sharp edges
Se concentrer sur les chemins critiques de sécurité
Documenter tous les patterns suspects
Recouper avec les CVEs connus

Phase 3 : Chasse aux variantes

Pour chaque résultat, extraire le pattern
Rechercher les variantes systématiquement
Valider chaque variante potentielle
Évaluer le risque agrégé

Phase 4 : Reporting

Consolider les résultats par catégorie
Assigner des évaluations de sévérité
Fournir des conseils de remédiation
Mettre en évidence les problèmes systémiques

Intégration avec l'analyse statique

Règles Semgrep pour les patterns courants

# Exemple : détecter l'injection SQL en Python
rules:
  - id: sql-injection-format
    patterns:
      - pattern: $CURSOR.execute($QUERY % ...)
    message: "Injection SQL potentielle via formatage de string"
    severity: ERROR
    languages: [python]

Requêtes CodeQL

// Trouver les données taintées qui s'écoulent vers des sinks dangereux
import python
import semmle.python.dataflow.TaintTracking

from DataFlow::PathNode source, DataFlow::PathNode sink
where TaintTracking::localTaint(source.getNode(), sink.getNode())
  and sink.getNode().asExpr().(Call).getTarget().getName() = "execute"
select sink, source, sink, "Tainted input reaches SQL execution"

Exemples

Voir le dossier /examples pour :

Des exemples sharp edges réels par langage
Des études de cas de variant analysis
Des walkthroughs d'extraction de pattern

Ressources

resources/sharp-edges-catalog.md - Catalogue complet des patterns dangereux
resources/variant-patterns.md - Templates de patterns de vulnérabilités courants
templates/variant-report.md - Template de rapport pour variant analysis

Directives

Toujours vérifier - Ne signalez pas les problèmes théoriques comme des vulnérabilités confirmées
Le contexte importe - Un pattern peut être sûr dans un contexte, dangereux dans un autre
Priorité à l'exploitabilité - Concentrez-vous sur les patterns qui mènent à un impact réel
Documenter les hypothèses - Notez toute hypothèse de modèle de menace
Systémique plutôt que ponctuel - Recommandez des améliorations architecturales quand les patterns se répètent

Fichiers de compétence

vulnhunter/
├── SKILL.md                          # Ce fichier
├── resources/
│   ├── sharp-edges-catalog.md        # Patterns dangereux catégorisés
│   └── variant-patterns.md           # Templates de patterns de vulnérabilités
├── examples/
│   ├── smart-contracts/              # Exemples Solidity/blockchain
│   ├── web-apps/                     # Exemples d'applications web
│   └── native-code/                  # Exemples C/C++/Rust
├── templates/
│   └── variant-report.md             # Template de rapport d'analyse
└── docs/
    └── methodology.md                # Guide méthodologique détaillé

Vérifier

La cause racine est énoncée en une phrase et est soutenue par un artefact concret (stack trace, ligne de log, diff, sortie de profiler)
Le reproducer est minimal et s'exécute localement ; la commande exacte et la sortie observée sont capturées
Le fix a été vérifié en réexécutant le reproducer et montrant que la sortie qui échouait précédemment passe maintenant
Un test de régression (ou monitoring/alerte) a été ajouté pour que le même bug soit attrapé automatiquement la prochaine fois
Les chemins de code adjacents qui partagent le même mode d'échec ont été vérifiés, pas seulement le symptôme signalé
Si le fix touche la sécurité, les performances ou l'intégrité des données, le trade-off est nommé et quantifié