seguridad – ChrisADR

cómo proteger tu equipo de ataques

Muy buenas con todos, antes de entrar al hardening de tu equipo, quiero contarles que el installador que estoy desarrollando para Gentoo ya está en su fase pre-alpha :D esto quiere decir que el prototipo es lo suficientemente robusto como para poder ser probado por otros usuarios, pero al mismo tiempo todavía falta mucho por recorrer, y el feedback de estas etapas (pre-alpha,alpha,beta) ayudará a definir rasgos importantes sobre el proceso :) Para los interesados…

https://github.com/ChrisADR/installer

PS. todavía tengo la versión exclusivamente en inglés, pero espero que para el beta ya tenga su traducción a español también (estoy aprendiendo esto de las traducciones en tiempo de ejecución en python, así que todavía hay mucho por descubrir)

Hardening

Cuando hablamos de hardening, nos referimos a una gran variedad de acciones o procedimientos que dificultan el acceso a un sistema informático, o red de sistemas. Precisamente por eso es que es un tema vasto y lleno de matices y detalles. En este artículo voy a listar algunas de las cosas más importantes o recomendables para tener en cuenta al momento de proteger un sistema, intentaré ir de lo más crítico a lo menos crítico, pero sin ahondar mucho en el tema puesto que cada uno de estos puntos sería motivo de un artículo propio.

Acceso físico

Este es sin dudas el primer y más importante problema de los equipos, puesto que si el atacante cuenta con fácil acceso físico al equipo, ya puede contarse como un equipo perdido. Esto es verdad tanto en grandes centros de data como en laptops dentro de una empresa. Una de las principales medidas de protección para este problema son las claves a nivel de BIOS, para todos aquellos a los que suene nuevo esto, es posible poner una clave al acceso físico de la BIOS, de esta manera si alguien quiere modificar los parámetros de inicio de sesión y arrancar el equipo desde un sistema live, no será trabajo sencillo.

Ahora bien, esto es algo básico y ciertamente funciona si es realmente requerido, yo he estado en varias empresas en las que no importa esto, porque creen que el “guardia” de seguridad de la puerta es más que suficiente para poder evitar el acceso físico. Pero vamos a un punto un poco más avanzado.

LUKS

Supongamos por un segundo que un “atacante” ya ha conseguido acceso físico al equipo, el siguiente paso es cifrar cada disco duro y partición existente. LUKS (Linux Unified Key Setup) es una especificación de cifrado, entre otras cosas LUKS permite cifrar con clave una partición, de esta manera, al iniciar el sistema si no se conoce la clave, la partición no puede ser montada ni leída.

Paranoia

Ciertamente existe gente que necesita un nivel “máximo” de seguridad, y esto lleva a resguardar hasta el aspecto más mínimo del sistema, pues bien, este aspecto llega a su cúspide en el kernel. El kernel de linux es la manera en la que tu software va a interactuar con el hardware, si tu evitas que tu software “vea” al hardware, este no podrá hacer daño al equipo. Para poner un ejemplo, todos conocemos lo “peligrosos” que son los USB con vírus cuando hablamos de Windows, pues ciertamente los usb pueden contener código en linux que podría o no ser perjudicial para un sistema, si hacemos que el kernel solo reconozca el tipo de usb (firmware) que deseamos, cualquier otro tipo de USB simplemente sería obviado por nuestro equipo, algo ciertamente un poco extremo, pero podría servir dependiendo de las circunstancias.

Servicios

Cuando hablamos de servicios, la primera palabra que me viene a la mente es “supervisión”, y esto es algo bastante importante, puesto que una de las primeras cosas que hace un atacante al entrar a un sistema es mantener la conexión. Realizar análisis periódicos de las conexiones entrantes y sobre todo salientes es algo muy importante en un sistema.

Iptables

