Discussion :

[Olivier Famien]

Des clés secrètes pour Uber, AWS et d’autres entreprises exposées dans de nombreuses applications Android
après la réalisation d’ingénierie inverse

Pour analyser le code source des applications compilées, les développeurs ont généralement recours à l’ingénierie inverse si le code n’est pas directement disponible. Cette méthode, bien que décriée par certains, permet de reconstituer le code source d’un programme compilé afin de l’analyser plus en profondeur. Spécialisée dans la sécurité des API et des technologies cloud, l’entreprise Fallible examine couramment pour le compte de ses clients le code source des applications Android en appliquant cette méthode.

Depuis novembre dernier, l’entreprise Fallible a décidé d’automatiser cette tâche eu égard aux sollicitations qui se sont faites croissantes. Pour cela, elle a conçu et mis en ligne un outil permettant de faire de l’ingénierie inverse sur n’importe quelle application Android. Quelques mois après la publication de cet outil sur la toile, les utilisateurs s’en sont servis pour réaliser de l’ingénierie inverse sur environ 16 000 applications.

En examinant le code de ces applications, plusieurs découvertes ont été effectuées. Sur les 16 000 applications examinées, environ 2 500 ont soit une clé soit une clé secrète de service tiers codée en dur dans l’application. Par ailleurs, même s’il est normal pour les applications d’intégrer des clés comme par exemple la clé de l’API Google pour utiliser les services de l’entreprise, les développeurs de l’entreprise ont découvert la présence de nombreuses clés secrètes d’API qui n’avaient finalement pas leur place dans ces applications.

Selon Fallible, ces clés secrètes appartiennent à divers services tiers comme celui d’Uber qui peut être utilisé pour envoyer une notification à partir de l’application Uber. À côté d’Uber, les ingénieurs ont également découvert des clés secrètes d’Amazon Web Service (AWS) également codées en dur dans les applications. Et le plus intrigant, selon Fallible, est que certaines de ces clés secrètes avaient des privilèges complets pour créer ou supprimer des instances.

Pour donner une idée des clés secrètes trouvées dans ces applications, Fallible a publié la liste ci-dessous.

Généralement, les propriétaires des applications ne souhaitent pas que l’on réalise de l’ingénierie inverse sur leurs applications au risque de trouver des choses que l’on ne souhaite pas faire connaître au public. Et c’est ce qui a certainement poussé Mary Ann Davidson, la directrice de la sécurité d’Oracle, à affirmer il y a quelques années qu'un client n’a pas le droit d’appliquer l’ingénierie inverse sur ses produits. Et même s’il trouvait des failles dans le code source d’un produit Oracle en appliquant cette méthode, il lui sera simplement rappelé en guise de remerciement que « le client ne saurait faire du reverse engineering, désassembler, décompiler ou alors tenter de dériver le code source des programmes... », tout en insistant sur le fait qu’il devra détruire les résultats de cette ingénierie inversée et confirmer qu’il l’a fait.

Bien entendu, si Fallible a pu découvrir de nombreuses clés ou jetons d’API et clés secrètes dans ces applications il est clair qu’elles peuvent se retrouver dans n’importe quel produit. Pour inciter à de bonnes pratiques, Fallible recommande aux développeurs de bien réfléchir avant de coder en dur les jetons et clés d’API dans les applications.

Aux services tiers, l’entreprise leur recommande de préconiser aux développeurs de ne pas mettre de clés secrètes directement dans les applications, mais plutôt de créer plusieurs clés secrètes d’API avec différentes portées.

Source : Hackernoon

Et vous ?

Qu’en pensez-vous ?

Voir aussi

« Vous n'avez pas le droit d'appliquer le reverse engineering sur notre code », le coup de gueule de la directrice de la sécurité d'Oracle

La Rubrique Sécurité, Forum Sécurité, Cours et tutoriels Sécurité, FAQ Sécurité

[Thorna]

Hum, voyons... La clef secrète, ce n'est pas celle qui doit rester... secrète ? Soigneusement planquée sur le serveur, disponible pour personne ? Alors que celle qu'on donne à tout le monde, c'est la clef publique ?
J'aimerais biren qu'on m'explique pourquoi une appli, qui cause à un serveur, a besoin d'une clef secrète ! Elle utilise la clef publique du serveur pour lui envoyer en toute sécurité ce qu'elle veut, non ? Et si le serveur veut renvoyer en échange des trucs sans qu'on le sache, l'appli lui file discrètement une clef symétrique et le tour est joué.
Je vois que les spécialistes en sécurité sont toujours aussi présents dans les applis du monde internet et mobile, ça fait plaisir de savoir que nos données personnelles, nos messages et nos petits secrets sont toujours et de mieux en mieux protégés.

