it-swarm-es.com

¿Por qué la defensa de ofuscación del sistema operativo contra "es un sistema Unix!" no ampliamente implementado?

El escena de Jurassic Park al que se hace referencia en el título es infame por lo ridículo que suena para aquellos que saben mucho de tecnología. Pero también ilustra lo que me parece un enorme agujero en la seguridad web, en particular los dispositivos IoT: tan pronto como los atacantes descubren que un servidor o cámara o monitor de bebé ejecuta Linux, instantáneamente conocen volúmenes sobre cómo funciona. Saben que comandos como Sudo son grandes objetivos jugosos y saben que el acceso Shell traerá consigo herramientas útiles como ls y cat.

Entonces, ¿por qué la ofuscación del sistema operativo no es más una cosa? No estoy hablando de ocultar la versión en los encabezados web. Similar a la minificación u ofuscación de JavaScript, estoy hablando de cambiar los nombres de binarios y rutas de archivos en el sistema operativo. ¿No serían prácticamente inútiles clases enteras de ataques si el sistema operativo tuviera ha7TrUO y RRI6e29 comandos en lugar de Sudo y ls? Imagine a un pirata informático que de alguna manera obtuvo acceso a la raíz remota: ¿qué van a hacer si no conocen ningún comando?

La implementación sería bastante fácil para los compiladores. Tome el caso más simple de "cambiar el nombre de esta función y todas las llamadas a ella". Podrías dar a un compilador de SO y a un compilador de aplicaciones los mismos nombres aleatorios y podrían comunicarse entre ellos. Pero incluso si la aplicación tiene poca seguridad y es vulnerable a la inyección de bash, tales ataques serían infructuosos.

Obviamente, esta técnica no se puede utilizar en todos los escenarios. Dejando de lado escenarios como servidores mantenidos por administradores de sistemas humanos, me parece que cualquier dispositivo o servidor administrado por automatización es un candidato principal para esta defensa.

Supongo que las preguntas deben ser un poco más concretas:

  1. ¿La ofuscación del sistema operativo como se describe se usa ampliamente y simplemente no la he encontrado?
  2. Si no se usa ampliamente, ¿cuáles son las barreras prácticas o técnicas para el uso?
156
Indigenuity

Antes de desgarrar tu idea, déjame decirte que es una idea realmente interesante y fue muy divertido pensar en ella.

¡Continúa pensando fuera de la caja y haz preguntas interesantes!

Muy bien, ¡hagamos esto!


Vamos a dar un paso atrás y preguntar por qué ese monitor de bebé está ejecutando Linux en primer lugar. ¿Qué pasaría si no hubiera un sistema operativo y la aplicación estuviera escrita en código microcontrolador (piense en el código arduino)? Entonces no habría Sudo o ls o incluso un Shell para el atacante, ¿verdad?

No soy un experto aquí, pero espero que nosotros, como industria, nos hemos inclinado por poner Linux en algo lo suficientemente grande como para ejecutarlo en gran medida para la comodidad del desarrollador:

  1. Reducción del tiempo de desarrollo: al crear su whizpopper auto-parcheado de sincronización en la nube administrado por la web compatible con WiFi y bluetooth con complementario Android y aplicaciones iOS, Linux viene con todas las bibliotecas, utilidades y controladores que necesita hacer eso.
  2. Aumento de la capacidad de prueba: si el dispositivo ejecuta bash o busybox con un puerto SSH, es muy fácil conectarse y descubrir qué salió mal durante la fase de prueba del producto.

Para que su idea de ofuscación funcione, necesitaría ofuscar no solo los nombres de las utilidades de línea de comandos como Sudo y ls, sino también cada API de kernel de Linux para evitar que el atacante deje caer su propio binario compilado que llama al kernel directamente. Así que echemos otro vistazo a su idea:

