Maîtriser le durcissement des applications : une plongée approfondie dans les obscurcissements

Les obscurcissements et vous

Application security est un connu connu maintenant. Tout le monde sait qu’ils en ont besoin, et les attaquants savent comment vaincre les protections de base ; expédier une application non protégée n’est tout simplement pas une option. Toutes les protections fortes comportent deux parties : la prévention par analyse statique et la détection dynamique des attaques. L'analyse statique est un outil puissant qui donne aux attaquants un aperçu unique des détails de mise en œuvre spécifiques à une application. Il expose les parties les plus vulnérables d'une application, contribuant ainsi à accélérer une attaque ou à voler de précieuses adresses IP professionnelles. Le code source, ainsi que les données, obfuscation est un élément important de toute protection contre l’analyse statique. Voici quelques façons dont le code et les données peuvent être transformés pour ralentir les acteurs malveillants. Plus ils doivent travailler dur, plus safer notre monde peut être.

Privatisez votre protection

Même si les applications ne doivent pas être livrées sans une certaine forme d’obscurcissement, toutes les obscurcissements ne sont pas créés égaux. Deux éléments cruciaux pour tout obscurcissement puissant sont l’adresse IP privée et la randomisation. Les obfuscateurs open source actuellement disponibles peuvent être tout aussi utiles aux attaquants qu’aux développeurs d’applications. Le niveau de protection fourni par ces obfuscateurs open source n'est pas assez puissant pour sécuriser de manière fiable les applications de qualité entreprise. Les obscurcissements percutants doivent transformer le code source en quelque chose d'illisible par les humains et irréversible par les outils d'attaque automatisés. Les techniques d’obscurcissement accessibles au public fonctionnent comme leur propre pierre de Rosette pour les vaincre. L'utilisation de techniques d'obfuscation personnalisées et non accessibles au public empêche Timmy Turner d'inverser l'obscurcissement d'une application à l'aide de ses Generative AI Fairies. Associez ces algorithmes privés au caractère aléatoire inhérent pour garantir qu’aucun être humain, ou LLM, ne puisse démêler le fil.

PRNG contre-attaque

Les attaquants peuvent obtenir de nombreuses informations en comparant différents releases de la même application. Faire changer les obscurcissements entre les versions de l’application est une nécessité absolue. La plupart des moteurs de pseudo-randomisation utilisent une graine pour forcer la prévisibilité tout en conservant le caractère aléatoire inhérent, et les obscurcissements ne sont pas différents. Le simple fait d'augmenter ou de décrémenter une valeur de départ aura un impact considérable sur les obscurcissements appliqués à une application d'entrée. Cela donne une reproductibilité en cas de besoin, mais oblige les attaquants à recommencer lorsqu'ils inversent une application après la création d'une nouvelle version. released. C'est comme si l'agresseur pelletait la moitié de l'allée, prenait une pause pour prendre un chocolat chaud et revenait sur la neige fraîche. Une sécurité renforcée se concentre sur le gaspillage d'un ingénierie inverse du temps, et un paysage en constante évolution est l'une des meilleures façons de perdre leur temps.

Obscurcissement Obscurcissements Obscurcissements

Conceptuellement, l’obscurcissement est à l’opposé de l’optimisation. Tout comme les compilateurs ont souvent plusieurs passes d'optimisation, nous avons plusieurs passes d'obscurcissement. Cela signifie que nous appliquons l’obscurcissement aux obscurcissements qui viennent d’être ajoutés. Le résultat est incroyablement difficile à lire.

Des choses comme une simple instruction « ajouter » ou « déplacer » peuvent rapidement devenir une cinquantaine, voire des centaines d'instructions. Obscurcir correctement les appariements « adrp add » peut décimer la capacité d'un outil automatisé (comme ghidra ou IDA) à résoudre le flux de contrôle du programme. Des obscurcissements apparemment mineurs peuvent rendre presque impossible pour un attaquant de trouver le début, la fin ou le milieu de cet appel de fonction « acceptUserCredentials ». Des centaines d’obscurcissements complexes et variés laissent les attaquants potentiels tenter de comprendre comment le code s’exécute avec succès.

