Estudio, mente y paciencia

Alien [blackhat4all@gmail.com]

Mucho se ha hablado sobre los Hacker en varias ediciones de BlackHat, pero hasta el momento, que yo recuerde, jamás se han dado a conocer cómo Hackear un servidor o una máquina teniendo acceso directo a ella. En este artículo abordaré sobre cómo es posible buscar y encontrar defectos de seguridad en los programas que nos permitan poder realizar con ellos tareas para las que no fueron concebidos, o simplemente tratar de burlar la seguridad de los mismos.

Muchos podrán leerse este artículo sin lograr entender la mitad de las cosas que se dicen, otros querrán probar de inmediato todas las variantes, pero algo les aseguro y es que no se mostrarán los pasos en concreto para realizar estas tareas, ya que cuando alguien se decide a acometer un Hacking, debe basarse primeramente en algunas variantes que haya escuchado o que haya visto funcionar, en caso que aún estén vigentes esas técnicas, tendrá el éxito casi asegurado, pero si por casualidad los textos que ha leído están algo “pasados de moda”, entonces tendrá que recurrir a su imaginación e ingenio, ya Hackear no se aprende de ningún manual.

Antes que se aventuren a continuar, les diré que esta labor puede ser tarea de semanas, meses, años e incluso no llegar jamás a controlar un programa. Hackear depende de muchas cosas, pero sobre todo, de la inventiva y capacidad del que lo intenta. Se debe conocer sobre programación, o al menos tener una noción de qué es cada cosa, puesto que es muy difícil poder entrar en un sistema sin saber o tener una idea de cuales son los pasos que realiza un programa en cada momento.

En otras ocasiones hemos hablado en BlackHat sobre las cosas que se deben saber y tener para enfrascarse en una tarea de este tipo, así que no pienso repetir nuevamente los programas o elementos fundamentales que se deben dominar. Me limitaré a hablarles no sobre un invento mío, sino sobre una teoría ya probada y que establece 4 pasos para buscar debilidades en un sistema operativo.

Conocimiento de la estructura de control del sistema

Para encontrar agujeros de seguridad (bug) e identificar debilidades de diseño en sistemas operativos es primeramente imprescindible entender la estructura de control del sistema.
No basta con saber el nombre del sistema operativo, o el idioma en que está, se debe conocer más.
Todos los sistemas operativos actuales tratan de competir por ver quien ofrece más seguridad a sus clientes, pero si algo tienen en común, es que la seguridad se brinda mediante un nombre de usuario y contraseña, los cuales deben ser suministrados en algún momento por quienes usan la computadora, y esos datos deben ser guardados en alguna parte y con algún tipo de encriptación para darle más protección.

Es necesario conocer cuales son los objetos que el sistema protege con más empeño, pues es en esas locaciones donde sabe que tiene la mayor vulnerabilidad. Igualmente se debe saber cual o cuales son las aplicaciones que se encargan de proteger estos archivos, ya que si se logra desactivarlas, se pudiera buscar la forma de entrar al archivo y obtener su contenido.

Una vez que se logra conocer estas cosas, se puede crear un gráfico que permita ver la jerarquía que existe en la máquina e identificar luego los puntos vulnerables. Para esto puede servir tanto bibliografía que exista en Internet como manuales de usuarios y texto que en ocasiones anteriores han ayudado a burlar la seguridad del sistema y que por la importancia que tuvieron en su momento no han perdido actualidad y sirven aún hoy a modo de guía.

Inventario de desperfectos

Esto no es más que hacer un recorrido histórico por el sistema. Sus inicios, desarrollo, faces por las que ha pasado, puntos que más ataques han recibido y demás. Se debe tener bien presente todas las revisiones que se han hecho del sistema, así como estar actualizados en cuanto a los parches, ya que esto nos evita un doble trabajo tratando de entrar por una vía que ya ha sido revisada por terceros.

A menudo sucede que cuando se programan grande tareas, a mitad del trabajo se decide crear o cambiar de tipo una variable, ya sea para facilitar las cosas o por necesidad o simplemente por un cambio de planes. Esto perfectamente puede traer como consecuencia que en el código escrito antes de ese punto, y por consiguiente la variable afectada u otras que realizan operaciones vinculadas a esta se vean afectadas, trayendo consigo un error.

Esto no es difícil que ocurra, de hecho en BlackHat #28, en la sección de noticias, hablábamos de cómo los programadores de Microsoft Exel habían cometido un error que traía consigo una respuesta errónea.

Confirmar hipótesis

Todo lo anteriormente dicho puede ser llevado a cabo sin tener que estar necesariamente de frente a un ordenador. Pero desde este punto, ya será imprescindible tenerlo como almohada.

Esta es la fase casi final, en la que, después de haber hecho una especie de resumen, comenzamos a explota todos las debilidades que pudimos haber encontrado. Esta es la fase donde nuestros dones de programador deben ganar el papel protagónico, puesto que trataremos de entrar a zonas a las que no se ha penetrado, por lo que difícilmente exista un software capaz de realizar esta tarea por nosotros.

Generalizar.

La última fase es tratar de llevar las debilidades que hemos encontrado a su mayor exponente. Se supone que en este paso ya se han encontrado bugs, al menos uno y es la hora de hacerse preguntas:
¿Funcionará solo en este sistema?
¿Qué pasa si…?
¿Y si no …?

Esta es la fase donde se extrapola todo lo que hemos descubierto a otros sistemas, lo que nos abre las puertas para penetrar en otros programas que estén basados en el mismo tipo de seguridad.

Espero que este artículo les sea útil y logren no penetrar en un sistema operativo, sino aprender a darle seguridad a sus programas, evitando así convertirse en víctima de Crackers.

Artículos relacionados