La implementación sería bastante fácil para los compiladores. Tome el caso más simple de "cambiar el nombre de esta función y todas las llamadas a ella". Podrías dar a un compilador de SO y a un compilador de aplicaciones los mismos nombres aleatorios y podrían comunicarse entre ellos.

Tendrá que hacer esta compilación aleatoria usted mismo; de lo contrario, alguien podría buscar las asignaciones en google.

Por lo tanto, deberá compilar el núcleo desde el origen con su "compilador de ofuscación" para que solo usted conozca las asignaciones de las API de kernel ofuscado. (¿alguna vez construyó el kernel de Linux desde la fuente? Sin duda es más una tarea que docker pull Alpine, que es la dirección en la que parece ir la cultura de desarrollo) .

Pero un sistema operativo es más que solo el núcleo. ¿Desea controladores para el chip wifi Broadcom BCM2837 que viene en ese dispositivo mini-pc? Tendrá que compilar ese controlador contra su núcleo ofbuscado con su compilador, si Broadcom incluso le dará el código fuente. De lo que necesitará para construir todo el GNU wifi y las pilas de software de red. ¿Cuántas otras cosas necesitará para encontrar la fuente y agregar su canal de compilación antes de tener un sistema operativo en funcionamiento?

Ah, y si los repositorios ascendentes de cualquiera de esas cosas emiten un parche, ahora eres responsable de reconstruirlo (suponiendo que guardaste los archivos de mapeo de ofuscación del compilador que coinciden con el binario del kernel) y enviarlo a sus dispositivos porque, por diseño, sus dispositivos no pueden usar binarios de parches producidos por el proveedor.

Ah, y para frustrar a los hackers, no habrá nada de esto "Aquí están los archivos binarios para Whizpopper 1.4.7" , oh no, usted Tendrá que crear una versión única ofuscada de todo, desde el núcleo hacia arriba por dispositivo que envíe.


Entonces a sus preguntas:

  1. ¿La ofuscación del sistema operativo como se describe se usa ampliamente y simplemente no la he encontrado?
  2. Si no se usa ampliamente, ¿cuáles son las barreras prácticas o técnicas para el uso?

Creo que la respuesta es que lo que estás describiendo derrota completamente el propósito de usar componentes de software preexistentes si necesitas encontrar y construir literalmente todo desde la fuente. En realidad, podría ser menos esfuerzo deshacerse por completo del sistema operativo, fingir que es 1960 y escribir su aplicación directamente en el microcódigo de la CPU.

Me gusta la seguridad más que la mayoría de los desarrolladores, pero me gusta f * eso .

235
Mike Ounsworth

La respuesta de Mike dice básicamente todo lo que tengo para ofrecer acerca de por qué esta es una mala idea desde una perspectiva de desarrollo (y, como dice el comentario de Ghedipunk, una característica de seguridad inutilizable no proporciona seguridad). Entonces, en cambio, voy a hablar sobre por qué desde una perspectiva de seguridad , nunca harías esto.

