Pourquoi la défense contre l'obfuscation du système d'exploitation contre "C'est un système Unix!" pas largement mis en œuvre?
La scène Jurassic Park référencée dans le titre est tristement célèbre pour la façon dont elle sonne ridicule pour ceux qui sont alphabétisés en technologie. Mais cela illustre également ce qui me semble être un énorme trou dans la sécurité Web, en particulier les appareils IoT - dès que les attaquants découvrent qu'un serveur ou une caméra ou un babyphone fonctionne sous linux, ils connaissent instantanément des volumes sur son fonctionnement. Ils savent que les commandes comme Sudo sont de grosses cibles juteuses et ils savent que l'accès Shell apportera avec lui des tas d'outils utiles comme ls et cat.
Alors pourquoi l'obfuscation du système d'exploitation n'est-elle pas plus une chose? Je ne parle pas simplement de cacher la version dans les en-têtes Web. Semblable à la minification ou à l'obscurcissement JavaScript, je parle de changer les noms des binaires et des chemins de fichiers dans le système d'exploitation lui-même. Des classes d'attaques entières ne seraient-elles pas pratiquement inutiles si le système d'exploitation avait ha7TrUO et RRI6e29 commandes au lieu de Sudo et ls? Imaginez un pirate qui a en quelque sorte obtenu un accès root à distance - que vont-ils même faire s'ils ne connaissent aucune commande?
La mise en œuvre serait assez facile pour les compilateurs. Prenons le cas le plus simple de "renommer cette fonction et tous les appels à elle". Vous pourriez donner à un compilateur OS et à un compilateur d'application les mêmes noms aléatoires et ils pourraient se parler. Mais même si l'application a une sécurité médiocre et est vulnérable à l'injection bash, de telles attaques seraient vaines.
Évidemment, cette technique ne peut pas être utilisée dans tous les scénarios. Mis à part les scénarios tels que les serveurs gérés par des administrateurs système humains, il me semble que tout appareil ou serveur géré par automatisation est un candidat de choix pour cette défense.
Je suppose que la ou les questions doivent être un peu plus concrètes:
- L'obfuscation du système d'exploitation tel que décrit est-elle largement utilisée et je ne l'ai tout simplement pas rencontrée?
- S'ils ne sont pas largement utilisés, quels sont les obstacles pratiques ou techniques à l'utilisation?
Avant de déchirer votre idée, permettez-moi de dire que c'est une idée vraiment intéressante et que c'était super amusant d'y penser.
Veuillez continuer à sortir des sentiers battus et à poser des questions intéressantes!
D'accord, faisons ça!
Prenons un peu de recul et demandons pourquoi ce babyphone utilise Linux en premier lieu? Et s'il n'y avait pas de système d'exploitation et que l'application était écrite en code microcontrôleur nu (pensez au code Arduino)? Il n'y aurait alors pas de Sudo ou ls ou même un Shell à utiliser par l'attaquant, non?
Je ne suis pas un expert ici, mais je m'attends à ce que nous, en tant qu'industrie, gravitons vers la mise en place de Linux sur quelque chose d'assez gros pour le faire fonctionner en grande partie pour la commodité des développeurs:
- Réduction du temps de développement: lors de la création de votre whizpopper auto-correcteur cloud-synchronisé, compatible WiFi et Bluetooth, avec compagnon Android et applications iOS, Linux est livré avec toutes les bibliothèques, utilitaires et les pilotes dont vous avez besoin.
- Augmentation de la testabilité: si l'appareil exécute bash ou busybox avec un port SSH, il est très facile de se connecter et de déterminer ce qui n'a pas fonctionné pendant la phase de test de votre produit.
Pour que votre idée d'obscurcissement fonctionne, vous devez masquer non seulement les noms des utilitaires de ligne de commande comme Sudo et ls, mais aussi chaque API du noyau Linux pour empêcher l'attaquant de déposer son propre binaire compilé qui appelle directement le noyau. Reprenons donc votre idée:
La mise en œuvre serait assez facile pour les compilateurs. Prenons le cas le plus simple de "renommer cette fonction et tous les appels à elle". Vous pourriez donner à un compilateur OS et à un compilateur d'application les mêmes noms aléatoires et ils pourraient se parler.
Vous devrez faire cette compilation aléatoire vous-même; sinon quelqu'un pourrait rechercher les mappages sur google.
Donc, vous aurez besoin de construire le noyau à partir des sources avec votre "compilateur d'obscurcissement" afin que vous seul connaissiez les mappages des API du noyau obscurcies. (jamais construit le noyau linux à partir des sources? C'est certainement plus une corvée que docker pull Alpine, qui est la direction dans laquelle la culture de développement semble aller) .
Mais un système d'exploitation est plus qu'un simple noyau. Vous voulez des pilotes pour la puce wifi Broadcom BCM2837 fournie avec ce mini-ordinateur? Vous devrez construire ce pilote contre votre noyau ofbuscated avec votre compilateur, si Broadcom vous donnera même le code source. Ensuite, vous devrez créer l'intégralité des piles de logiciels de réseau et de wifi GNU. De combien d'autres choses aurez-vous besoin pour trouver la source et ajouter votre pipeline de construction avant d'avoir un système d'exploitation fonctionnel?
Oh, et si le dépôt en amont de l'une de ces choses émet un correctif, vous êtes maintenant responsable de le reconstruire (en supposant que vous avez enregistré les fichiers de mappage d'obfuscation du compilateur qui correspondent à votre binaire du noyau) et le pousser vers vos appareils parce que - par conception - vos appareils ne peuvent pas utiliser de binaires de correctifs produits par le fournisseur.
Oh, et pour déjouer les pirates, il n'y aura rien de tout cela "Voici les fichiers binaires pour Whizpopper 1.4.7" , oh non, vous 'ai besoin de construire une version entièrement obscurcie de tout, depuis le noyau par périphérique que vous expédiez.
Donc à vos questions:
- L'obfuscation du système d'exploitation tel que décrit est-elle largement utilisée et je ne l'ai tout simplement pas rencontrée?
- S'ils ne sont pas largement utilisés, quels sont les obstacles pratiques ou techniques à l'utilisation?
Je pense que la réponse est que ce que vous décrivez va à peu près complètement à l'encontre du but d'utiliser des composants logiciels préexistants si vous avez besoin de trouver et de construire littéralement tout à partir de la source. En fait, cela pourrait être moins d'efforts d'abandonner complètement le système d'exploitation, de faire comme si c'était 1960 et d'écrire votre application directement dans le microcode du processeur.
J'aime la sécurité plus que la plupart des développeurs, mais comme f * that .
La réponse de Mike dit essentiellement tout ce que j'ai à offrir sur la raison pour laquelle c'est une mauvaise idée du point de vue du développement (et, comme le dit Ghedipunk, une fonctionnalité de sécurité inutilisable n'offre aucune sécurité). Donc, à la place, je vais vous expliquer pourquoi du point de vue de la sécurité , vous ne feriez jamais cela.
La réponse est en fait étonnamment simple: c'est une perte de temps et il existe des options strictement meilleures. Chaque stupide doodad IoT (rappelez-vous, le "s" dans "IoT" signifie Secure) qui ne prend pas la peine d'implémenter de telles fonctionnalités, car l'enfer n'irait pas avec une approche comme vous le suggérez.
- L'idée ne fonctionnera tout simplement pas pour restreindre les appels système. Un attaquant peut simplement définir quelques registres et invoquer un opcode et un boom, ils sont dans le noyau exécutant l'appel système de leur choix; qui se soucie de son nom symbolique? Bien sûr, vous pouvez falsifier la table syscall pour compliquer cela (si cela ne vous dérange pas de devoir tout recompiler et de faire du débogage de votre noyau personnalisé une forme d'enfer) mais c'est comme obscurcir le système d'exploitation utilisé; pourquoi s'embêter quand il y a si peu de candidats de toute façon? Même si l'attaquant ne veut pas inverser l'ingénierie du code existant sur le système, le forçage brutal devrait être possible à moins que l'espace de recherche des indices d'appel utilisables ne soit plus large que je n'ai jamais vu sur un système embarqué.
- Pourquoi masquer les noms de commandes alors que vous pouvez simplement les rendre entièrement inaccessibles? Un
chrootne fonctionnera pas pour les fonctions intégrées de Shell si vous exécutez un Shell , mais cela fonctionne très bien pour tout le reste et vraiment, pourquoi votre application intégrée à usage unique exécutera-t-elle un shell? Je veux dire, les unités de développement en auraient un installé, à des fins de test, et peut-être que cela ne sera pas supprimé dans votre image de vente au détail parce que vous êtes paresseux ou pensez que vous en aurez besoin à nouveau. Mais un attaquant ne pourrait pas l'exécuter à partir du contexte dans lequel s'exécute son application. Un simplechroot(ou un bac à sable/prison/conteneur plus compliqué) peut rendre le programme incapable d'exécuter - ou même d'accéder - à des fichiers autres que ceux requis pour son travail. - Pourquoi obscurcir les API du noyau alors que vous pouvez simplement supprimer l'accès à celles-ci? Il existe un certain nombre de systèmes de sandboxing qui peuvent restreindre ce que peuvent faire un processus (ou ses descendants ... s'il est même autorisé à en créer un). Voir https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
Si votre objectif est de priver un attaquant de ls et cat, il existe une alternative encore meilleure à l'obfuscation: il suffit de ne pas installer ces utilitaires.
Bien que je ne dirais pas que c'est une approche d'implémentation largement , c'est au moins une implémentation. Par exemple, considérons distroless , une collection d'images de docker avec à peu près rien en elles. Certains d'entre eux (comme celui à emporter) n'ont littéralement rien en eux. Une attaque sur un système s'exécutant dans un tel conteneur ne peut pas accéder à Shell car il n'y a aucun Shell à exécuter.
Le seul moyen d'obtenir l'accès à Shell en attaquant une application dans un tel conteneur est alors de contourner le runtime du conteneur, conçu pour empêcher précisément cela.
Alors que j'ai donné un exemple d'image docker, le même concept peut être appliqué aux systèmes d'exploitation en général. Par exemple, ls et cat font partie du paquet coreutils dans Debian. Vous pouvez exécuter apt-get remove coreutils et soyez certain qu'un attaquant ne pourra pas utiliser ls ou cat dans le cadre d'une attaque. Bien sûr, cela signifie que vous ne pouvez pas les utiliser non plus, et il y a probablement beaucoup d'autres choses qui dépendent de coreutils qui devront également être supprimées, mais pour un périphérique intégré ou un serveur qui ne fait qu'une chose cela peut être OK.
Le principe général est de réduire la "surface d'attaque": plus une cible a de "choses", plus elle est facile à compromettre. Il peut s'agir de ports réseau ouverts, de lignes de code ou de fichiers binaires installés. Si l'augmentation de la sécurité est l'objectif, supprimer tous les "trucs" inutiles est un bon début.
Parce que l'obfuscation n'est pas la sécurité et parce que l'obfuscation du système d'exploitation est fondamentalement un non-sens.
Il n'y a que tant de systèmes d'exploitation courants et tant de façons de faire des suppositions éclairées. Si vous détectez que j'exécute IIS ou MSSQL Server, vous avez une idée du système d'exploitation exécuté en dessous.
Même si je parviens à exécuter une pile qui ne vous dit rien sur mon système d'exploitation sous-jacent et à masquer tous les autres indices (l'empreinte digitale est une chose), je n'ai toujours pas gagné grand-chose.
Du point de vue de la sécurité, vous savez que j'utilise Linux, ou même que j'utilise Debian 8, cela ne vous donne pas grand-chose à travailler ni à vous inquiéter. Si je suis correctement endurci et corrigé, vous pouvez savoir ce que vous voulez. Si je suis sur un niveau de correctif qui a été appliqué au musée du logiciel hier, votre suite d'attaques va me briser tout simplement en les essayant toutes, et obscurcir mon système d'exploitation ne vous oblige qu'à essayer quelques exploits inutiles de plus. Dans une attaque automatisée, cela vous ralentira pendant quelques secondes.
L'obfuscation ne fonctionne pas. Les gens peuvent vous scanner, prendre vos empreintes digitales ou simplement jeter toute leur bibliothèque d'exploits pour voir ce qui fonctionne.
Si vous perdez du temps sur ce que vous auriez pu consacrer au durcissement réel, vous portez en fait atteinte à votre sécurité.
Travaux de durcissement appropriés. J'ai dit plus haut que "vous pourriez savoir ce que vous voulez" . J'ai posté mon adresse IP et mot de passe root lors de conférences de sécurité où j'ai prononcé un discours. SSH avec connexion root à distance et un tas de services activés. Machine SELinux sérieusement durcie. Personne n'a jamais réussi à interrompre mon discours, bien qu'une personne ait réussi à déposer un fichier texte dans le répertoire racine alors que ma politique n'était pas encore parfaite.
Addendum: Votre point de départ était un film. L'obfuscation est un excellent appareil cinématographique, car une révélation comme celle-ci indique aux téléspectateurs que le héros (ou le méchant) a trouvé des informations et progresse donc. C'est l'ordinateur équivalent à savoir où se trouve le coffre-fort, même si vous avez toujours besoin du code. Ce n'est pas grave si c'est factuellement correct, s'il transmet le bon message émotionnel au public.
Pour un exemple extrêmement répandu, Intel Management Engine, qui a son propre système d'exploitation, fait quelque chose comme ça, où il existe un mécanisme de mise à jour du firmware, mais le firmware doit être dans un format très spécifique dont les détails sont confidentiels. Il semble impliquer un codage Huffman avec des paramètres inconnus. De manière similaire à votre proposition (qui est essentiellement un cryptage symétrique du firmware), ME nécessite des modifications spécifiques au moment de la préparation du firmware et présente un écart correspondant aux mécanismes standard au moment de l'exécution.
Ce que vous décrivez s'appelle "Sécurité par l'obscurité" et est un modèle de sécurité largement connu . Ce qui signifie que ce n'est pas une nouvelle idée, mais plutôt une vieille et mauvaise idée, dans laquelle les personnes qui ne sont pas initiées à la philosophie de la sécurité doivent être éduquées afin de ne pas tomber dedans.
Imaginez que vous conceviez une maison pour être sûre et que l'obscurité était une stratégie prometteuse. Toutes les maisons sont construites à partir de couloirs et de pièces, de portes avec poignées de porte, d'interrupteurs d'éclairage, etc. Comme elles sont communément connues, vous pouvez penser que cela n'est pas sûr car un intrus pourrait facilement naviguer dans la maison par ces éléments de construction communément connus. Vous pouvez essayer de repenser les principes de construction à partir de zéro, remplacer les boutons de porte par des cubes rubiks, créer des plafonds à mi-hauteur pour confondre l'intrus, etc. ça y est, et pire que tout, c'est pour rien car tout intrus, une fois à l'intérieur, peut regarder autour de lui avec ses yeux et utiliser son cerveau pour le comprendre. Les hackers sont des passionnés de puzzle dans l'âme.
La solution pour sécuriser votre maison n'est pas d'avoir une construction non standard, c'est d'avoir de meilleures serrures, des fenêtres sécurisées, un système de sécurité approprié, etc. Vous ne voulez pas cacher votre or dans un passage secret, car finalement Abbé et Costello s'appuiera sur ce chandelier et l'ouvrira accidentellement. Mettez votre or dans un coffre-fort avec une bonne combinaison secrète et une alarme de sabotage. L'équivalent informatique a un accès restreint avec des informations d'identification par cryptographie à clé publique, des rôles d'accès utilisateur limités, des systèmes de surveillance, une réduction de la surface exposée, une atténuation des vecteurs de menaces d'entrée, etc.
Les efforts pour rendre un système informatique plus obscur ne font que rendre votre système plus éloigné du support, plus difficile à obtenir security patches, plus difficile à utiliser de manière sécurisée .
Edit: Parfois, certains sécurité par l'obscurité est acceptable, lorsqu'elle est utilisée en plus de la sécurité réelle. Un exemple courant est d'exécuter SSH sur un port haut comme 30000 quelque chose. SSH est crypté, et l'accès est derrière une authentification authentifiée, c'est votre véritable sécurité. Mais l'avoir sur un port haut le rend moins visible au début si quelqu'un effectue des analyses rapides. Tout ce qui est plus compliqué que cela, comme essayer de brouiller votre système d'exploitation, en ferait simplement un cauchemar opérationnel, ce qui rendrait les mesures de sécurité réelles (comme être à jour sur les correctifs) plus difficiles.
Pensez utilisabilité
- Essayez d'expliquer à votre nouveau sysadmin qu'il doit frapper
ha7TrUOsans lecture deSudo,RRI6e29au lieu delset ainsi de suite ... Oui, il y a une liste de traductions que vous n'avez qu'à apprendre ! navigation sur le réseau local ne doit pas être possible aussi: il faut maintenir la liste papier pour garder une vue d'ensemble !?
Si vous renommez toutes les commandes critiques, vous devrez les piloter pour effectuer la mise à niveau du système!
Et comme Nick2253 commente , si vous essayez de construire un système intégré, puis faites de l'obscurcissement avant de publier le produit final, vous devrez tester le produit final.
- Vous devez créer un script fait maison pour tout lier pour l'obscurcissement.
- En cas de problème, le débogage deviendra délicat.
- Vous devez créer des scripts de désobfuscation faits maison, afin de pouvoir effectuer un débogage.
- Le feed-back personnalisé (avec les fichiers journaux) devra être désobfusqué aussi.
Ce faisant, vous ajouterez une couche de travail important avec de nouveaux bogues potentiels.
Pour très peu d'amélioration de la sécurité, voir plus loin
L'obscurité peut vous nuire.
Pensez niveau inférieur
Même si vous essayez de renommer des fichiers, de fonctionner au niveau de l'application et du système d'exploitation, tout cela utilisera bibliothèques standard qui sera appelé directement si l'attaquant envoie des fichiers exécutables binaires. Vous pourriez même envisager d'obscurcir toutes les bibliothèques standard! (Y compris système de fichiers, protocoles réseau ...)
Pendant que vous utilisez un noyau non modifié, ils utiliseront des variables et des espaces de noms standard. Donc, vous devrez créer version obscurcie du noyau ...
... Alors liez tout ensemble!
Eh bien, même lorsque tout est obscurci, l'application devra gérer Internet. L'obfuscation n'empêchera pas les bugs conceptuels à ce sujet!
Obscurité Si ce n'est pas à tous les niveaux, n'améliorera pas la sécurité.
Obscurité totale N'est pas vraiment possible, en raison de la nécessité d'utiliser des protocoles standard afin de pouvoir gérer Internet.
Pensez licence
Si vous prévoyez de distribuerGNU/Linux , vous devez partager le code source comme décrit dans GNU GENERAL PUBLIC LICENSE GPLv et/ou - GNU LESSER GENERAL PUBLIC LICENSE LGPLv (selon l'application et les librairies utilisées). Cela impliquera la publication de la méthode d'obfuscation avec chaque produit distribué.
Répondant strictement à vos deux questions:
Je suis quelque chose d'expert, mais avec une très petite concentration. Travaillant sur de nombreuses infrastructures différentes de petites entreprises, j'ai fait quelques choix il y a quelques années. L'évolution et l'histoire semblent confirmer mes choix, mais ce n'est que mon point de vue personnel.
L'obfuscation du système d'exploitation tel que décrit est-elle largement utilisée et je ne l'ai tout simplement pas rencontrée?
Donc, je ne sais vraiment pas dans quelle proportion l'obscurcissement est largement utilisé, mais je n'utilise pas la sécurité par obscurité = et déconseille.
S'ils ne sont pas largement utilisés, quels sont les obstacles pratiques ou techniques à l'utilisation?
Pas de barrières! C'est tout simplement contre-productif. Le coût en temps devient rapidement gigantesque et l'amélioration de la sécurité est un leurre.
Bien sûr, certaines choses minimales sont à faire:
- Ne démarrez pas le serveur
sshs'il n'est pas nécessaire - N'installez pas
Sudo, utilisez les bonnes structures - autorisations, groupes et cohérentes. - Gardez votre infrastructure mondiale à jour !!!
Petit échantillon when light come over obscurity
Sécurisation de
ssh: bidirectionnelle.Déplacer le port ssh de 22 à 34567
- léger et fait rapidement, mais
si un attaquant les trouvait, ils pourraient engager une force brute fluide contre ce port beaucoup de temps jusqu'à ce que l'utilisateur final les découvre.
installer un pare-feu
- Plus fort, nécessite plus de connaissances, mais.
Plus sûr tout en étant à jour.
Des classes entières d'attaques ne seraient-elles pas pratiquement inutiles si le système d'exploitation avait des commandes ha7TrUO et RRI6e29 au lieu de Sudo et ls? Imaginez un pirate qui a en quelque sorte obtenu un accès root à distance - que vont-ils même faire s'ils ne connaissent aucune commande?
Une meilleure alternative serait tout simplement de ne pas installer ces commandes en premier lieu. Je ne crois pas que vous ayez réellement besoin un Shell pour exécuter un noyau Linux, bien que cela implique que votre processus de démarrage soit autre chose que sysV-init ou systemd.
Comme d'autres l'ont noté, cependant, c'est un compromis entre la sécurité et la facilité de développement. Malheureusement, de nombreux fabricants d'appareils se soucient beaucoup plus de ce dernier que du premier.
La mise en œuvre serait assez facile pour les compilateurs. Prenons le cas le plus simple de "renommer cette fonction et tous les appels à elle". Vous pourriez donner à un compilateur OS et à un compilateur d'application les mêmes noms aléatoires et ils pourraient se parler. Mais même si l'application a une sécurité médiocre et est vulnérable à l'injection bash, de telles attaques seraient vaines.
Je ne suis pas sûr que vous ayez besoin de l'aide du compilateur. Je pense que vous pouvez principalement y parvenir en modifiant linker ¹ pour appliquer une randomisation à tous les noms de symboles. Il suffit probablement d'appliquer une fonction de hachage avec un sel qui n'est connu que du fabricant. Je ne suis pas sûr que vous ayez même besoin du code source pour ce faire, c'est-à-dire que je pensez vous pouvez appliquer le mangling au code déjà compilé.
(¹ Je pense que c'est un mensonge. Vous devrez peut-être modifier le code objet afin de remplacer les noms de symboles, mais cela ressemble plus au niveau assembleur, c'est-à-dire a) vous ne faites pas tout les durs bits de compilation de C/C++/etc. et b) vous n'avez pas besoin du code source C/C++/quelque soit le code. OTOH Je ne suis pas sûr que vous puissiez faire ce genre de chose si le code de votre appareil est plutôt quelque chose comme Python.)
Cependant, il existe encore une possibilité de rétro-ingénierie du processus, et de plus cela peut violer la GPL² (en particulier GPLv3) à moins que vous ne donniez le sel, ce qui irait à l'encontre du but.
En fait, "à cause de la GPL" est probablement la principale raison pour laquelle vous ne voyez pas cela; il serait difficile à implémenter d'une manière qui soit réellement utile en dehors de la fabrication de chaque appareil différent. OTOH, cela signifierait au moins que les attaquants ne peuvent cibler que des appareils spécifiques plutôt que de pouvoir exploiter une vulnérabilité sur "tout appareil exécutant Linux x.y.z".
(² Pour plus de simplicité, je vais simplement utiliser "GPL" partout, mais notez que cela s'applique généralement même pour L GPL'd stuff.)
Cela dit, notez que la GPL ne vous oblige pas à publier le sel car vous avez "modifié" les sources. Si la randomisation du nom du symbole se produit au moment de la compilation, vous n'avez pas modifié les sources. La raison pour laquelle vous auriez besoin de publier le sel est que la GPL exige que les utilisateurs puissent remplacer leurs propres versions d'une bibliothèque GPL, ce qu'ils ne peuvent pas faire à moins de connaître le sel. (Comme indiqué, vous pourrez peut-être vous en sortir avec la GPLv2, mais les effets techniques sont similaires à "uniquement exécuter un logiciel signé", pour lequel la GPLv3 a été spécifiquement écrite pour y remédier.)
En fin de compte, il pourrait y avoir certains avantage ici, mais vous n'allez pas rendre un système particulier notablement plus sûr (il est bien connu que la "sécurité par l'obscurité" n'est généralement pas sécurité du tout). Ce que vous pouvez accomplir, il est plus difficile de cibler de nombreux systèmes via un seul vecteur.
Divulgation équitable: je suis le directeur technique d'une entreprise qui construit exactement cela. Dé-biaiser tout ce que vous voulez.
Il IS en effet possible de construire complètement un noyau de système, des pilotes de périphériques, des packages, la pile entière par hôte, plusieurs fois par jour, et cela peut être très efficace. C'est exactement ce que nous faisons , et nous aidons nos clients à le faire. Nous ne sommes pas les seuls - nous pouvons en déduire qu'au moins Google le fait également pour toutes leurs machines (référence à venir bientôt.)
Maintenant, si vous aviez la possibilité de reconstruire à partir de zéro par machine, quelles sont les choses que vous pouvez changer?
Le projet d'autoprotection du noyau le permet déjà grâce à une réorganisation aléatoire des structures du noyau: https://lwn.net/Articles/722293/ . Cet article pointe également sur le célèbre échange où Linus Torvalds l'appelle théâtre de sécurité, mais l'auteur du projet (qui travaille chez Google) commente: "Eh bien, Facebook et Google ne publient pas leurs versions de noyau. :)"
Cela conduit à croire que Google le fait au moins et le considère utile. Pouvons-nous faire PLUS de types de brouillage sur un ensemble fermé? Au niveau le plus fondamental, pourquoi un virus Windows ne s'exécute-t-il pas sur Linux ou un Mac? Parce que les formats sont différents. C'est tout x86 en dessous, et pourtant ce n'est pas pareil. Et si deux Linux étaient différents de façon similaire? Windows vs Linux n'est pas une "obfuscation" simplement parce que nous n'avons pas beaucoup de façons de rendre Linux aussi différent que Windows de Linux. Mais ce n'est pas impossible, et ce n'est même pas si difficile. Adoptez l'approche du KSPP et appliquez-la aux appels système, puis recompilez tout en haut par rapport à ces appels système. Ça va être difficile à briser - du moins pas de façon survolée.
Votre question portait cependant sur le changement de nom des symboles (noms des exécutables, bibliothèques, etc.). Cela a deux aspects: (a) est-ce utile? (b) Peut-on le faire de manière fiable?
Nous recherchions un moyen de résoudre PHP injections de code une fois pour toutes. Malgré quoi HackerNews voudriez-vous le croire , PHP les injections de code ne sont pas un problème résolu en dehors des forums de discussion Internet. Vie réelle PHP développeurs, administrateurs et utilisateurs sont exposés à un nombre continu d'injections de code.
Nous avons donc décidé d'essayer le Polyscripting (licence Open Source autorisée par le MIT): https://github.com/polyverse/polyscripted-php
Nous partageons cela publiquement pour solliciter des commentaires, et nous gérons deux sites Web, polyscripted.com et nonpolyscripted.com , qui font exactement ce que vous attendez en fonction de leurs noms. Nous avons également engagé des pentesters pour essayer de le briser.
Et je commence tout juste à expérimenter avec les bibliothèques partagées exécutables et le renommage des symboles exportés sur un ensemble fermé (dans un conteneur Docker, par exemple). Personnellement, je ne pense pas que cela ajoute autant de valeur, mais cela en ajoutera-t-il un peu? Je le pense. Cela revient donc au coût. Si vous pouvez obtenir peu de valeur pour un coût encore plus faible, pourquoi ne pas le faire? C'est exactement pourquoi nous avons tous l'ASLR - ce n'est pas exactement la meilleure défense depuis le pain tranché, mais si vous avez déjà du code déplaçable et que vous allez le réorganiser de toute façon, pourquoi NE PAS le pousser à la limite et le randomiser?
En bref, l'approche que vous décrivez est tentée par de nombreuses personnes (y compris Google, Facebook, le noyau Linux, etc.), ainsi que de nombreux universitaires dans le domaine de la défense contre les cibles mobiles, et une poignée d'entreprises comme la nôtre qui '' re essayer de le rendre trivialement consommable comme ASLR.
Je dirais comment je vois cela du point de vue des pirates.
Certainement, si vous renommez tous les utilitaires - cela rendra les choses beaucoup plus difficiles et moins confortables pour moi, mais que pourrais-je faire?
Si j'avais déjà accès à Shell sur le système, je téléchargerais simplement une boîte occupée (tous les utilitaires de base en un seul binaire) ou un ensemble complet de binaires dont j'ai besoin pour les opérations de base.
Pour augmenter encore les privilèges, il se peut que je doive chercher des binaires suid-root, et il y en a peu (Sudo, mount, etc.). Le pirate ne peut pas télécharger de tels fichiers (sauf s'il est déjà root). Mon petit système Linux simple n'a que 24 binaires suid. Très facile d'essayer chacun d'eux manuellement.
Mais de toute façon, je suis d'accord, cela rendrait le piratage de cette boîte plus difficile. Ce serait pénible d'utiliser (pirater) ce système, mais c'est possible. Et le pirate informatique fonctionne sur le système pendant une heure, un jour ou un mois ... mais l'administrateur/l'utilisateur peut travailler sur le système pendant des années et ne peut pas se souvenir des noms ha7TrUO et RRI6e29. Peut-être que personne n'essaiera même de pirater le système, mais l'administrateur en souffrira chaque jour.
Mais ... si vous rendez la sécurité trop élevée mais inconfortable pour l'utilisateur/administrateur - souvent, vous réduisez la sécurité en fait. Comme si vous appliquez des mots de passe complexes avec plus de 20 caractères - les mots de passe les plus probables seront écrits sur des post-it sur le moniteur. Si vous voulez rendre le système aussi obscur, il sera très difficile de travailler dessus pour les bons utilisateurs. Et ils devront faire certaines choses pour leur faciliter la vie. Par exemple, ils peuvent télécharger leur binaire busybox. Temporaire. Et ils l'oublieront ou l'y laisseront intentionnellement (car ils prévoient de l'utiliser un peu plus tard).
Cela se produit réellement, car les connexions ssh sont cryptées. Changer les noms de certains binaires de base ne fait rien de plus que cela. Cela provoquerait également beaucoup de chaos: par exemple tous les scripts s'appuyant sur ces utilitaires sont soit rendus inutilisables, soit vous aurez besoin d'une sorte de "déobfuscateur" proxy, qui finirait sûrement par être un vecteur d'attaque. Cependant, j'ai vu certains serveurs dans la nature qui n'autorisent pas la connexion root, forçant à utiliser Sudo à la place. Les noms d'utilisateur des sudoers restent quelque peu secrets. Je ne sais pas à quel point c'est sécurisé, mais je ne suis pas un expert.
Pourquoi toutes les portes n'ont-elles pas dix trous de serrure, dont un seul fonctionnait réellement pour les clés ou les serrures? Réponse: la plupart du temps, la peine ne vaut pas les dix secondes supplémentaires du temps d'un voleur.
S'il y avait des millions de niquecréés isolément systèmes d'exploitation de code source, l'obscurcissement pourrait être courant. Cependant, en pratique, nous avons environ quatre bases de code uniques en usage commun - toutes les informations de fuite sur elles-mêmes par le calendrier des événements, et pour plusieurs fonctions de bas niveau du système d'exploitation où les fabricants de puces fournissent des séquences de codes de bits de machine prescrites pour activer ou accéder à certaines fonctionnalités du processeur, elles tous ont probablement de courtes séquences contenant exactement le même code.