Ahora bien, todos hemos oído sobre iptables, es una herramienta que permite generar reglas de ingreso y salida de data a nivel de kernel, esto es ciertamente útil, pero también es un arma de doble filo. Muchas personas creen que por tener el “firewall” ya están libres de cualquier tipo de ingreso o salida del sistema, pero nada más alejado de la realidad, esto solo puede servir de efecto placebo en muchos casos. Es conocido que los firewalls funcionan a base de reglas, y estas ciertamente pueden ser evitadas o engañadas para permitir transportar data por puertos y servicios por los cuales las reglas considerarían que es algo “permitido”, solo es cuestión de creatividad :)

Estabilidad vs rolling-release

Ahora este es un punto bastante polémico en muchos lugares o situaciones, pero permítanme explicar mi punto de vista. Como miembro de un equipo de seguridad que vela por muchos de los problemas de la rama estable de nuestra distribución, estoy al tanto de muchas, casi todas las vulnerabilidades existentes en los equipos Gentoo de nuestros usuarios. Ahora bien, distribuciones como Debian, RedHat, SUSE, Ubuntu y muchas otras pasan por lo mismo, y sus tiempos de reacción pueden variar dependiendo de muchas circunstancias.

Vayamos a un ejemplo claro, seguro todos han oído hablar de Meltdown, Spectre y toda una serie de noticias que han volado por internet en estos días, pues bien, la rama más “rolling-release” del kernel ya está parchada, el problema radica en llevar esas correcciones a kernels anteriores, ciertamente el “backporting” es un trabajo pesado y difícil. Ahora bien, después de eso, todavía tienen que ser probados por los desarrolladores de la distribución, y una vez que se han completado las pruebas, recién estará a disposición de los usuarios normales. ¿A qué quiero llegar con esto? A que el modelo rolling-release nos exige conocer más sobre el sistema y formas de rescatarlo si algo falla, pero eso es bueno, porque mantener la pasividad absoluta en el sistema tiene varios efectos negativos tanto para quien lo administra como para los usuarios.

Conoce tu software

Este es un adicional bastante valioso al momento de administrar, cosas tan simples como subscribirse a las noticias del software que utilizas puede ayudar a conocer de antemano los avisos de seguridad, de esta manera se puede generar un plan de reacción y al mismo tiempo ver cuánto tiempo toma para cada distribución resolver los problemas, siempre es mejor se proactivo en estos temas porque más del 70% de los ataques a empresas se llevan a cabo por software no actualizado.

Reflexión

Cuando la gente habla de hardening, muchas veces se cree que un equipo “resguardado” es a prueba de todo, y no hay nada más falso. Como su traducción literal lo indica, hardening implica hacer las cosas más difíciles, NO imposibles… pero muchas veces mucha gente piensa que esto conlleva magia oscura y muchos trucos como los honeypots… esto es un adicional, pero si no se puede con lo más básico como mantener actualizado un software o un lenguaje de programación… no existe necesidad de crear redes fantasma y equipos con contramedidas… lo digo porque he visto varias empresas donde preguntan por versiones de PHP 4 a 5 (evidentemente descontinuadas)… cosas que hoy por hoy son conocidas por tener cientos sino miles de fallas de seguridad, pero si la empresa no puede seguir el ritmo de la tecnología, pues de nada sirve que hagan lo demás.

Además, si todos estamos usando software libre o abierto, el tiempo de reacción para los errores de seguridad suele ser bastante corto, el problema viene cuando estamos tratando con software privativo, pero eso lo dejo para otro artículo que sigo esperando poder escribir pronto.

Muchas gracias por llegar hasta aquí :) saludos

La siguiente generación de ciberdelincuentes

Muy buenas con todos, un título más que sugestivo, y quiero empezar con este pequeño video que vi hace un buen tiempo, una de esas joyas que te hacen desconfiar de la tecnología y te ponen la piel de gallina.

Pese a su inofensivo aspecto, este video es sin duda algo que todos nosotros como personas relacionadas al TI debemos temer y conocer. Pero vamos a revisar unos pocos detalles antes.

Mar.IO

