Tag: #gentoo-es

Como me quedé con ganas de seguir tratando de este tema, permítanme contarles un poco de historia, teoría y práctica sobre las vulnerabilidaes. Todos hemos oído a estas alturas que  los fallos de seguridad pueden costar mucho, todos sabemos que debemos mantener nuestro software actualizado, todos sabemos que muchas actualizaciones se producen por errores de seguridad. Pero hoy les contaré un poco sobre cómo es que se encuentran y se explotan dichos errores :) Pero antes de esto vamos a aclarar unos cuantos detalles para poder tener un mejor panorama.

Antes de empezar

Primero quiero decirles que nos vamos a centrar en la primer vulnerabilidad que aprendí a explotar, los conocidos Buffer Overflows, en esta vulnerabilidad aprovechamos una falta de verificación en la memoria para hacer cosas divertidas :) Pero vamos a aclarar un poco más al respecto.

Esto no va a ser un escenario del mundo real

No puedo darme el lujo de enseñarles a romper cualquier programa que vean :) primero porque es peligroso para sus computadoras, segundo porque eso me tomaría más de mi acostumbrada cuota de palabras.

Nos vamos de viaje a los 80s

Esto que les voy a mostrar lo puedo hacer en mi laptop, pero no quiere decir que se pueda realizar hoy por hoy de manera sencilla :) muchos de estos conceptos ya han sido explotados tantas veces que han surgido nuevos métodos de protección y nuevos métodos para evadirlos :P pero eso nos regresa al mismo lugar, falta espacio para poder contar todo eso :)

Tal vez no funcione en tu procesador

Aunque voy a usar un ejemplo muy simple, quiero que desde el principio quede bastante claro que los pormenores de esto son tantos y tan variados que así como puede salirte igual que a mí, si deseas intentarlo, también puede que no se consiga el efecto deseado :) Pero ya se imaginarán que eso no puedo explicarlo en este espacio, sobre todo porque con esta introducción ya me llevé más de 300 palabras, así que directo a lo nuestro.

Qué es un Buffer Overflow

Para responder esto primero tenemos que comprender la primera mitad de esta combinación.

Buffers

Como todo se trata de memoria en un equipo computacional, es lógico que debe existir algún tipo de contenedor de información. Cuando hablamos de inputs o outputs, llegamos directamente al concepto de buffers. Para hacerlo corto, un buffer es un espacio de memoria de tamaño definido en el que vamos a almacenar una cantidad de información, simple :)

Los overflow ocurren, como su nombre lo indica, cuando un buffer se llena con más información de la que puede aguantar. Pero, ¿por qué es esto importante?

Stack

También conocido como pilas, son un tipo de datos abstracto en el que podemos apilar información, su principal característica es que cuentan con un ordenamiento LIFO (Last In First Out). Pensemos por un segundo en una pila de platos, nosotros los ponemos por encima uno a uno, y luego los sacamos uno a uno desde arriba, esto hace que el último plato que hayamos puesto (el que se encuentra hasta arriba) sea el primer plato que vamos a sacar, evidentemente si solo podemos sacar un plato a la vez y decidimos hacerlo en ese orden :P.

Ahora que ya conocen estos dos conceptos, tenemos que ordenarlos. Las pilas son importantes porque cada programa que ejecutamos tiene su propia pila de ejecución. Pero esta pila tiene una característica particular, crece hacia abajo. Lo único que deben saber de esto es que mientras un programa se ejecuta, cuando una función es llamada, la pila pasa de un número X de memoria a un número (X-n). Pero para poder seguir debemos comprender un concepto más.

Punteros

Este es un concepto que vuelve loco a muchos programadores cuando empiezan en el mundo de C, a decir verdad la gran potencia de la programación en C se debe en parte al uso de punteros. Para hacerlo simple, un puntero apunta a una dirección de memoria. Esto suena complejo, pero no lo es tanto, todos tenemos RAM en nuestras máquinas ¿cierto? Pues esta puede definirse como un arreglo consecutivo de bloques, normalmente dichas ubicaciones se expresan en números hexadecimales ( del 0 a 9 y luego de eso de A a F, como por ejemplo 0x0, 0x1, 0x6, 0xA, 0xF, 0x10). Aquí como nota curiosa, 0x10 NO es igual a 10 :P si lo convertimos al orden decimal sería lo mismo que decir 15. Esto es algo que también confunde a más de uno al principio, pero vamos a lo nuestro.