[youtpout978]

J'accède à une api externe et pour cela j'ai besoin d'une clé unique qui m'est attribué et qui ne change pas, malheureusement le seul moyen de cacher cette clé est de créer ma propre api qui elle encapsule cette clé, dont ça engage des coûts si je ne veux pas stocker directement la clé dans l'application ...

[Tagashy]

en gros si j'ai bien compris, Faillible a juste mis en ligne un decompilateur java (enfin avec une ou deux étapes supplémentaire mais en 5 minute n'importe quel novice peut récupérer le code source d'une appli android (a l’exception du native code)) comme il en existe depuis des années YOUPI ...
@Thorna je pense qu'il s'agit de clé juste pour accéder a L’API comme c'est le cas pour les API payante (je pense au lecteur vidéo de wakanim par exemple ou la clé est coder en dur mais sur le serveur) par contre des clé AWS WTF

[Squisqui]

J'accède à une api externe et pour cela j'ai besoin d'une clé unique qui m'est attribué et qui ne change pas, malheureusement le seul moyen de cacher cette clé est de créer ma propre api qui elle encapsule cette clé, dont ça engage des coûts si je ne veux pas stocker directement la clé dans l'application ...

C'est ce qu'on appelle "prioriser". Si la sécurité n'est pas une priorité pour toi, alors ne protège pas ta clé, c'est aussi simple que ça.

[youtpout978]

C'est ce qu'on appelle "prioriser". Si la sécurité n'est pas une priorité pour toi, alors ne protège pas ta clé, c'est aussi simple que ça.

Disons que tant que mon application n'est que sur Windows Phone ça va, mais dès que je vais la sortir sur Android, là je serais obligé de mettre la clé ailleurs vu comme il est facile d'accéder au code d'une application Android, la meilleure solution reste de créer mon propre service mais suivant le taux d'adoption il me faudra une infra qui tiennent le choc.

[yapiti]

Sinon on peut aussi offusquer ses clés privé pour décourager les hackers.
Pour moi le plus efficace serait de stocker en dur sa clé, chiffrée, dans une lib native => https://www.androidsecurity.info/201...on-in-the-ndk/ (et de la déchiffrer dans la lib native)

[hotcryx]

C'est ce qu'on appelle "prioriser". Si la sécurité n'est pas une priorité pour toi, alors ne protège pas ta clé, c'est aussi simple que ça.

Prioritiser, tu veux dire?

[marsupial]

Par les temps qui courent, la sécurité devraient être loin du cadet des soucis de quiconque. Moi pas (vouloir) comprendre.

[Aiekick]

Quand ils nous parles de clef secrete c'est quoi par exemple ? parce que pour les application android, des qu'on veut un service comme une regie pub, un service d'analyse de bug, de reporting etc, on a des clef d'acces aux api qui sont codés en dur dans le soft..si c'est de ca qu'on parle je vois pas bien ce qu'on peut y faire.

J'aimerais bien qu'on m'explique pourquoi une appli, qui cause à un serveur, a besoin d'une clef secrète ! Elle utilise la clef publique du serveur pour lui envoyer en toute sécurité ce qu'elle veut, non ? Et si le serveur veut renvoyer en échange des trucs sans qu'on le sache, l'appli lui file discrètement une clef symétrique et le tour est joué.

Je ne comprends pas, ta clef symmetrique serait codé en dur dans l'app, c'est pas le meme probleme ?

[marsupial]

Sinon on peut aussi obfusquer ses clés privé pour décourager les hackers.
Pour moi le plus efficace serait de stocker en dur sa clé, chiffrée, dans une lib native => https://www.androidsecurity.info/201...on-in-the-ndk/ (et de la déchiffrer dans la lib native)

MIAMM

[derderder]

Disons que tant que mon application n'est que sur Windows Phone ça va, mais dès que je vais la sortir sur Android, là je serais obligé de mettre la clé ailleurs vu comme il est facile d'accéder au code d'une application Android, la meilleure solution reste de créer mon propre service mais suivant le taux d'adoption il me faudra une infra qui tiennent le choc.