El autor del video nos cuenta la historia del jugador que ha conseguido vencer ese nivel del tan conocido juego Super Mario World. En el proceso nos explica que dicho jugador no es humano, más bien un programa de computadora que ha conseguido aprender por su cuenta el proceso del juego.

Neuroevolución

Este es el proceso que ha seguido Mar.io desde no cononcer absolutamente nada sobre el juego a completar exitosamente el nivel. Este proceso emula a los cerebros humanos y genera una red neural. Dicha red se puede apreciar en la parte superior derecha de Mar.io y es la que se genera tras una larga secuencia de intentos y errores.

Resultado

Tras 24 horas de evolución neuronal, Mar.io ha sido capaz de completar exitosamente el nivel, esto debido a una serie de generaciones que han aprendido que el camino a seguir está a la derecha, que existen cosas que pueden lastimar a Mar.io y que puede evitarlas con comandos como saltar y demás.

Todo está en los números

Si han visto el video completo sabrán que existe un diagrama en el que se muestra una línea azul (4:06). Este cuadro muestra el fitness alcanzado en cada generación. Fitness es un resultado que se obtiene de una función que toma, entre otras cosas, la distancia y tiempo que demora Mar.io en morir. Como pueden ver, existen puntos donde se estanca en su evolución, pero eventualmente encuentra la solución y sigue evolucionando. Tras 32 generaciones de Mar.ios se consigue el objetivo de completar el nivel.

¿Qué tiene que ver con seguridad?

Muchos ya lo estarán preguntando a estas alturas, pero creo que la respuesta es más que evidente, cambiemos un poco de contexto a Mar.io, supongamos que en lugar de jugar su inofensivo juego, le entregamos una computadora con mmm… ¿Kali Linux?

Kali Linux

Todo buen profesional de TI debe conocer este nombre, así como Ubuntu es sinónimo de computadoras de mesa y los nombres Red Hat y SUSE grandes empresas que giran en torno a Linux. Lo primero que suele venir a la mente de muchos cuando hablamos de seguridad informática es Kali Linux.

Simplifica el pentesting

Para los que hemos jugado un poco con la distro, sabemos que Kali simplifica mucho los pasos del pentesting, puesto que nos entrega una suite completa de herramientas que podemos empezar a usar tanto desde su entorno live como instalando en un disco duro. Algunas de estas herramientas se instalan de manera manual me dirán más de uno, pero si lo vemos de forma un poco simplista, con lo que tenemos pre-instalado estamos más que preparados para un pentesting “normal”.

Pentesting

Este es el proceso que realiza un analista de seguridad, algunos de forma defensiva, pero si estás en Kali, probablemente de manera ofensiva. A lo largo de un pentesting el analista hace un reconocimiento del objetivo, encuentra posibles vectores de ataque, realiza ataques dirigidos en entornos lo más “controlados” posibles, y tras su largo esfuerzo genera un reporte detallado de todo el proceso y apunta los posibles fallos que puede tener un sistema/software/equipo/persona.

Mar.io pentester

Supongamos por un segundo que Mar.io decide dedicar su vida al análisis de seguridad, él no duerme, no come, no juega, solo requiere de tiempo para procesar cosas y números para analizar sus resultados. Imaginemos qué sucederá tras unos cuantos meses de estudios de Kali Linux. Con un poco de tiempo aprenderá a usar nmap, tal vez después le interese probar metasploit, y quién sabe, tal vez con el tiempo genere su propio programa para hacer las cosas más eficientes. Esto me recuerda mucho al programa de AI de Facebook que decidió crear su propio idioma de negociación porque el inglés era muy poco “eficiente” ( y no, no era esperanto tampoco por si se lo preguntan :P ).

El futuro de la seguridad