Registros

Los procesadores trabajan con una serie de registros, los cuales funcionan para transmitir ubicacioines desde la memoria física al procesador, para arquitecturas que usan 64-bits, la cantidad de registros es grande y difícil de describir aquí, pero para hacernos a la idea, los registros son como punteros, indican entre otras cosas, un espacio en memoria (ubicación).

Ahora la práctica

Sé que ha sido mucha información para procesar hasta ahora, pero en realidad son temas algo complejos que intento explicar de manera muy simple, vamos a ver un pequeño programa que usa buffers y lo vamos a romper para entender esto de los overflows, evidentemente este no es un programa real, y vamos a “evadir” muchas de las contramedidas que se usan hoy en día, solo para mostrar cómo se hacían las cosas antes :) y porque algunos de estos principios son necesarios para poder aprender cosas más complejas ;)

GDB

Un gran programa que es sin duda uno de los más usados por programadores en  C. Entre sus múltiples virtudes tenemos el hecho de que nos permite ver todo esto que hemos estado conversando hasta ahora, registros, la pila, buffers, etc :) Vamos a ver el programa que vamos a usar para nuestro ejemplo.

retinput.c

Este es un programa bastante simple, vamos a usar la librería stdio.h para poder obtener información y mostrarla en un terminal. Podemos ver una función llamada return_input la cual genera un buffer llamado array, que tiene una longitud de 30 bytes (el tipo de dato char es de 1 byte de largo).

La función gets(array); solicita información por consola y la función printf() devuelve el contenido de array y lo muestra en pantalla.

Todo programa escrito en C comienza por la función main(), esta solo se va a encargar de llamar a return_input, ahora vamos a compilar el programa.

Vamos a desprender un poco de lo que acabo de hacer. La opción -ggdb le indica a gcc que tiene que compilar el programa con información para que gdb sea capaz de realizar un debug adecuado. -fno-stack-protector es una opción que evidentemente no deberíamos estar usando, pero que vamos a usar porque en caso contrario nos sería posible genererar el buffer overflow en el stack. Al final he probado el resultado. ./a.out solo ejecuta lo que acabo de compilar, me pide información y la devuele. Funcionando :)

Advertencias

Otra nota aquí. ¿Pueden ver las advertencias? claramente es algo a tener en cuenta cuando trabajamos con código o compilamos, esta es un poco obvia y son pocos los programas que hoy en día tienen la función gets() en el código. Una ventaja de Gentoo es que al compilar cada programa, puedo ver lo que puede estar mal, un programa “ideal” no debería tenerlas, pero les sorprendería cuántos programas grandes tienen estas advertencias porque simplemente son MUY grandes y es difícil mantener el rastro de las funciones peligrosas cuando son muchas advertencias al mismo tiempo. Ahora si sigamos

Depurando el programa

Ahora, esta parte puede ser un poco confusa, pero como ya he escrito bastante, no puedo darme el lujo de explicarlo todo, así que perdón si ven que voy muy rápido :)

Desarmando el código

Vamos a empezar viendo nuestro programa compilado en lenguaje máquina.

Este es el código de nuestra función main en Assembly, esto es lo que entiende nuestro procesador, la línea de la izquierda es la dirección física en memoria, el <+n> se conoce como offset, básicamente la distancia desde el principio de la función (main) hasta esa instrucción (conocido como opcode). Luego vemos el tipo de instrucción (push/mov/callq…) y uno o más registros. Resumido podemos decir que es la indicación seguida de la fuente/origen y el destino. <return_input> hace referencia a nuestra segunda función, vamos a darle un vistazo.

Return_input

Esta es un poco más compleja, pero solo quiero que revisen un par de cosas, existe un label llamado <gets@plt> y un último opcode llamado retq que indica el final de la función. Vamos a poner un par de breakpoints, uno en la función gets y otro en el retq.

Run

Ahora vamos a correr el programa para ver cómo empieza a comenzar la acción.

Podemos ver que aparece una pequeña flecha que indica el opcode donde nos encontramos, quiero que tengan en cuenta la dirección 0x000055555555469b, esta es la dirección que se encuentra tras la llamada a return_input en la función main , esto es importante puesto que ahí es donde debería regresar el programa cuando acabe de recibir el input, vamos a entrar en la función. Ahora vamos a revisar la memoria antes de entrar a la función gets.

