Trouver et valider les clés et secrets codés en dur

Les clés secrètes codées en dur sont une cible pratique pour les chasseurs de bug bounty et les attaquants. Elles sont faciles à repérer et peuvent donner un large accès à des données sensibles et à des privilèges élevés.

Les secrets codés en dur ont causé plusieurs brèches très médiatisées par le passé, dont les plus notables sont :

• MyCar : MyCar est un système de télématique pour véhicules. L'éditeur a laissé des identifiants codés en dur dans ses applications mobiles Android et iOS. Des dizaines de milliers de voitures se sont retrouvées vulnérables à des pirates, qui pouvaient les localiser, les identifier, les déverrouiller, démarrer le véhicule ou déclencher l'alarme.

• Uber : un employé d'Uber a publié des identifiants en clair dans du code source, ensuite posté sur Github. Un attaquant a trouvé ces identifiants intégrés sur GitHub, puis s'en est servi pour obtenir un accès privilégié aux instances Amazon AWS d'Uber. L'attaquant a ensuite exigé une rançon de 100k$, qu'Uber a bien payée. La brèche d'Uber a entraîné l'exposition des informations de 57 millions de clients, ainsi que d'environ 600 000 chauffeurs. Une fois l'affaire rendue publique, Uber a versé un règlement de 148M$ et a dû repousser son introduction en bourse.

• Uniguest : Uniguest fournit des bornes (PC, iMac, tablettes) disponibles dans les halls d'hôtel (et d'autres lieux). Les utilisateurs peuvent s'en servir pour des tâches simples, comme naviguer sur le web ou imprimer des cartes d'embarquement. Les identifiants d'API étaient codés en dur dans l'application et ont servi à extraire toutes les données de la base de données cloud d'Uniguest. Ces données comprenaient des identifiants d'administration, des mots de passe de routeurs et de BIOS, des clés de produit et diverses autres informations sensibles.

Les secrets codés en dur sont aussi couramment signalés par les chasseurs de bug bounty. Si vous consultez les différents programmes de bug bounty, vous trouverez de nombreux rapports divulgués pointant vers des clés codées en dur dans AndroidManifest.xml, Info.plist ou un fichier de ressources.

Selon les permissions et l'usage de la clé, ces vulnérabilités peuvent être récompensées jusqu'à 1k$. La sévérité va de l'élévation de privilèges à l'accès à des informations sensibles, en passant par la surfacturation ou le vol d'un service, ou encore une attaque par déni de service.

Comment trouver et valider les secrets ?

Les secrets peuvent être trouvés de manière statique ou dynamique. Une approche statique courante consiste à rechercher des motifs connus, par exemple des chaînes correspondant à l'expression régulière suivante AIza[0-9A-Za-z\\-_]{35} :

$ app8 egrep -r 'AIza[0-9A-Za-z\\-_]{35}' . 
Binary file ./resources.arsc correspondent
Binary file ./app.apk correspondent
Binary file ./classes.dex correspondent                                
./assets/google-services-desktop.json:          "current_key": "AIzaSy....................."

Vous trouverez dans ce dépôt l4yton/RegHex une liste d'expressions régulières à utiliser.

Comme toutes les clés d'API et tous les secrets ne sont pas mauvais ou dangereux, et que tous les résultats de motifs ne sont pas corrects, les clés doivent être vérifiées, et les permissions, rôles, scopes et restrictions (nous y reviendrons plus loin) doivent être énumérés et contrôlés. streaak a publié un dépôt streaak/keyhacks qui répertorie des commandes curl pour vérifier un large éventail de clés.

Voici quelques exemples pour des clés Firebase et des secrets Facebook :

$ curl -s -X POST --header "Authorization: key=AIzaS........." --header "Content-Type:application/json" 'https://fcm.googleapis.com/fcm/send' -d '{"registration_ids":["1"]}'
<HTML>
<HEAD>
<TITLE>INVALID_KEY_TYPE</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>INVALID_KEY_TYPE</H1>
<H2>Error 401</H2>
</BODY>
</HTML>