Bop-le, tourne-le, configure-le

Tous les appels de méthode ou de fonction ne sont pas sensibles dans une application, et certains appels de méthode ou de fonction peuvent être très sensibles aux performances. Bien qu’appliquer uniformément l’obscurcissement sur l’ensemble d’une application soit bien mieux que rien, cette stratégie peut avoir un impact considérable sur les performances d’exécution. Donner aux ingénieurs de sécurité la possibilité de masquer fortement les appels sensibles, tout en masquant légèrement les appels exigeants en performances, fait partie de la fourniture d'un outil de protection de classe mondiale. Toutes les protections dynamiques (Guards) injectées dans l’application nécessitent autant d’obscurcissement que le code source sous-jacent l’exige. L'application des mêmes techniques d'obscurcissement de haute sécurité à ces gardes actifs contribue à les maintenir protégés et opérationnels et ralentit les efforts des attaquants pour les identifier et les supprimer. La configurabilité est cruciale pour toute organisation centrée sur la sécurité, et les outils de protection doivent évoluer aussi rapidement que l'orientation de l'entreprise le peut. Comme mentionné précédemment, certaines obscurcissements sont construits différemment. Voici quelques concepts que propose tout moteur d’obscurcissement sérieux et comment il peut empêcher le trafic aérien non approuvé d’entrer.

Flux de contrôle calculé

Les attaquants peuvent acquérir de nombreuses connaissances sur une application simplement en examinant le flux d’appels de fonctions dans l’ensemble de l’application. Pour lutter contre cela, nos obscurcissements utilisent quelque chose appelé Computed Control Flow. Le flux de contrôle calculé empêche les décompilateurs de connecter les appels de fonction et les références d'étiquettes au point d'entrée principal des applications. Il s'agit d'un élément essentiel de toute protection de classe mondiale. Lorsqu'un décompilateur analyse un binaire, voir comment une fonction appelle une autre fonction est souvent trivial. Prenez, par exemple, des instructions telles que : `b.eq 0x10055bc42` et `bl 0x100abcdef`. Un décompilateur sait exactement ce qui se trouve dans ces emplacements de mémoire virtuelle. Dans le cas des deux instructions précédentes, il s'agit soit d'étiquettes au sein d'une fonction, soit d'un appel de fonction lui-même. Tout décompilateur digne de ce nom rendra une belle toile d'araignée d'appels de fonctions entrelacés, montrant un chemin d'exécution clair dans toute une application. Combinez cela avec d'autres astuces de base, comme voir où dans l'assembly un message « connexion réussie » est utilisé, et il devient trivial pour un attaquant d'identifier le code exploitable. Le flux de contrôle calculé est un ensemble d'opérations mathématiques injectées avant les appels évidents du flux de contrôle. Ces opérations mathématiques empêchent un décompilateur de connaître l'adresse virtuelle relative exacte vers laquelle accéder, détruisant ainsi sa capacité à générer un graphique de flux de contrôle.

Aplatissement du flux de contrôle

Computed Control Flow est déjà une terreur pour les décompilateurs ; ce serait certainement dommage si nous aggravions les choses. Une autre stratégie pour faire dérailler le flux de contrôle logique est appelée Control Flow Flattening. Nous avons différentes formes de CFF, mais une récemment ajoutée (nommée The Nexus) insuffle une nouvelle vie à cette technique d'obscurcissement critique. Nous avons tous déjà écrit un jeu d'échecs dans « main », mais que diriez-vous d'écrire une application complète de niveau production dans une seule instruction switch auto-référencée ? C’est exactement ce que fait le Nexus tout en donnant la priorité aux performances d’exécution. Il existe une multitude d'informations sur le CFF, son importance et son fonctionnement. Il est impossible de sous-estimer à quel point cette technique d’obscurcissement rend la vie des attaquants difficile, et aucune application ne devrait quitter la scène sans elle.