Imaginemos ahora por un instante que después solo existirán Mar.ios trabajando en seguridad, algunos atacando, otros defendiendo, pero eso ya no importaría. ¿Por qué? pues porque si tenemos ambos bandos peleando a ese nivel, sin dormir, sin comer, sin nada… ¿qué podría hacer un humano para estar a su altura? Recordemos a la AI de Google que pudo vencer al mejor jugador de Go en lo que se supone es el juego más complicado del planeta para una máquina :).

Esto nos lleva al mundo empresarial, en el que los pentesters ya no serán necesarios, ni para auditar, ni para defender, y las grandes empresas tendrán servidores dedicados al análisis continuo de sus programas y redes.

¿Debo continuar mi carrera en seguridad?

Pues esto es algo un poco complicado de responder :) si seguimos la misma premisa para cualquier campo, vamos a ver que el 90% de trabajos del futuro serán o podrían ser realizados por pequeños Mar.ios, desde la psicología, pasando por el derecho y medicina, hasta finalmente llegar al software, digo finalmente porque el punto en el que un programa sea capaz de modificarse a sí mismo, ese será el punto de fin de nuestro control sobre los programas, ellos se mejorarán a sí mismos y en ese entonces serán incontrolables. Suena aterrador, lo sé :) pero déjenme soñar un poco :P

Centrando en el tema nuevamente, si vale la pena o no aprender a hacer esto, yo creo que sí y no. Sí vale la pena si realmente vas a meterte de lleno en el tema, y vas a investigar y aprender cosas que vayan más allá del mero hecho de repetir un proceso una y mil veces esperando obtener el mismo resultado.

Esto aplica tanto para los pentesters como para los desarrolladores, y los administradores de sistemas. Aquel que solamente conozca usar una herramienta será fácilmente remplazado por un Mar.io en el futuro. Los que, por otro lado, puedan diseñar herramientas (verdaderos hackers :P) serán quienes entrenen y mejoren a los pequeños Mar.ios, no tendrán el futuro asegurado, pero mientras sean mejores que los programas, podrán llevarse un pan a la mesa :)

Reflexión

Bueno, hasta aquí será por hoy, gracias por leer y me gustaría pedirles un favor. Sé que muchos leen sin comentar nada al respecto, y es verdad que ya les debo varios temas para escribir o continuar, pero nunca está de más un pequeño feedback para saber si hay dudas o no, si se puede comentar algo más o no, si ustedes tienen un aporte sustancial al texto, o lo que se les ocurra :) Así me motivan a mí a seguir escribiendo y al mismo tiempo me dan nuevas ideas para otros artículos. Saludos.

Un vistazo a la explotación de vulnerabilidades

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 :)

Diseño propio. Christopher Díaz Riveros

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í.

Qué significa realmente ‘hacker’

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’

Cómo responder ante un hacker ‘profesional’

Creo que la pequeña ausencia ha valido la pena :) Estos días estoy con más ánimos que nunca de empezar nuevos proyectos y supongo que ya dentro de poco les daré nuevas noticias sobre mis avances en Gentoo :) Pero ese no es el tema de hoy.

Computación Forense

Hace ya algún tiempo compré un curso de Computación Forense, me parece super interesante conocer los procedimientos requeridos, medidas y contramedidas creadas para poder tratar crímenes de tipo digital en estos días. Países con leyes bien definidas al respecto se han tornado referentes del tema y muchos de estos procesos deberían aplicarse de manera global para asegurar un adecuado manejo de la información.

Falta de procedimientos

Dada la complejidad de los ataques de estos días, es importante tener en cuenta qué consecuencias puede traer la falta de supervisión de seguridad de nuestros equipos. Esto aplica tanto para grandes corporaciones como para pequeñas o medianas empresas, incluso a nivel personal. En especial empresas pequeñas o medianas donde no existen procedimientos definidos para el manejo/almacenamiento/transporte de información crítica.

El ‘hacker’ no es tonto