$ curl https://graph.facebook.com/oauth/access_token\?client_id\=51XXXX\&client_secret\=0cbd4XXXXX\&redirect_uri\=\&grant_type\=client_credentials
{"access_token":"5181XXXXXXXXXXXXXX","token_type":"bearer"}% 

Une fois une clé trouvée, la documentation de l'API doit être votre meilleure amie pour déterminer les permissions dont elle dispose et les types d'actions qu'elle permet. Prenons par exemple une application Facebook : vous pouvez alors utiliser l'endpoint https://graph.facebook.com/v8.0/{applicationId}/permissions pour lister les permissions :

$ curl "https://graph.facebook.com/v8.0/51XXXXXXXX/permissions?access_token=51XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
{"data":[{"permission":"email","status":"live"},{"permission":"pages_show_list","status":"live"},{"permission":"pages_messaging","status":"live"},{"permission":"groups_show_list","status":"live"},{"permission":"pages_read_engagement","status":"live"},{"permission":"public_profile","status":"live"}]}%   

Un autre outil adapté à la ligne de commande est detect-secret de Yelp : Yelp/detect-secrets. Cet outil détecte un sous-ensemble plus restreint de clés et implémente aussi la validation pour certaines d'entre elles.

Ostorlab automatise la recherche et la vérification des clés et des secrets, et couvre 53 types de secrets à la date de rédaction de cet article. Un agent de détection de secrets collecte les clés qui correspondent à des motifs, ou qui sont utilisées dynamiquement par des API précises, ou encore interceptées sur le réseau. L'agent vérifie ensuite ces clés pour confirmer leur validité, en parcourant tous les services connus.

Voici une capture d'écran montrant un exemple de confirmation d'une clé valide et du service correspondant**.

Rien que sur les 10 000 dernières applications scannées, nous avons signalé plus de 200 secrets valides donnant accès à des données hautement sensibles ou à des services critiques, comme le paiement ou le code source. Voici quelques statistiques sur le nombre de clés trouvées par service :

Comment y remédier ?

• L'intégration est acceptable, rien à faire : la plupart des services publient des bonnes pratiques d'utilisation de leur API ou de leur secret. Certaines API peuvent sans risque être intégrées dans une application. Firebase en est un exemple :

Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; 
that can only be done with Firebase Security Rules. 
Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); 
however, API keys for Firebase services are ok to include in code or checked-in config files.

• Des alternatives sont recommandées, je dois changer d'approche : certains services proposent des alternatives plus sûres à l'intégration d'identifiants (comme Amazon et Google, exemple tiré des recommandations d'AWS) :

You have a mobile app. Do not embed access keys with the app, even in encrypted storage. 
Instead, use Amazon Cognito to manage user identities in your app. This service lets you authenticate users using Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC)–compatible identity provider. 
You can then use the Amazon Cognito credentials provider to manage credentials that your app uses to make requests to AWS. For more information, see Using the Amazon Cognito Credentials Provider on the AWS Mobile Blog. 

• L'intégration est dangereuse, déléguez les actions au serveur : pour certains services, intégrer des clés revient à s'inviter à se faire pirater, voir par exemple la documentation de Stripe. Dans ces cas, c'est le serveur qui doit effectuer l'interaction avec le service.

Your secret API key can be used to make any API call on behalf of your account, such as creating charges or performing refunds. 
Treat your secret API key as you would any other password. Grant access only to those who need it. 
Ensure it is kept out of any version control system you may be using. 
Control access to your key using a password manager or secrets management service.

In live mode, new secret keys are only visible the first time you access them. 
After that, the Dashboard redacts the API key. When the key is revealed, you can leave a note on the Dashboard describing the location on your own systems where you’ve copied it. 
If you lose your secret key, you can’t recover it from the Dashboard and must roll the key or create another one.

• Durcissement par récupération distante des clés et épinglage des clés : pour les services qui ne proposent pas de service d'authentification par utilisateur et qui doivent être intégrés dans l'application, il est recommandé de récupérer la clé depuis le serveur. C'est aussi une bonne pratique de restreindre les permissions de la clé (principe du moindre privilège). Certains services offrent la possibilité d'épingler (PIN) les clés à une application ou à un nom de domaine. Cette protection n'étant pas parfaite, la rotation des clés est recommandée pour limiter l'exposition.