Hopup

Aucun ensemble de couteaux en acier inoxydable ne serait complet sans une paire de ciseaux en acier inoxydable assortie, et Chopup complète les obscurcissements du flux de contrôle de la même manière. Les formats de fichiers binaires sont généralement densément compactés pour économiser de l'espace sur le disque. Cela signifie que la plupart des appels de fonctions associés sont assez proches les uns des autres. En conséquence, un binaire désassemblé a tendance à regrouper les fonctions liées et a presque toujours des fonctions comme un bloc contigu dans le binaire. C'est beaucoup trop facile à lire et cela nous fait vraiment du mal. Chopup change cela. Il n'y a aucune restriction technique dans un binaire exigeant que les appels de fonction soient contigus en mémoire, et une bonne paire de ciseaux (avec de la colle flexible) peut laisser un binaire fonctionner comme prévu mais forcer les attaquants à sauter dans chaque coin du binaire à la recherche d'une logique. contrôler le flux.

mgDaea et réparation

Si l’obscurcissement du flux de code lui-même constitue une couche de protection cruciale, l’obscurcissement des données d’application sous-jacentes est tout aussi nécessaire. Les dommages et les réparations sont le mal chaotique et le bien légal des protections par analyse statique, et vont presque toujours de pair. Endommager une donnée, ou même dans certains cas, un morceau de code, puis le réparer juste avant sa lecture ou son exécution, rend l'analyse statique effectivement impossible. Damage transforme les données spécifiées en ce qui semble être de la mémoire poubelle. Lorsque ces mêmes données sont exposées à un appel de réparation, elles reviennent à leur forme d'origine plusieurs fois juste avant d'être utilisées. Ces données peuvent ensuite être à nouveau endommagées après être tombées hors de portée et ne seront utilisées qu'au prochain appel de la fonction. Cette clé API peut être « 1#&at0d$*nd@@z » dans le binaire pour commencer, mais rassurez-vous, elle sera corrigée avant d'être utilisée.

Renommer le symbole

Même avec l'obscurcissement du code source et l'obscurcissement des données, il reste encore des noms de symboles de code source dans un binaire compilé. Par exemple, un artefact de symbole pour un nom de fonction tel que « acceptContinuousPayment » peut facilement fournir un lien direct vers l'implémentation de cette fonction. Une fois trouvé, il est trivial de modifier l'assemblage et d'accéder à des fonctionnalités premium sans payer. Le renommage complet des symboles masque les artefacts restants et ne laisse rien aux attaquants avec lesquels travailler. La suppression de tout indice ou allusion à une fonctionnalité sensible dans un binaire protégé peut forcer les attaquants à abandonner complètement l'analyse statique.

La Fin

Ce ne sont là que des exemples de ce à quoi ressemblent de solides pratiques et méthodologies d’obscurcissement, et il ne s’agit en aucun cas d’une liste exhaustive. Laisser une application non protégée dans la nature donne à quiconque une visibilité complète sur une adresse IP unique et offre à tout attaquant une fenêtre sans brouillard sur la logique métier. Avec l’essor fulgurant de l’IA générative et des copilotes de code source dans le courant dominant, il est devenu infiniment plus facile pour les gens d’écrire du code, et pour certaines personnes d’inverser le code. Un engagement à l’échelle de l’organisation en faveur de la mise en œuvre de solutions de sécurité solides est la seule voie viable dans un environnement aussi dynamique. Ne laissez pas le travail acharné de votre développeur quitter la maison sans lui.

 

Lisez le point de vue d'IDC sur l'importance de obscurcissement et anti-falsification dans le cadre de votre DevSecOps entraine toi.