Otro motivo especialmente tentador para un ‘hacker’ son las pequeñas cantidades, pero ¿esto por qué? Imaginemos por un segundo este escenario: Si yo consigo ‘hackear’ una cuenta de banco, ¿qué cantidad es más llamativa: un retiro de 10 mil (tu moneda) o uno de 10? Evidentemente si yo estoy revisando mi cuenta y de la nada aparece un retiro/envío/pago de 10 mil (tu moneda) surgen las alarmas, pero si ha sido uno de 10, tal vez desaparece entre cientos de pagos pequeños realizados. Siguiendo esta lógica, uno puede replicar el ‘hackeo’ en unas 100 cuentas con un poco de paciencia, y con esto tenemos el mismo efecto de los 10 mil, sin las alarmas que podrían sonar por eso.

Los problemas empresariales

Ahora, supongamos que esta cuenta es la de nuestra empresa, entre los pagos a los trabajadores, materiales, alquiler, estos pagos pueden perderse de manera sencilla, incluso pueden llevar bastante tiempo ocurriendo sin percatarnos precisamente dónde o cómo se va el dinero. Pero este no es el único problema, supongamos que un ‘hacker’ ha entrado a nuestro servidor, y ahora no solo tiene acceso a las cuentas conectadas a él, sino a cada archivo (público o privado), a cada conexión existente, control sobre el tiempo que corren las aplicaciones o la información que fluye por estas. Es un mundo bastante peligroso cuando nos detenemos a pensar en eso.

¿Qué medidas preventivas existen?

Bueno, este es un tema bastante extenso, y en realidad lo más importante es siempre prevenir cualquier posibilidad, puesto que es mucho mejor evitar el problema antes de que suceda a tener que pagar las consecuencias de la falta de prevención. Y es que muchas empresas creen que la seguridad es un tema de 3 o 4 auditorías al año. Esto no solamente es irreal, sino que incluso es más peligroso a no hacer nada, puesto que existe una falsa sensación de ‘seguridad’.

Ya me ‘hackearon’, ¿ahora qué?

Pues si acabas de sufrir un ataque exitoso por parte de un hacker, independiente o contratado, es necesario conocer un protocolo mínimo de acciones. Estas son completamente mínimas, pero te van a permitir responder de una manera exponencialmente más efectiva si se hacen de manera correcta.

Tipos de evidencia

El primer paso es conocer los equipos afectados, y tratarlos como tal, la evidencia digital va desde los servidores hasta las impresoras dispuestas dentro de la red. Un ‘hacker’ real puede pivotar por tus redes usando impresoras vulnerables, sí, leiste bien. Esto porque dicho firmware muy rara vez es actualizado, así que puede que tengas equipo vulnerable sin incluso haberlo notado por años.

Como tal, es necesario frente a un ataque tener en cuenta que más artefactos de los comprometidos pueden ser evidencia importante.

First responder

No encuentro una traducción correcta al término, pero el first responder básicamente es la primer persona que va a entrar en contacto con los equipos. Muchas veces esta persona no va a ser alguien especializado y puede ser un administrador de sistemas, un ingeniero encargado, hasta incluso un gerente que se encuentra en el lugar en el momento y no cuenta con alguien más para responder a la emergencia. Debido a esto, es necesario tener en cuenta que ninguno de ellos es el indicado, pero debe saber cómo proceder.

Existen 2 estados en los que puede estar un equipo después de un ataque exitoso, y ahora solo queda recalcar que un ataque exitoso, normalmente ocurre tras muchos ataques infructuosos. Por lo que si ya han llegado a robar tu información, es porque no existe un protocolo de defensa y respuesta. ¿Recuerdan lo de prevenir? Ahora es donde más sentido y peso tiene esa parte. Pero bueno, no voy a restregar eso más de la cuenta. Sigamos.

Un equipo puede estar en dos estados tras un ataque, conectado a internet o sin conexión. Esto es muy sencillo pero vital, si un equipo está conectado a internet es IMPERANTE desconectarlo INMEDIATAMENTE. ¿Cómo lo desconecto? Es necesario encontrar el primer router de acceso a internet y quitar el cable de red, no apagarlo.