La respuesta es en realidad sorprendentemente simple: es una pérdida de tiempo y hay opciones estrictamente mejores. Cada estúpido doodad de IoT (recuerde, la "s" en "IoT" significa Seguro) que no se molesta en implementar funciones tan seguras como el infierno no iría con un enfoque como usted sugiere.

  1. Toda la idea simplemente no funcionará para restringir las llamadas al sistema. Un atacante solo puede establecer algunos registros e invocar un código de operación y un boom, están en el núcleo ejecutando la llamada de sistema de su elección; ¿A quién le importa cuál es su nombre simbólico? Claro, puede manipular la tabla syscall para complicar esto (si no le importa tener que volver a compilar todo y hacer que la depuración de su kernel personalizado sea una forma de infierno) pero es como ofuscar el sistema operativo en uso; ¿Por qué molestarse cuando hay tan pocos candidatos, de todos modos? Incluso si el atacante no quiere realizar ingeniería inversa del código existente en el sistema, la fuerza bruta debería ser posible a menos que el espacio de búsqueda de los índices de llamadas utilizables sea más amplio de lo que he visto en un sistema integrado.
  2. ¿Por qué ofuscar los nombres de comandos cuando puede hacerlos completamente inaccesibles? Un chroot no funcionará para las incorporaciones de Shell si está ejecutando un Shell , pero funciona bien para todo lo demás y En realidad, ¿por qué su aplicación en una caja diseñada para un solo propósito está ejecutando un shell? Quiero decir, las unidades de desarrollo tendrían una instalada, para fines de prueba, y tal vez eso no se elimine en su imagen minorista porque es perezoso o cree que lo necesitará nuevamente. Pero un atacante no podría ejecutarlo desde el contexto en el que se ejecuta su aplicación. Un simple chroot (o una caja de arena/cárcel/contenedor más complicada) puede hacer que el programa no pueda ejecutar, o incluso acceder, a cualquier archivo más allá de los necesarios para su trabajo.
  3. ¿Por qué ofuscar las API del núcleo cuando solo puede eliminar el acceso a ellas? Hay una serie de sistemas de sandboxing que pueden restringir las llamadas que puede realizar un proceso (o sus descendientes ... si se le permite crear alguno). Ver https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Si su objetivo es privar a un atacante de ls y cat, hay una alternativa aún mejor para la ofuscación: simplemente no instale esas utilidades.

Si bien no diría que este es un enfoque de implementación ampliamente , al menos es implementar. Por ejemplo, considere distroless , una colección de imágenes acoplables con prácticamente nada en ellas. Algunos de ellos (como el que está para ir) literalmente no tienen nada en ellos. Un ataque a un sistema que se ejecuta en dicho contenedor no puede obtener acceso a Shell porque no hay ningún Shell para ejecutar.

La única forma de obtener acceso de Shell atacando una aplicación en dicho contenedor es eludir el tiempo de ejecución del contenedor, que está diseñado para evitar precisamente eso.

Si bien di un ejemplo de una imagen acoplable, el mismo concepto se puede aplicar a los sistemas operativos en general. Por ejemplo, ls y cat son parte del paquete coreutils en Debian. Podrías correr apt-get remove coreutils y tenga la seguridad de que un atacante no podrá usar ls o cat como parte de un ataque. Por supuesto, esto significa que tampoco puede usarlos, y probablemente haya muchas otras cosas que dependen de coreutils que también tendrán que eliminarse, pero para un dispositivo incorporado o un servidor que solo hace una cosa eso puede estar bien.

El principio general es reducir la "superficie de ataque": mientras más "cosas" tenga un objetivo, más fácil será comprometerlo. El material podría ser puertos de red abiertos, líneas de código o binarios instalados. Si el objetivo es aumentar la seguridad, entonces eliminar todas las "cosas" innecesarias es un buen comienzo.

30
Phil Frost

Porque la ofuscación no es seguridad y porque la ofuscación del sistema operativo es básicamente una tontería.

Hay tantos sistemas operativos comunes y tantas formas de hacer conjeturas informadas. Si detecta que estoy ejecutando IIS o MSSQL Server, tiene una idea de qué sistema operativo se está ejecutando debajo.

Incluso si de alguna manera logro ejecutar una pila que no te dice nada sobre mi sistema operativo subyacente, y también enmascarar cualquier otro indicio (la huella digital es una cosa), todavía no he ganado mucho.

En cuanto a la seguridad, sabiendo que estoy ejecutando Linux, o incluso que estoy ejecutando Debian 8, no le da mucho en qué trabajar ni mucho de qué preocuparse. Si estoy bien endurecido y parchado, podrías saber lo que quieras. Si estoy en un nivel de parche que se aplicó ayer al museo de software, su conjunto de ataques me abrirá de par en par simplemente al probarlos todos, y ofuscar mi sistema operativo solo lo obliga a probar un par de exploits inútiles más. En un ataque automático, te ralentizará unos pocos segundos.

