Avant de déchirer votre idée, laissez-moi vous dire que c'est une idée vraiment intéressante et que c'était super amusant d'y réfléchir.

Merci de continuer à penser à l'extérieur la boîte et posez des questions intéressantes!

D'accord, allons-y!

Prenons du recul et demandons pourquoi babyphone fonctionne sous Linux en premier lieu? Et s'il n'y avait pas de système d'exploitation et que l'application était écrite en code de microcontrôleur nu (pensez au code Arduino)? Alors il n'y aurait pas de sudo ou ls ou même de shell pour l'attaquant à utiliser, non?

Je ne suis pas un expert ici, mais Je pense que nous, en tant qu'industrie, avons tourné vers l'installation de Linux sur quelque chose d'assez grand pour l'exécuter en grande partie pour la commodité des développeurs:

1. Réduction du temps de développement: lors de la construction de votre WiFi et Bluetooth-capable Whizpopper auto-patching de synchronisation cloud administré par le Web avec les applications Android et iOS associées, Linux est livré avec toutes les bibliothèques, utilitaires et pilotes dont vous avez besoin pour le faire.
2. Augmentation de la testabilité: si l'appareil exécute bash ou busybox avec un port SSH, il est alors 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 doivent masquer non seulement les noms des utilitaires de ligne de commande tels que sudo et ls , mais aussi chaque API du noyau Linux pour empêcher l'attaquant de tomber dans leur propre binaire compilé qui ca lls le noyau directement. Jetons donc un autre regard sur 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 à celle-ci». 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 devrez construire le noyau à partir des sources avec votre "compilateur obscurcissant" afin que vous seul connaissiez les mappages des API du noyau obscurcies. (vous avez déjà 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 bien plus que le noyau. Vous voulez des pilotes pour la puce wifi Broadcom BCM2837 fournie sur ce mini-pc? Vous devrez construire ce pilote sur votre noyau ofbuscated avec votre compilateur, si Broadcom vous donnera même le code source. Ensuite, vous devrez créer l'ensemble des piles de logiciels GNU wifi et réseau. 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 les dépôts en amont de l'une de ces choses émettent un correctif, vous êtes maintenant responsable de le reconstruire (en supposant que vous ayez enregistré les fichiers de mappage d'obscurcissement du compilateur qui correspondent à votre binaire du noyau ) et le pousser sur vos appareils parce que - de par leur conception - vos appareils ne peuvent pas utiliser les fichiers binaires de correctifs produits par le fournisseur.

Oh, et pour déjouer les pirates, il n'y en aura pas de ce "Voici les fichiers binaires pour Whizpopper 1.4.7" , oh non, vous aurez besoin de construire une version obscurcie de tout ce qui est du noyau jusqu'à par appareil vous expédiez.

Donc à vos questions:

1. L'obscurcissement du système d'exploitation tel que décrit est-il largement utilisé et je ne l'ai tout simplement pas rencontré?
2. Si ce n'est pas largement utilisé, 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 but d'utiliser des composants logiciels préexistants si vous avez besoin de trouver et de construire littéralement tout de la source. Il pourrait en fait être moins difficile 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 j'aime f * that .

La réponse de Mike dit essentiellement tout ce que j'ai à offrir sur les raisons pour lesquelles c'est une mauvaise idée du point de vue du développement (et, comme le dit le commentaire de Ghedipunk, une fonction de sécurité inutilisable n'offre aucune sécurité). Au lieu de cela, je vais 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 de mettre en œuvre de telles fonctionnalités ne serait certainement pas adapté à une approche comme vous le suggérez.

1. Toute l'idée ne fonctionnera 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 absolu) 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 souhaite pas procéder à l'ingénierie inverse du code existant sur le système, le forçage brutal devrait être possible à moins que l'espace de recherche des index d'appels utilisables ne soit plus large que ce que j'ai jamais vu sur un système embarqué.
2. Pourquoi masquer les noms de commandes alors que vous pouvez simplement les rendre totalement inaccessibles? Un chroot ne fonctionnera pas pour les interfaces intégrées du shell si vous exécutez un shell , mais cela fonctionne bien pour tout le reste et vraiment, pourquoi votre single personnalisé -pour l'application-dans-une-boîte exécuter 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 à nouveau besoin. Mais un attaquant ne pourrait pas l'exécuter à partir du contexte dans lequel son application s'exécute. Un simple chroot (ou un bac à sable / une prison / un 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.
3. Pourquoi obscurcir les API du noyau lorsque vous pouvez simplement en supprimer l'accès? Il existe un certain nombre de systèmes de sandboxing qui peuvent restreindre ce que peut faire un processus (ou ses descendants ... s'il est même autorisé à en créer). 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: n'installez simplement pas ces utilitaires.

Bien que je ne dise pas qu'il s'agit d'une approche largement implémentée, c'est au moins une implémentation. Par exemple, considérez distroless, une collection d'images de docker ne contenant pratiquement rien. Certains d'entre eux (comme celui pour go) n'ont littéralement rien en eux. Une attaque sur un système fonctionnant dans un tel conteneur ne peut pas obtenir l'accès au shell car il n'y a pas de shell à exécuter.

Le seul moyen alors d'obtenir un accès au shell en attaquant une application dans un tel conteneur est puis pour contourner le runtime du conteneur, qui est 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 être sûr 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 que une chose qui peut être OK.

Le principe général est de réduire la "surface d'attaque": plus une cible a de "trucs", plus il est facile de faire des compromis. Il peut s'agir de ports réseau ouverts, de lignes de code ou de binaires installés. Si l’objectif est d’améliorer la sécurité, supprimer toutes les "choses" inutiles est un bon début.

Parce que l'obscurcissement n'est pas une sécurité et parce que l'obscurcissement du système d'exploitation est fondamentalement absurde.

Il n'y a que tellement 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 qui s'exécute en dessous.

Même si j'arrive d'une manière ou d'une autre à exécuter une pile qui ne vous dit rien sur mon système d'exploitation sous-jacent, et masquer également tous les autres indices (la prise d'empreintes digitales est une chose), je n'ai toujours pas gagné grand-chose.

Sur le plan de la sécurité, vous savez que je suis sous Linux, ou même que j'utilise Debian 8, ne vous donne pas beaucoup de travail ni de quoi m'inquiéter. Si je suis correctement endurci et patché, vous pouvez savoir ce que vous voulez. Si je suis à un niveau de correctif qui s'est appliqué au musée du logiciel hier, votre suite d'attaques me brisera tout simplement en les essayant toutes, et obscurcir mon système d'exploitation ne vous obligera qu'à essayer encore quelques exploits inutiles. Lors d'une attaque automatisée, cela vous ralentira pendant quelques secondes.

L'obscurcissement ne fonctionne pas. Les gens peuvent vous scanner, vous empreintes digitales ou simplement lancer toute leur bibliothèque d'exploits pour voir ce qui fonctionne.

Si vous perdez du temps sur ce que vous auriez pu consacrer à un durcissement réel, vous nuisez en fait votre sécurité .

Travaux de durcissement corrects. J'ai dit plus haut que "vous pourriez savoir ce que vous voulez" . J'ai publié mon adresse IP et mon mot de passe root lors de conférences sur la 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'obscurcissement est un excellent appareil de cinéma car une révélation comme celle-ci indique aux téléspectateurs que le héros (ou le méchant) a trouvé une information et progresse ainsi. C'est l'équivalent informatique de savoir où se trouve le coffre-fort, même si vous avez toujours besoin du code. Peu importe si c'est factuellement correct, s'il transmet le message émotionnel approprié 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, là où il existe un mécanisme de mise à jour du micrologiciel, mais le micrologiciel 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 même que votre proposition (qui est fondamentalement un cryptage symétrique du micrologiciel), ME nécessite des modifications spécifiques au moment de la préparation du micrologiciel et présente un écart correspondant par rapport aux mécanismes standard au moment de l'exécution.

Ce que vous décrivez s'appelle «La sécurité par l'obscurité» et est un antipattern de sécurité largement connu. Cela signifie que ce n'est pas une idée nouvelle, mais plutôt une vieille et mauvaise idée, dans laquelle les personnes non initiées à la philosophie de la sécurité doivent être éduquées pour ne pas tomber.

Imaginez que vous conceviez une maison sécurisée, et pensait que l'obscurité était une stratégie prometteuse. Toutes les maisons sont construites hors des couloirs et des pièces, des portes avec des poignées de porte, des interrupteurs d'éclairage, etc. Comme ils sont communément connus, vous pourriez penser que ce n'est pas sûr car un intrus pourrait facilement naviguer dans la maison par ces éléments de construction communément connus. Vous pourriez essayer de repenser les principes de construction à partir de zéro, remplacer les boutons de porte par des cubes rubiks, faire des plafonds à mi-hauteur pour confondre l'intrus, etc. à voir avec cela, et pire que tout, c'est pour rien parce que 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. Je veux cacher votre or dans un passage secret, car finalement Abbot et Costello vont s'appuyer sur ce chandelier et l'ouvrir accidentellement. Mettez votre or dans un coffre-fort avec une bonne combinaison secrète et une alarme anti-sabotage. L'équivalent informatique est d'avoir un accès restreint par authentification 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 menace d'entrée, etc.

Les efforts pour rendre un système informatique plus obscur ne font que rendre votre système est plus éloigné du support, plus difficile à obtenir des correctifs de sécurité , plus difficile à utiliser de manière sécurisée .

Modifier: Parfois, une certaine sécurité par l'obscurité est acceptable, lorsqu'elle est utilisée en plus de la sécurité réelle. Un exemple courant est l'exécution de SSH sur un port élevé comme 30000 quelque chose. SSH est crypté, et l'accès est derrière une authentification par identifiant, c'est votre vraie sécurité. Mais l'avoir sur un port haut le rend simplement moins visible pour commencer si quelqu'un effectue des analyses rapides. Tout ce qui est plus compliqué que cela, comme essayer de masquer 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 à l'utilisabilité

• Essayez d'expliquer à votre nouvel administrateur système qu'il doit appuyer sur ha7TrUO au lieu de sudo , RRI6e29 au lieu de ls et ainsi de suite ... Oui, il y a une liste de traductions que vous avez juste à apprendre!

• naviguer sur le réseau local ne doit pas non plus être possible: vous devez maintenir une liste papier afin de garder une vue d'ensemble !?

• Si vous renommez toutes les commandes critiques, vous devrez conduire ceci pour faire la mise à niveau du système!

• Et comme Nick2253 commenter, si vous essayez de créer un système intégré, puis faites une 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 obfuscation.
  • Si quelque chose ne va pas, le débogage deviendra délicat.
  • Vous devez créer des scripts de désobfuscation faits maison , afin de pouvoir faire certains débogage.
  • Retour personnalisé (avec log fi les) devront être désobfusqués aussi .

  Ce faisant, vous ajouterez une couche de travail important avec de nouveaux bogues potentiels.

  Pour très peu d’améliorations de la sécurité, voir plus loin

L’obscurité pourrait 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 des bibliothèques standard qui seront appelées directement si l'attaquant envoyer des fichiers exécutables binaires. Vous pourriez même envisager de masquer toutes les bibliothèques standard! (Y compris le système de fichiers, les protocoles réseau ...)

• Pendant que vous utilisez un noyau non modifié, ils utiliseront des variables et des espaces de noms standard . Il va donc falloir créer une version obscurcie du noyau ...

... Puis tout lier ensemble!

Eh bien, même lorsque tout est obscurci, l'application devra gérer Internet. L'obscurcissement 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é.

L'obscurité totale n'est pas vraiment possible, en raison de la nécessité d'utiliser protocoles standards afin de pouvoir gérer Internet.

Pensez à license

Si vous prévoyez de distribuer GNU / Linux, vous devez partager le code source comme décrit dans GNU GENERAL PUBLIC LICENSE GPLv3 et / ou GNU LESSER GENERAL PUBLIC LICENSE LGPLv3 (selon l'application et librairies utilisées). Cela impliquera la publication de la méthode d'obscurcissement avec chaque produit distribué .

Répondre strictement à vos deux questions:

Je suis un expert, mais avec un tout petit foyer. Travaillant sur de nombreuses infrastructures de petites entreprises différentes, j'ai fait des 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'obscurcissement du système d'exploitation tel que décrit est-il largement utilisé et je ne l'ai tout simplement pas rencontré?

Donc, je ne sais vraiment pas dans quelle proportion l’obscurcissement est largement utilisé, mais je n’utilise pas la sécurité par l’obscurité et déconseillé.

S'il n'est pas largement utilisé, quels sont les obstacles pratiques ou techniques à l'utilisation?

Pas de barrières! C'est juste contre-productif. Le coût du temps devient rapidement gigantesque et l’amélioration de la sécurité est un leurre.

Bien sûr, certaines choses minimes sont à faire:

• Ne commencez pas ssh serveur s'il n'est pas nécessaire
• N'installez pas sudo , utilisez les permissions , les groupes et la structure cohérente corrects.
• Gardez votre infrastructure globale à jour !!!

Petit échantillon quand la lumière vient sur l'obscurité

• Sécurisation ssh : bidirectionnelle.

  • Déplacez le port ssh de 22 à 34567

    • léger et rapide, mais

    si un attaquant les trouvait, il pourrait engager une force brute fluide contre ce port pendant longtemps jusqu'à ce que l'utilisateur final les découvre.

  • installer un pare-feu

    • Plus solide, nécessite plus de connaissances, mais.

    Plus sécurisé 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 informatique qui obtient en quelque sorte un accès root à distance - que vont-ils même faire s’ils ne connaissent aucune commande?

Une meilleure alternative serait simplement de ne pas installer ces commandes dans la première place. Je ne pense pas que vous ayez besoin d'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 ont noté, cependant, qu'il s'agissait d'un compromis entre la sécurité et la facilité de développement. Malheureusement, de nombreux fabricants de périphériques 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 à celle-ci». 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 mauvaise sécurité et est vulnérable à l'injection bash, de telles attaques seraient infructueuses.

Je ne suis pas sûr que vous ayez besoin de l'aide du compilateur à tout. Je pense que vous pouvez principalement y parvenir en modifiant le 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 de code source pour faire cela, c'est-à-dire que je pense que vous pourriez appliquer le découpage au code déjà compilé.

(¹ Je pense que c'est un peu Vous devrez peut-être modifier le code objet afin de remplacer les noms des symboles, mais cela ressemble plus au niveau assembleur, c'est-à-dire a) vous ne faites pas tout le dur bits de compilation C / C ++ / etc. code et b) vous n'avez pas besoin du code source C / C ++ / quel que soit le code source. 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.)

Il y a encore une possibilité de rétroconcevoir le processus, cependant, et en plus cela peut violer la GPL² (en particulier la GPLv3) à moins que vous ne donniez le sel, ce qui irait à l'encontre de l'objectif.

En fait , "à cause de la GPL" est probablement la principale raison pour laquelle vous ne voyez pas ceci; il serait difficile de l'implémenter d'une manière qui soit réellement utile en dehors de rendre 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 xyz».

(² Par souci de simplicité, J'utiliserai simplement "GPL" partout, mais notez que cela s'applique généralement même pour les éléments sous L GPL.)

Cela dit, notez que la GPL ne vous oblige pas pour publier le sel parce que 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 parce que la GPL exige que les utilisateurs puissent remplacer leurs propres versions d'une bibliothèque sous 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 à "exécuter uniquement des logiciels signés", pour laquelle la GPLv3 a été spécifiquement écrite.)

En fin de compte , il pourrait y avoir un avantage ici, mais vous n'allez pas rendre un système particulier sensiblement plus sûr (il est bien connu que la "sécurité par l'obscurité" n'est généralement pas une sécurité du tout). Ce que vous pouvez accomplir, c'est rendre plus difficile le ciblage de nombreux systèmes via un seul vecteur.

Divulgation équitable: je suis le directeur technique d'une entreprise qui construit exactement cela. Dé-biaisez pour cela tout ce que vous voulez.

Il est en effet possible de construire complètement un noyau système, des pilotes de périphériques, des packages, toute la pile par hôte, plusieurs fois par jour, et cela peut être assez efficace. C'est exactement ce que nous faisons et nous aidons nos clients à faire. Nous ne sommes pas les seuls - nous pouvons en déduire qu'au moins Google le fait également pour toutes ses machines (référence à venir.)

Maintenant, si vous aviez la possibilité de reconstruire par machine à partir de zéro, quoi y a-t-il des 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 souligne également le célèbre échange où Linus Torvalds l'appelle théâtre de la 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 mène à la conclusion qu'au moins Google fait cela 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. Tout est x86 en dessous, et pourtant ce n'est pas la même chose. Et si deux Linux étaient différents de la même manière? Windows vs Linux n'est pas "obscurcir" simplement parce que nous n'avons pas beaucoup de façons de rendre les Linux aussi différents que Windows l'est de Linux. Mais ce n'est pas impossible, et ce n'est même pas vraiment si difficile. Adoptez l'approche du KSPP et appliquez-la aux appels système, puis recompilez tout ce qui se trouve en haut contre ces appels système. Cela va être très difficile à casser - du moins pas de manière survolée.

Votre question portait sur le changement de nom des symboles (noms des exécutables, bibliothèques, etc.) Cela a deux aspects: (a) est c'est utile? (b) Cela peut-il être fait de manière fiable?

Nous cherchions un moyen de résoudre une fois pour toutes les injections de code PHP. Malgré ce que HackerNews voudrait vous faire croire, les injections de code PHP ne sont pas un problème résolu en dehors des forums de discussion sur Internet. Les développeurs, administrateurs et utilisateurs PHP de la vie réelle sont exposés à un nombre continu d'injections de code.

Nous avons donc essayé Polyscripting (Open Source sous licence MIT permissive): https: // github. com / polyverse / polyscripted-php

Nous partageons ceci 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 embauché des pentesters pour essayer de le casser.

Et je commence tout juste à expérimenter avec des exécutables, des bibliothèques partagées et le renommage de symboles exportés sur un ensemble fermé (dans un conteneur de docker, par exemple). Personnellement, je ne pense pas que cela ajoute autant de valeur, mais est-ce que cela en ajoutera un peu? Je le pense. C'est donc une question de coût. Si vous pouvez obtenir peu de valeur pour un coût encore plus petit, 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à un code relocalisable 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 par de nombreux universitaires dans le domaine de la défense de cible mobile et une poignée d'entreprises comme les nôtres qui essaient de le rendre trivialement consommable comme ASLR.

Je dirais comment je vois cela du point de vue des hackers.

Certainement, si vous renommez tous les utilitaires - cela rendra les choses beaucoup plus difficiles et moins confortables pour moi, mais que pourrais-je faire?

1. Si j'avais déjà accès au shell sur le système, je téléchargerais simplement busybox (tous les utilitaires de base dans un binaire) ou l'ensemble complet de binaires dont j'ai besoin pour les opérations de base.

2. Pour augmenter encore les privilèges, je devrai peut-être rechercher des binaires suid-root, et il n'y en a que quelques-uns (sudo, mount, etc.). Hacker 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. Il serait pénible d'utiliser (pirater) ce système, mais c'est possible. Et le hacker travaille sur le système pendant une heure, un jour ou un mois ... mais l'administrateur / 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 tous les jours.

Mais ... si vous rendez la sécurité trop élevée mais inconfortable pour l'utilisateur / administrateur, vous réduisez souvent 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 si obscurci, il sera très difficile de travailler dessus pour les bons utilisateurs. Et ils devront faire certaines choses pour rendre leur vie plus facile. Par exemple, ils peuvent télécharger leur binaire busybox. Temprorary. Et ils l'oublieront ou le laisseront là intentionnellement (car ils prévoient de l'utiliser un peu plus tard).

Cela arrive en fait, car les connexions ssh sont cryptées. Changer les noms de certains binaires de base n'accomplit rien de plus. Cela causerait également beaucoup de chaos: par exemple tous les scripts reposant sur ces utilitaires sont soit rendus inutilisables, soit vous aurez besoin d'une sorte de "deobfuscator" proxy, qui finirait sûrement par devenir un vecteur d'attaque. Cependant, j'ai vu certains serveurs dans la nature qui n'autorisent pas la connexion root, obligeant à utiliser sudo à la place. Les noms d'utilisateur des sudoers restent quelque peu secrets. Je ne sais pas à quel point il 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 pour les clés ou les crochets de serrure? 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 code source uniques créés isolément systèmes d'exploitation, l'obscurcissement peut être courant. En pratique cependant, nous avons à peu près quatre bases de code uniques en usage commun - toutes les informations de fuite sur elles-mêmes par synchronisation des événements, et pour plusieurs fonctions du système d'exploitation de bas niveau où les fabricants de puces donnent des séquences de bitcode machine prescrites pour activer ou accéder à certaines fonctionnalités du processeur, ils tous ont probablement de courtes séquences contenant exactement le même code.

Si vous obscurcissez GNU / Linux sur un appareil IoT distribué au public, vous serez obligé de publier votre code car il est sous GPL, ou de retirer l'appareil du marché.

Obfusquer les logiciels sous GPL - une stratégie dépendant du secret - n'est pas une idée viable.

Je ne sais pas pourquoi cela est déclassé; mais si les objections sont dans la veine des commentaires de Charles: Le simple fait de renommer les utilitaires de base ne fonctionnera pas (pour un démarrage simple, vous devrez éditer les scripts d'initialisation sous GPL). Je soupçonne fortement que vous devrez également recompiler de nombreux binaires qui interagissent avec d'autres binaires comme le pilote du compilateur gcc, ld.so, sh / bash etc. Tous les scripts shell et de nombreux fichiers de configuration doivent connaître les noms et les emplacements de binaires, ils doivent donc être modifiés.

Tout cela est sous GPL et vous serez obligé de publier les sources, les scripts et les fichiers de configuration modifiés, frustrant ainsi les efforts d'obfuscation. Si vous utilisez l'appareil uniquement en interne, il n'y a aucune obligation de publier les sources, mais en même temps, le cas de l'obscurcissement est beaucoup plus faible: vous vous frustrerez surtout vous-même.

Les compilateurs (en fait, les éditeurs de liens) le font déjà. C'est l'une des principales raisons pour lesquelles l'ingénierie inverse est difficile.

Dans votre code source, vous pouvez avoir ces fonctions:

  void print_hello () {printf ("Bonjour! \ N ");} void print_hello_twice () {print_hello (); print_hello ();}  

Voici à quoi ils ressemblent après avoir été compilés dans un programme:

  0x400582 push rbp0x400583 mov rbp, rsp0x400586 mov edi, 0x4006340x40058b call 0x4004900x400590 nop0x400591 pop rbp0x400592 ret0x400593 push rbp0x400594 mov rbp, rsp0x400597 call 0x4005820x40059c call 0x4005820x4005a1 nop0x4005a2 pop rbp0x4005a3 push rbp0x400594 mov rbp, rsp0x400597 call 0x4005820x40059c call 0x4005820x4005a1 nop0x4005a2 pop rbp0x4005a3 push est maintenant appelé "print"  0x400582 ,  printf  s'appelle désormais  0x400490  et  print_hello_twice  s'appelle désormais  0x400593 . Tous les appels ont également reçu les mêmes noms aléatoires, de sorte que les fonctions peuvent s'appeler les unes les autres.  
 Cependant, l'éditeur de liens ne peut le faire que dans un programme, car il lie un programme à la fois .