Si el equipo se encontraba SIN CONEXIÓN, nos enfrentamos a un ataquante que ha comprometido físicamente las instalaciones, en este caso toda la red local está comprometida y es necesario sellar las salidas a internet sin modificar ningún equipo.

Inspeccionar el equipo

Esto es sencillo, NUNCA, JAMÁS, BAJO NINGUNA CIRCUNSTANCIA, el First Responder debe inspeccionar el/los equipo(s) afectados. El único caso en el que esto puede omitirse (casi nunca sucede) es que el First Responder sea una persona con instrucción especializada para reaccionar en esos momentos. Pero para que se hagan una idea de lo que puede suceder en estos casos.

Bajo entornos Linux

Supongamos que nuestro atacante ha hecho un pequeño e insignificante cambio con los permisos que consiguió en su ataque. Cambió el comando ls ubicado en /bin/ls por el siguiente script:

#!/bin/bash rm -rf /

Ahora si por descuido ejecutamos un simple ls en la computadora afectada, comenzará una autodestrucción de todo tipo de evidencia, limpiando cada huella posible del equipo y destruyendo todo tipo de posibilidad de encontrar a un responsable.

Bajo entornos Windows

Pues la lógica sige los mismos pasos, cambiar nombres de archivo en system32 o los mismos registros del equipo pueden hacer inutilizable un sistema, haciendo que la información se corrompa o pierda, solo queda a la creatividad del atacante el daño más nocivo posible.

No jueguen al héroe

Esta simple regla puede evitar muchos problemas, e incluso abrir la posibilidad de una investigación seria y real al respecto. No existe forma de empezar a investigar una red o sistema si todo posible rastro ha sido borrado, pero evidentemente estos rastros tienen que dejarse de manera premeditada, esto quiere decir que tenemos que tener protocolos de seguridad y respaldo. Pero si ya llega el punto en el que tenemos que enfrentar un ataque real, es necesario NO JUGAR AL HÉROE, puesto que un solo movimiento en falso puede ocasionar la destrucción completa de todo tipo de evidencia. Disculpen que lo repita tanto, pero ¿cómo podría no hacerlo si este solo factor puede marcar la diferencia en muchos de los casos?

Reflexiones finales

Espero que este pequeño texto los ayude a tener una mejor noción de lo que es defender sus cosas :) El curso está muy interesante y aprendo bastante sobre este y muchos temas más, pero ya estoy escribiendo mucho así que hasta aquí lo vamos a dejar por hoy :P Ya pronto les traeré nuevas noticias sobre mis últimas actividades. Saludos,

Evita ser hackeado con estos 3 pasos

Hasta ahora creo que no he tocado uno de mis temas favoritos, seguridad informática, y considero que este será el tema que les vengo a contar hoy :) Espero que tras este pequeño artículo puedan tener una mejor idea de lo que puede ayudar a tener un mejor control de sus riesgos y cómo mitigar bastantes al mismo tiempo.

Riesgos por doquier

Es inevitable, en este año solamente, ya llevamos más de 15000 vulnerabilidades descubiertas y asignadas de manera pública. ¿Cómo lo sé? Porque parte de mi trabajo es revisar CVEs en los programas que usamos en Gentoo para saber si corremos software vulnerable, de esta manera podemos actualizarlo y asegurar que todos en la distribución tengamos equipos seguros.

CVE

Common Vulnerabilities and Exposures por sus siglas en inglés, son los identificadores únicos que se asignan a cada vulnerabilidad existente. Puedo decir con mucha alegría que varios Developers de Gentoo apoyan al bien de la humanidad, investigando y publicando sus hallazgos para que puedan ser corregidos y solucionados. Uno de los últimos casos que tuve el gusto de leer fue el de Optionsbleed; una vulnerabilidad que afectaba a servidores Apache a nivel mundial. ¿Por qué digo que estoy orgulloso de esto? Pues porque ellos hacen un bien al mundo, mantener las vulnerabilidades en secreto solo beneficia a pocos, y las consecuencias de esto pueden ser catastróficas dependiendo del objetivo.