La ofuscación no funciona. Las personas pueden escanearlo, tomar huellas digitales o simplemente lanzar toda su biblioteca de exploits para ver qué funciona.

Si pierde tiempo en lo que podría haber gastado en el endurecimiento real, en realidad está perjudicando su seguridad.

El endurecimiento adecuado funciona. Dije anteriormente que "puedes saber lo que quieras" . Publiqué mi dirección IP y contraseña de root en conferencias de seguridad donde di un discurso. SSH con inicio de sesión raíz remoto y un conjunto de servicios habilitados. Máquina SELinux seriamente endurecida. Nadie ha logrado interrumpir mi discurso, aunque una persona logró soltar un archivo de texto en el directorio raíz cuando mi política aún no era perfecta.


Anexo: Su punto de partida fue una película. La ofuscación es un gran dispositivo de película porque una revelación como esa le dice a los espectadores que el héroe (o villano) encontró alguna información y, por lo tanto, está progresando. Es la computadora equivalente a averiguar dónde está la caja fuerte, a pesar de que todavía necesita el código. No importa si es objetivamente correcto, si transmite el mensaje emocional adecuado a la audiencia.

13
Tom

Para un ejemplo extremadamente extendido, Intel Management Engine, que tiene su propio sistema operativo, hace algo así, donde existe un mecanismo de actualización de firmware, pero el firmware debe estar en un formato muy específico cuyos detalles son confidenciales. Parece implicar la codificación de Huffman con parámetros desconocidos. De manera similar a su propuesta (que es básicamente cifrado simétrico de firmware), ME requiere modificaciones específicas en el momento de la preparación del firmware y tiene una desviación correspondiente de los mecanismos estándar en el momento de la ejecución.

7
Roman Odaisky

Lo que está describiendo se llama "Seguridad a través de la oscuridad" y es un antipatrón de seguridad ampliamente conocido . Lo que significa que no es una idea nueva, más bien es una vieja y mala idea, que las personas que no están iniciadas en filosofía de seguridad deben ser educadas para no caer en ellas.

Imagine que está diseñando una casa para ser segura, y pensó que la oscuridad era una estrategia prometedora. Todas las casas están construidas a partir de pasillos y habitaciones, puertas con pomos de puertas, interruptores de luz, etc. Como se conocen comúnmente, podría razonar que esto es inseguro ya que un intruso podría navegar fácilmente por los elementos de construcción conocidos. Puede intentar rediseñar los principios de construcción desde cero, reemplazar las perillas de las puertas con cubos de rubik, hacer techos de media altura para confundir al intruso, etc. Usted termina con una casa en la que es terrible vivir, no se puede mantener porque ningún contratista quiere nada que ver con eso, y lo peor de todo es que no sirve de nada porque cualquier intruso, una vez dentro, puede mirar a su alrededor con los ojos y usar su cerebro para resolverlo. Los hackers son adictos a los rompecabezas en el fondo.

La solución para asegurar su casa no es tener una construcción no estándar, es tener mejores cerraduras, ventanas seguras, un sistema de seguridad adecuado, etc. No desea ocultar su oro en un pasadizo secreto, porque eventualmente Abbot y Costello se apoyará en ese candelabro y lo abrirá accidentalmente. Ponga su oro en una caja fuerte con una buena combinación secreta y una alarma de manipulación. El equivalente de la computadora es tener acceso acreditado restringido por criptografía de clave pública, roles de acceso de usuario limitados, sistemas de monitoreo, reducción del área de superficie expuesta, mitigación del vector de amenaza de entrada, etc.

Los esfuerzos para hacer que un sistema informático sea más oscuro solo hacen que su sistema esté más alejado del soporte, más difícil de obtener seguridad parches, más difícil de usar de manera segura .