Il est tout aussi facile d'acceder au code d'une appli sous Windows Phone, ou iOS ou que n'importe quel logiciel client.

[derderder]

Sinon on peut aussi offusquer ses clés privé pour décourager les hackers.
Pour moi le plus efficace serait de stocker en dur sa clé, chiffrée, dans une lib native => https://www.androidsecurity.info/201...on-in-the-ndk/ (et de la déchiffrer dans la lib native)

Le hacker va bien rigoler...

Si non chiffré:
strings libfoo.so et voilà une belle clé...

Si chiffré:

Afficher les functions de la bibliotheque native de l'appli:
arm-linux-androideabi-nm libfoo.so
La on repere les function appellés depuis java, vu leur nom franchement pas dur, ainsi que les functions de la bibliothèque de chiffrement utilisé, si c'est une bibliotheque perso il rigole encore plus et va attaquer le site de l'entreprise... puis on désassemble tout ça:

arm-linux-androideabi-objdump -d libfoo.so

On repere la function utilisé et l'adresse de la constante, puis objdump -s -j .rodata libfoo.so pour dump la table des constantes, on déchiffre la clé et enjoy, si un hacker met plus de 1/4h pour faire ça je lui conseille de changer de voie, il parait que McDo embauche.

Stockez votre clé sur un serveur point.

[Tagashy]

yapiti stocker ça clé comme ça n'est pas une solution.
un petit coup de gdb(ou equivalent android) ou un dump de la mémoire a l’exécution et ta clé est récupéré et même en statique ça peut devenir encore plus drôle le gas récupère ta lib native regarde les fonctions dedans puis refait une appli avec ta lib et fait un echo(get_private_key()) (ou la fonction qui l'appele) et boom ta clé a leak
tout ce que ca protège c'est d'un script kiddy qui tente de décompiler sur le web
la seule solution correcte niveau secu est celle proposer par youtpout978 et te faire une api pour communiquer avec les serveur qui est stockée sur un serveur sous ton contrôle (et pas donner la cle au client via une requette faire une vrai api sinon même chose que pour la lib native il exec jusqu'à la clé et la print)

bref la regle est de toujours considéré l'utilisateur comme un ***** voulant te degomer tout ce qu'il peut

P:S ah bas derderder est plus rapide que moi

[marsupial]

La première chose à faire suite à un hack, sécuriser la base de mots de passe... sur le serveur. Ensuite crypter les communications et "vacciner" le réseau par une empreinte matérielle.
C'est-à-dire ( i.e.), générer une base d'id matériels, y compris les lecteurs usb connectables, complète. Authentification automatique lors du login par une vérification d'aucun intrus par une routine furtive.
Créer un OS tout aussi furtif, Thèbes en l'occurrence, protégé par un colosse de Rhodes en cas de tentative d'attaque.

Lors du hack, isoler les serveurs aussi vite que possible en coupant le réseau.

J'en passe et des meilleurs. Quasi impossible à faire en Microsoft car moins fin et surtout fermé. Mais nous l'avons fait aussi.

Générer un script d'install pour déployer aussi vite que possible.
Et lorsque c'est fait, créer une IA
Observer des écrans de paquets c'est hyper fastidieux

S'il vous reste du temps à tuer, faciliter le travail des administrateurs en créant une interface de gestion.

En sécurité la deadline dépend du résultat pas du temps.

Bonne année à tous !

Un CEO heureux

[youtpout978]

Sinon on peut aussi offusquer ses clés privé pour décourager les hackers.
Pour moi le plus efficace serait de stocker en dur sa clé, chiffrée, dans une lib native => https://www.androidsecurity.info/201...on-in-the-ndk/ (et de la déchiffrer dans la lib native)

Si on utilise Xamarin normalement c'est du natif sur android donc la clé devrait être autant offusquée ?

Il est tout aussi facile d'acceder au code d'une appli sous Windows Phone, ou iOS ou que n'importe quel logiciel client.

Je n'ai pas compris comment tu peux accéder au code, surtout que je crois sur les dernières version de WP les Xap sont cryptés de A à Z.

J'envisageai de faire une API sur Azure mais vu les coûts et prendre un serveur dédié ou autre risque de me coûter assez chère (A cause des licences MS, c'est ça de faire du .Net ).