CNA

Las CNA son entidades encargadas de solicitar y/o asignar CVEs, por ejemplo, tenemos la CNA de Microsoft, encargada de agrupar sus vulnerabilidades, resolverlas y asignarles un CVE para su posterior registro a lo largo del tiempo.

Tipos de medidas

Vamos a comenzar aclarando que ningún equipo es o será 100% seguro, y como decía un refrán bastante común:

El único equipo 100% seguro es aquel que se encuentra encerrado en una bóveda, desconectado de internet y apagado.

Porque es cierto, los riesgos siempre estarán ahí, conocidos o desconocidos, solo es cuestión de tiempo por lo que frente al riesgo podemos hacer lo siguiente:

Mitigarlo

Mitigar un riesgo no es más que reducirlo (NO anularlo). Este es un punto bastante importante y crucial tanto a nivel empresarial como personal, uno no quiere ser “hackeado”, pero a decir verdad el punto más débil de la cadena no es el equipo, ni el programa, ni siquiera el proceso, es el humano.

Todos tenemos costumbre de culpar a otros, sean personas o cosas, pero en seguridad informática, la responsabilidad siempre es y será del humano, podrás no ser tú directamente, pero si no sigues el camino adecuado, serás parte del problema. Más adelante les doy un pequeño truco para mantenerse un poco más seguros ;)

Transferirlo

Este es un principio bastante conocido, tenemos que imaginarlo como un banco. Cuando tu necesitas cuidar tu dinero (me refiero de manera física) lo más seguro es dejarlo con alguien que tenga la capacidad de resguardarlo mucho mejor que tú. No necesitas tener tu propia bóveda (aunque sería mucho mejor) para poder cuidar cosas, solamente necesitas contar con alguien (de confianza) para que guarde algo mejor que tú.

Aceptarlo

Pero cuando el primero y el segundo no aplican, pues ahí es donde viene la pregunta realmente importante. ¿Qué tanto vale este recurso/dato/etc para mí? Si la respueseta es mucho, pues deberías pensar en los primeros dos. Pero si la respuesta es un no tanto, tal vez simplemente debas aceptar el riesgo.

Hay que afrontarlo, no todo es mitigable, y algunas cosas mitigables costarían tantos recursos que sería prácticamente imposible aplicar una solución real sin tener que cambiar e invertir mucho tiempo y dinero. Pero si puedes analizar aquello que intentas proteger, y no encuentra su lugar en el primer o segundo paso, pues simplemente llévalo en el tercer paso de la mejor manera, no le des más valor del que tiene, y no lo mezcles con cosas que realmente tienen valor.

Mantenerse al día

Esta es una verdad que escapa a cientos de personas y negocios. La seguridad informática no se trata de cumplir con tu auditoría 3 veces al año y esperar que nada suceda en los otros 350 días. Y esto es verdad para muchos administradores de sistemas. Yo hace poco al fin me pude certificar como LFCS (les dejo a ustedes buscar en dónde lo hice :) ) y este es un punto crítico durante el curso. Mantener al día tu equipo y sus programas es vital, crucial, para evitar la mayoría de riesgos. Seguro aquí muchos me dirán, pero el programa que usamos no funciona en la siguiente versión o algo similar, pues la verdad es que tu programa es una bomba de tiempo si no funciona en la última versión. Y eso nos lleva al anterior apartado, ¿puedes mitigarlo?,¿puedes transferirlo?,¿puedes aceptarlo?…

A decir verdad, solo para tenerlo presente, según las estadísticas 75% de los ataques de seguridad informáticas son originados desde el interior. Esto puede ser porque tiene usuarios en la empresa incautos, o malintencionados. O que sus procesos de seguridad no le han hecho difícil a un hacker irrumpir en sus locales o redes. Y casi más del 90% de ataques son originados por software desactualizado, no por vulnerabilidades de día cero.