Editar: a veces, algunos seguridad a través de la oscuridad es aceptable cuando se usa además de la seguridad real. Un ejemplo común es ejecutar SSH en un puerto alto como 30000 algo. SSH está encriptado, y el acceso está detrás de una autenticación con credenciales, esa es su verdadera seguridad. Pero tenerlo en un puerto alto solo hace que sea menos notable comenzar si alguien está haciendo escaneos rápidos. Cualquier cosa más complicada que esto, como tratar de ofuscar su sistema operativo, solo lo convertiría en una pesadilla operativa, lo que haría que las medidas de seguridad reales (como estar actualizado en parches) sean más difíciles.

5
user1169420

Piensa ¡usabilidad

  • Intenta explicarle a tu nuevo administrador de sistemas que debe presionar ha7TrUO en lugar de Sudo, RRI6e29 en lugar de ls y así sucesivamente ... ¡Sí, hay una lista de traducción que solo tienes que aprender
  • ¡navegando por la red local no debe ser posible también: ¡debe mantener una lista en papel para mantener una vista general!

  • Si cambia el nombre de todos los comandos críticos, ¡tendrá que manejar esto para realizar la actualización del sistema!

  • Y como comentario de Nick225 , si intentas construir un sistema incorporado, entonces ofusca antes de publicar el producto final, tendrás que probar el producto final.

    • Tienes que crear ¡hecho en casa script para unir todo para ofuscación.
    • Si algo sale mal, la depuración será complicada.
    • Debe crear ¡hecho en casa scripts de desofuscación, para poder realizar algunas depuraciones.
    • La retroalimentación personalizada (con archivos de registro) tendrá que ser ¡también desofuscada.

    Al hacerlo, agregará una capa de trabajo importante con nuevos errores potenciales.

    Para muy pocas mejoras de seguridad, vea más

La oscuridad podría dañarse.

Piensa ¡nivel inferior

  • Incluso si intenta cambiar el nombre de los archivos, funcionar a nivel de aplicación y sistema operativo, todo esto utilizará ¡bibliotecas estándar a quién se llamará directamente si el atacante envía archivos ejecutables binarios. ¡Incluso podría considerar ofuscar todas las bibliotecas estándar! (Incluyendo sistema de archivos, protocolos de red ...)

  • Mientras usa el kernel no modificado, usarán ¡estándar variables y espacios de nombres. Entonces, tendrá que crear ¡versión ofuscada del núcleo ...

... ¡Luego une todo!

Bueno, incluso cuando todo está ofuscado, la aplicación tendrá que lidiar con internet. ¡La ofuscación no evitará errores conceptuales sobre esto!

Oscuridad Si no está en todos los niveles, no mejorará la seguridad.

Oscuridad total No es realmente posible, debido a la necesidad de utilizar protocolos estándar para poder tratar con Internet.

Piensa ¡licencia

Si planea distribuirGNU/Linux , debe compartir el código fuente como se describe en GNU GENERAL PUBLIC LICENSE GPLv y/o - LICENCIA PÚBLICA GENERAL MENOR DE GNU LGPLv (según la aplicación y las bibliotecas utilizadas). Esto implicará la publicación del método de ofuscación junto con cada producto distribuido.

Estrictamente respondiendo a sus dos preguntas:

Soy algo experto, pero con un enfoque muy pequeño. Trabajando en muchas infraestructuras diferentes de pequeñas empresas, he tomado algunas decisiones hace algunos años. La evolución y la historia parecen confirmar mis elecciones, pero es solo mi punto de vista personal.

¿La ofuscación del sistema operativo como se describe se usa ampliamente y simplemente no la he encontrado?

Así que realmente no sé en qué proporción se ofusca ¡ampliamente, pero no uso ¡seguridad por oscuridad = y recomiendo no.

Si no se usa ampliamente, ¿cuáles son las barreras prácticas o técnicas para el uso?