Les he vuelto a poner la función main arriba, y he resaltado el código al que me refería, como pueden ver, debido al endianess se ha separado en dos segmentos, quiero que tengan en cuenta la dirección 0x7fffffffdbf0 (la primera de la izquierda tras el commando x/20x $rsp) puesto que esta es la ubicación que tenemos que usar para revisar el resultado de gets, sigamos:

Rompiendo el programa

He resaltado esos 0x44444444porque son la representación de nuestras Ds :) ahora hemos empezado a agregar input al programa, y como pueden apreciar, estamos a solo dos líneas de nuestra dirección deseada, vamos a llenarlo hasta estar justo antes de las direcciones que resaltamos en el paso anterior.

Cambiando la ruta de retorno

Ahora que hemos logrado entrar en esta sección del código donde indica el retorno de la función, vamos a ver qué sucede si cambiamos la direacción :) en lugar de ir a la ubicación del opcode que sigue al que teníamos hace un momento, ¿qué les parece si regreamos a return_input? Pero para esto, es necesario escribir en binario la direacción que deseamos, vamos a hacerlo con la función printf de bash :)

Ahora hemos recibido dos veces la información :D seguramente el programa no estaba hecho para eso, pero hemos conseguido romper el código y hacer que repita algo que no se suponía que haga.

Reflexiones

Este simple cambio puede considerarse un exploit muy básico :) ha logrado romper el programa y hacer algo que nosotros deseamos que haga.

Este es solo el primer paso en una casi infinita lista de cosas por ver y agregar, existen formas de agregar más cosas que simplemente repetir una orden, pero esta vez he escrito mucho y todo lo relacionado a shellcoding es un tema para escribir más que artículos, libros completos diría yo. Disculpen si no he podido ahondar un poco más en temas que me hubieran gustado, pero seguro ya habrá oportunidad :) Saludos y gracias por llegar hasta aquí.

Gracias a Guillermo por sugerir el tema para este post, es algo que si bien yo tengo la suerte de vivir, no sé si se habrá escrito al respecto aquí en el pasado, pero de todas maneras volveré a sacarlo a la luz para poder compartir un poco con ustedes :)

El arte de ser hacker

Uno de los libros que más me han llamado la atención sobre este tema es sin lugar a dudas Hacking: The Art of Exploitation, de Jon Erickson. Es una joya para todo aquel que quiera sumergirse en este mundo de los verdaderos hackers. Y tal como está en el libro, me permitiré tomar la primer pregunta que explotó mi mente al momento de leerlo.  

La esencia de un hacker

Usando cada uno de los siguientes números 1,3,4 y 6 exactamente una vez con cualquiera de las operaciones básicas (sumar,restar,multiplicar,dividir) conseguir un total de 24. Cada número debe ser usado solo una vez y el orden depende de ustedes. Por ejemplo:

3 * ( 4 + 6 ) + 1 = 31

Correcto en sintaxis, pero incorrecto en resultado.

Debo admitir que yo no pude resolver el problema hasta que terminé de leer el libro y vi la solución en la última página. Pero básicamente esta es la esencia de un hacker, poder ver lo que otros no ven.

Los primeros hackers

Un grupo de estudiantes del MIT (Massachusetts Institute of Technology), cerca de los años 50, recibió un donativo de equipos telefónicos, con estas piezas, ellos desarrollaron un sistema que permitía gestionar la línea de comunicación a distancia por medio de llamadas especiales. Ellos hicieron un descubrimiento usando la tecnología que ya existía, pero usándola de formas que pocos o nadie habían visto hasta entonces. Estos fueron los primeros hackers.

Una comunidad de respaldo

Hoy en día existen muchos exámenes de “certificación” para convertirse en “hacker”, pero la realidad es que uno no llegará a ser un verdadero hacker hasta que un miembro de la comunidad que ya lo sea esté de acuerdo en llamarnos por ese calificativo. Uno de los caminos para esto es poder aportar algo útil a la comunidad. Muchos hackers son en última instancia programadores de bajo nivel, puesto que conocen de manera profunda cómo funcionan los equipos, a nivel de memoria y sistema operativo.

Este conocimiento les permite encontrar vulnerabilidades