Piensa como máquina, no como humano

Este será un pequeño consejo que les dejo de aquí en adelante:

Piensen como máquinas

Para los que no comprendan, pues ahora les doy un ejemplo.

Les presento a John. Entre los amantes de la seguridad es uno de los mejores puntos de partida cuando comienzas en el mundo del ethical hacking. John se lleva de maravilla con nuestro amigo crunch. Y básicamente agarra una lista que se le entrega y empieza a probar las combinaciones hasta encontrar una clave que resuelva la contraseña que busca.

Crunch es un generador de combinaciones. esto quiere decir que tu le puedes decir a crunch que quieres una contraseña con 6 caractéres de largo, que contenga letras minúsculas y mayúsculas y crunch empezará a probar uno por uno… algo como:

aaaaaa,aaaaab,aaaaac,aaaaad,....

Y se preguntarán cuánto tiempo lleva ir por toda la lista seguro… no toma más de unos cuantos minutos. Para los que se quedaron con la boca abierta, permítanme explicarles. Como conversamos anteriormente, el eslabón más débil de la cadena es el hombre, y su forma de pensar. Para una computadora no es complicado probar combinaciones, es algo sumamente repetitivo, y con el pasar de los años los procesadores se han vuelto tan poderosos que no necesitan más de un segundo para hacer mil intentos, o incluso más.

Pero ahora lo bueno, el ejemplo anterior es con el pensamiento humano, ahora vamos por el pensamiento de máquina:

Si le decimos a crunch que empiece a generar una contraseña con solo 8 dígitos, bajo los mismos requerimientos anteriores, hemos pasado de minutos a horas. Y adivinen qué sucede si le decimos que use más de 10, se convierten en días. Para más de 12 ya estamos en meses, además del hecho de que la lista sería de proporciones que no podrían ser almacenadas en una computadora normal. Si llegamos a 20 hablamos de cosas que una computadora no va a poder descifrar en cientos de años (con los procesadores actuales claro está). Esto tiene su explicación matetmática, pero por cuestiones de espacio no se las voy a explicar aquí, pero para los más curiosos tiene mucho que ver con la permutación, las combinatorias y las combinaciones. Para ser más exactos, con el hecho de que por cada letra que agregamos al largo tenemos casi 50 posibilidades, así nos quedará algo como:

20^50 posibles combinaciones para nuestra última contraseña. Ingresen ese número a su calculadora para que vean cuantas posibilidades existen con una clave de longitud de 20 símbolos.

¿Cómo puedo pensar como máquina?

No es sencillo me dirá más de uno pensar en una clave de 20 letras seguidas, sobre todo con el antiguo concepto de que las contraseñas son palabras clave. Pero veamos un ejemplo:

dXfwHd

Esto es difícil de recordar para un humano, pero súmamente sencillo para una máquina.

caballoconpatasdehormiga

Esto por otro lado es súmamente fácil de recordar para un humano (hasta incluso divertido) pero es un infierno para crunch. Y ahora más de uno me dirá, ¿pero no es recomendable también cambiar de manera seguida las claves? Sí, es recomendable, por lo que ahora podemos matar dos pájaros de un tiro. Supongamos que este mes están leyendo El Quijote de la mancha, tomo I. En la contraseña pondrán algo como:

ElQuijoteDeLaMancha1

20 símbolos, algo bastante difícil de descubrir sin conocer a la persona, y lo mejor es que cuando acaben el libro (suponiendo que leen de forma constante :) ) sabrán que deben cambiar su contraseña, incluso el cambiar a:

ElQuijoteDeLaMancha2

Es ya un progreso :) y seguramente les ayudará a mantener sus contraseñas seguras y al mismo tiempo les recordará que deben acabar su libro.

Ya es bastante lo que he escrito, y aunque me encataría poder hablar sobre muchos más temas de seguridad, lo dejaremos para otro momento :) Saludos