No hay barreras! Simplemente es contraproducente. El costo del tiempo se vuelve rápidamente gigantesco y la mejora de la seguridad es un atractivo.

Por supuesto, hay algunas cosas mínimas que hacer:

  • No inicie el servidor ssh si no es necesario
  • No instales Sudo, usa correcto ¡permisos, grupos y estructura coherente.
  • ¡Mantenga su infraestructura global actualizada !!!

Pequeña muestra when light come over obscurity

  • Asegurando ssh: bidireccional.

    • Mover el puerto ssh de 22 a 34567

      • ligero y rápido, pero

      si un atacante los encuentra, podría aplicar una fuerza bruta suave contra este puerto mucho tiempo hasta que el usuario final los descubra.

    • instalar firewall

      • Más fuerte, requiere más conocimiento, pero.

      Más seguro mientras está actualizado.

4
F. Hauri

¿No serían prácticamente inútiles clases enteras de ataques si el sistema operativo tuviera comandos ha7TrUO y RRI6e29 en lugar de Sudo y ls? Imagine a un pirata informático que de alguna manera obtuvo acceso a la raíz remota: ¿qué van a hacer si no conocen ningún comando?

Una mejor alternativa sería simplemente no instalar estos comandos en primer lugar. No creo que realmente necesites un Shell para ejecutar un kernel de Linux, aunque esto implica que tu proceso de inicio es algo más que sysV-init o systemd.

Como otros han señalado, sin embargo, es una compensación entre la seguridad y la facilidad de desarrollo. Desafortunadamente, muchos fabricantes de dispositivos se preocupan mucho más por lo último que por lo primero.

La implementación sería bastante fácil para los compiladores. Tome el caso más simple de "cambiar el nombre de esta función y todas las llamadas a ella". Podrías dar a un compilador de SO y a un compilador de aplicaciones los mismos nombres aleatorios y podrían comunicarse entre ellos. Pero incluso si la aplicación tiene poca seguridad y es vulnerable a la inyección de bash, tales ataques serían infructuosos.

No estoy seguro de que necesite la ayuda compilador en absoluto. Creo que en su mayoría puede lograr esto modificando enlazador ¹ para aplicar una aleatorización a todos los nombres de símbolos. Probablemente, basta con aplicar una función hash con una sal que solo el fabricante conoce. No estoy seguro de que incluso necesite el código fuente para hacer esto, es decir, yo piense podría aplicar el cambio al código ya compilado.

(¹ Creo que esto es una mentira. Es posible que deba modificar el código objeto para reemplazar los nombres de los símbolos, pero esto se parece más al nivel de ensamblador, es decir, a) no está haciendo todo los hard bits de compilación C/C++/etc. código yb) no necesita C/C++/cualquier código fuente. OTOH No estoy seguro de que pueda hacer este tipo de cosas si el código de su dispositivo es algo así como Python).

Sin embargo, todavía hay alguna posibilidad de aplicar ingeniería inversa al proceso y, además, esto puede violar la GPL² (especialmente la GPLv3) a menos que se entregue la sal, lo que anularía el propósito.

De hecho, "debido a la GPL" es probablemente la razón principal por la que no ve esto; sería difícil de implementar de una manera que sea realmente útil además de hacer que cada dispositivo sea diferente. OTOH, eso al menos significaría que los atacantes solo pueden atacar dispositivos específicos en lugar de poder explotar una vulnerabilidad en "any dispositivo que ejecuta Linux x.y.z".

(² Por simplicidad, solo usaré "GPL" en todas partes, pero tenga en cuenta que esto generalmente se aplica incluso para L cosas de GPL.)

Dicho esto, tenga en cuenta que la GPL no requiere que publique la sal porque "modificó" las fuentes. Si la aleatorización del nombre del símbolo ocurre en tiempo de compilación, usted no modificó las fuentes. La razón por la que necesitaría publicar la sal es porque la GPL requiere que los usuarios puedan sustituir sus propias versiones de una biblioteca de GPL, lo que no pueden hacer a menos que conozcan la sal. (Como se señaló, es posible que pueda resolver esto con GPLv2, pero los efectos técnicos son similares a "ejecutar solo software firmado", que GPLv3 se escribió específicamente para abordarlo).