Esto es como cuando aprendemos por primera vez matemáticas, cuando eramos niños, necesitabamos de alguien que nos explique y enseñe los símbolos y las formas, y esto sucede en cierta manera con los programadores también, un verdadero hacker es aquel que conoce estos símbolos y formas, y nos señala cuando ve que hemos fallado al usarlos (una vulnerabilidad). Y como el mismo Linus Torvalds (otro gran hacker, en el sentido real de la palabra) las “vulnerabilidades” son solamente bugs. Con esto refiriéndose a que no son más que errores de programación, aunque tal vez con otro tipo de consecuencias a los bugs más comunes.

Los hackers NO necesariamente son delincuentes

Esto es cierto hasta cierto punto, vamos a pensarlo por un momento. Cuando un verdadero hacker desea conocer algo, este pone a prueba hasta el más mínimo detalle del sistema, con todos sus conocimientos le es posible esquivar, o evitar controles de acceso, o modificar órdenes para realizar otras tareas, o incluso convertir el programa en otra cosa. Pero ¿de dónde nace esto?

Motivaciones de un hacker

Estas pueden ir en un gran abanico de posibilidades, algunos (la mayoría de los verdaderos hackers) descubren lo que descubren por un mero placer intelectual, disfrutan el desafío de encontrar estos ‘vacíos’. Otros lo hacne por ego, puseto que desean poder decir que son los mejores en algo. Pero es innegable que alguno o muchos de ellos también estarán ahí por el dinero, puesto que controlar cosas que son incontrolables para la mayoría de personas es ciertamente una herramienta que puede producir mucho dinero. Es este el motivo por el que podemos decir que los hackers no necesariamente son malos, pero ojo con el necesariamente.

3 tipos de hacker hoy en día

Hoy por hoy podemos encontrar 3 conocidos grupos de hackers, distinguidos de manera curiosa por el tipo de sombrero que usan: white, black y grey hat. En pocas palabras y con una analogía que ya hemos tocado con anterioridad, encontramos que los blancos son los buenos, los negros son los malos y los grises están en un punto medio en el que usan sus habilidades para ser o buenos o malos, dependiendo de la situación. Pero hay un último término, mucho más utilizado en círculos de hackers reales.

Script-kiddie

¿Qué es un script-kiddie? Como su nombre lo dice, es un “niño” a la vista de los verdaderos hackers que solo usa scripts para su beneficio. Y aquí hay que hacer una distinción muy grande,

Estar certificado en seguridad informática NO te hace necesariamente un hacker.

Y este es un punto de vista personal, así como un hacker  puede ni siquiera tener certificaciones y seguir siendo uno. Pero vamos a ver por qué digo esto. Muchos exámenes de certificación/cursos/etc te enseñan los pasos de un pentesting exitoso, te enseñan la teoría de tipos de vulnerabilidad, te introducen en el mundo de la seguridad informática como si fueras versado en el tema. Pero la realidad es que hasta que no hagas un aporte sustancial a la comunidad hacker, esto quiere decir, hasta que no crees una herramienta que demuestre ser útil para los hackers, no eres uno. Así de simple y sencillo.

No importa qué tan bien puedas usar nmap, o zen, o incluso metasploit, mientras no seas capaz de aportar un exploit real, o una herramienta de reconocimiento real, NO eres un hacker, solo un script-kiddie, y no importa que tengas N certificaciones en seguridad, eso no lo va a cambiar.

Los hackers hacen de este un mundo mejor

Gracias a ellos es que tenemos tecnología en continuo movimiento. El kernel es un gran ejemplo de esto, son cientos de mentes muy versadas en el tema, que crean código que sirve no solo a la comunidad hacker, sino a todo el mundo. Pero no solo esto, si no fuera por ellos, la tecnología se estancaría en puntos donde la gente no querría seguir desarrollando, esto porque al encontrar vulnerabilidades, los hackers ayudan a motivar a los desarrolladores a escribir mejor código, y a su vez, este mejor código motiva a los hackers a demostrar que son aún mejores, generando un círculo virtuoso en el medio.

Reflexión final

Bueno, ya voy a cortar, así sin más, porque he visto que me estoy extendiendo y aunque me gustaría explicar un poco sobre cómo encontrar un exploit, eso tendrá que ser para otra ocasión. Yo personalmente me considero un ‘script-kiddie’ todavía, puesto que si bien he encontrado una que otra vulnerabilidad por ahí e incluso he podido asignar CVEs a estas, todavía no he creado mi propio exploit o herramienta para poner a disposición de la comunidad, pero espero que eso cambie en poco tiempo ;) Sin más que agregar, muchas gracias por su tiempo, saludos.Qué significa realmente ‘hacker’