En última instancia, podría haber una ventaja alguna aquí, pero no va a hacer que ningún sistema particular sea notablemente más seguro (es bien sabido que "seguridad a través de la oscuridad" generalmente no es seguridad en absoluto). Lo que puede lograr es hacer que sea más difícil apuntar a muchos sistemas a través de un solo vector.

4
Matthew

Divulgación justa: soy el CTO de una compañía que construye precisamente esto. Elimina el sesgo para eso todo lo que quieras.

Es IS de hecho posible construir completamente un núcleo del sistema, controladores de dispositivos, paquetes, la pila completa POR host, varias veces al día, y puede ser bastante efectivo. Eso es exactamente lo que hacemos , y ayudamos a nuestros clientes a hacerlo. No somos los únicos, podemos inferir que al menos Google también hace esto para todas sus máquinas (referencia próximamente).

Ahora, si tuviera la capacidad de reconstruir por máquina desde cero, ¿cuáles son algunas de las cosas que puede cambiar?

El Proyecto de autoprotección del núcleo ya lo permite mediante la reordenación aleatoria de las estructuras del núcleo: https://lwn.net/Articles/722293/ . Este artículo también apunta al famoso intercambio donde Linus Torvalds lo llama teatro de seguridad, pero el autor del proyecto (que trabaja en Google) comenta: "Bueno, Facebook y Google no publican sus compilaciones de kernel. :)"

Esto lleva a creer en la inferencia de que al menos Google hace esto y lo considera útil. ¿Podemos hacer MÁS tipos de codificación en un conjunto cerrado? En el nivel más fundamental, ¿por qué no se ejecuta un virus de Windows en Linux o Mac? Porque los formatos son diferentes. Todo es x86 debajo y, sin embargo, no es lo mismo. Bueno, ¿y si dos Linux fueran diferentes de manera similar? Windows vs Linux no es "ofuscación" simplemente porque no tenemos muchas maneras de hacer que Linux sea tan diferente como Windows para Linux. Pero no es imposible, y ni siquiera es tan difícil. Tome el enfoque de KSPP y aplíquelo a las llamadas al sistema, luego vuelva a compilar todo en la parte superior contra esas llamadas al sistema. Va a ser muy difícil de romper, al menos no en un sobrevuelo.

Sin embargo, su pregunta era sobre el cambio de nombre de los símbolos (nombres de ejecutables, bibliotecas, etc.) Esto tiene dos aspectos: (a) ¿es útil? (b) ¿Se puede hacer de manera confiable?

Estábamos buscando una manera de resolver PHP inyecciones de código de una vez por todas. A pesar de lo que HackerNews te haría creer , PHP las inyecciones de código no son un problema resuelto fuera de los tableros de mensajes de Internet. Vida real PHP desarrolladores, administradores y usuarios están expuestos a un número continuo de inyecciones de código.

Así que nos propusimos probar Polyscripting (código abierto permisivo con licencia MIT): https://github.com/polyverse/polyscripted-php

Compartimos esto públicamente para solicitar comentarios, y ejecutamos dos sitios web, polyscripted.com y nonpolyscripted.com , que hacen exactamente lo que esperarías según sus nombres. También contratamos pentesters para tratar de romperlo.

Y recién estoy comenzando a experimentar con bibliotecas compartidas ejecutables y cambio de nombre de símbolos exportados en un conjunto cerrado (en un contenedor acoplable, por ejemplo). Personalmente no creo que esto agregue tanto valor, pero ¿agregará un poco? Creo que sí. Entonces todo se reduce al costo. Si puede obtener poco valor por un costo aún más pequeño, ¿por qué no hacerlo? Esa es exactamente la razón por la que todos tenemos ASLR: no es exactamente la mejor defensa desde el pan rebanado, pero si ya tiene un código reubicable y lo va a reordenar de todos modos, ¿por qué NO llevarlo al límite y aleatorizarlo?

En resumen, el enfoque que está describiendo lo están intentando muchas personas (incluidos Google, Facebook, el kernel de Linux, etc.), junto con muchos académicos en el campo de Moving Target Defense y un puñado de empresas como la nuestra que ' estamos tratando de hacerlo trivialmente consumible como ASLR.

2
Archis Gore

Diría cómo veo esto desde el punto de vista del hacker.

Definitivamente, si cambia el nombre de todas las utilidades, me resultará mucho más difícil y menos cómodo, pero ¿qué podría hacer?

  1. Si ya tuviera acceso a Shell en el sistema, simplemente subiría busybox (todas las utilidades básicas en un binario) o el conjunto completo de binarios que necesito para las operaciones básicas.

  2. Para escalar aún más los privilegios, es posible que deba buscar binarios suid-root, y solo hay algunos de ellos (Sudo, mount, etc.). El hacker no puede cargar dichos archivos (a menos que ya sea root). Mi sencillo sistema Linux pequeño tiene solo 24 binarios suid. Muy fácil de probar cada uno de ellos manualmente.

Pero de todos modos, estoy de acuerdo, esto haría que piratear esta caja sea más difícil. Sería doloroso usar (piratear) este sistema, pero es posible. Y el hacker funciona en el sistema por hora, día o mes ... pero el administrador/usuario puede trabajar en el sistema durante años y no puede recordar los nombres ha7TrUO y RRI6e29. Tal vez nadie intente hackear el sistema, pero el administrador sufrirá todos los días.

Pero ... si hace que la seguridad sea demasiado alta pero incómoda para el usuario/administrador, de hecho, a menudo, hace que la seguridad sea más baja. Al igual que si aplica contraseñas complejas con más de 20 caracteres, lo más probable es que las contraseñas se escriban en notas post-it en el monitor. Si va a hacer que el sistema esté tan ofuscado, será muy difícil trabajar en él para los buenos usuarios. Y tendrán que hacer algunas cosas para facilitarles la vida. Por ejemplo, pueden cargar su binario busybox. Temprorario Y lo olvidarán o lo dejarán allí intencionalmente (porque planean usarlo poco después).

1
yaroslaff

En realidad sucede, porque las conexiones ssh están encriptadas. Cambiar los nombres de algunos binarios centrales no logra nada más que esto. También causaría mucho caos: p. cualquier script que dependa de estas utilidades quedará inutilizable, o necesitará tener algún tipo de "desobfuscator" proxy, que seguramente terminaría como un vector de ataque. Sin embargo, he visto algunos servidores en la naturaleza que no permiten el inicio de sesión raíz, lo que obliga a usar Sudo en su lugar. Los nombres de usuario de los sudoers permanecen algo secretos. No estoy seguro de lo seguro que es, pero no soy un experto.

0
galaktycznyseba

¿Por qué no todas las puertas tienen diez cerraduras, de las cuales solo una funcionó para llaves o ganzúas? Respuesta: sobre todo la molestia no vale los diez segundos extra del tiempo de un ladrón.

Si hubiera millones de sistemas operativos de código fuente únicocreado de forma aislada, la adquisición podría ser común. Sin embargo, como cuestión práctica, tenemos aproximadamente cuatro bases de código únicas de uso común: todas filtran información sobre sí mismas por temporización de eventos, y para varias funciones del sistema operativo de bajo nivel donde los fabricantes de chips dan secuencias de código de bits de máquina prescritas para activar o acceder a ciertas funciones de la CPU. probablemente todos tengan secuencias cortas que contengan exactamente el mismo código.

0
Dusty