Aclantis - ¿ Cómo los hackers se meten en las PCs ?

OPINIÓN-ANÁLISIS.- El experto en seguridad e informática José Manuel Tella explica en este artículo cómo los hackers explotan las vulnerabilidades que permiten tomar el control de computadoras ajenas, una cuestión de candente actualidad después del mes más destructivo en cuanto a virus de la historia de Internet.

Estos días han saltado a la opinión pública una serie de errores provocados por desbordamiento de buffer (buffer overflow), los cuales permitían o bien a un atacante remoto, o bien a gusanos y virus como Blaster, por ejemplo, que usan dicha vulnerabilidad el tomar control absoluto de nuestra máquina. "Desbordamiento de buffer" es una de las frases que muchas veces asumimos sin preguntar -aunque solo sea en plan curiosidad-, que es lo significa. En el presente articulo, escrito para neófitos en informática vamos a intentar clarificar este concepto, que es lo que realmente significa, y por qué sucede. Esto es inherente a cualquier sistema operativo, por lo que no es exclusivo de Microsoft. Vamos a utilizar en varios puntos de este articulo la palabra "exploit". Un exploit no es nada mas que una manera, o un código, o lo que sea, de manejar una vulnerabilidad para tomar el control de una máquina, o bien para hacerla malfuncionar y provocar la caída de sus servicios. [B]¿CÓMO FUNCIONA UN PROGRAMA?[/B] Un programa tiene su área de código ejecutable, y usa en memoria un espacio para almacenamiento del propio código y también para almacenamiento de los datos que vaya a utilizar. Igualmente, si el programa recibe parámetros o datos, debe guardarlos temporalmente en memoria. Por ejemplo, imaginemos un programa servidor de paginas web. Cuando el usuario teclea en un navegador: [URL=http://www.microsoft.com/directx]http://www.microsoft.com/directx[/URL], el texto anotado www.microsoft.com/directx viaja como dato al servidor web de Microsoft. Dicho servido es un programa que recibe ese texto, y que tiene que almacenarlo en memoria. Imaginemos que desde nuestro navegador, podemos teclear lo que queramos sin tener un tamaño máximo para escribir. Es decir que tecleamos http://www.microsoft.com/xx....xxxx y el texto que ponemos en las xxxxx es enorme. Pongamos que enviamos 10.000 caracteres... a ver qué pasa. Si el programa servidor que se está ejecutando en los servidores de Microsoft, no tiene presente que pueda recibir toda esta cantidad de datos y el programador que lo ha realizado ha previsto solo una cantidad, digamos razonable de 1.000 caracteres, el propio programa al intentar guardarse esos 10.000 caracteres, está "machacando" áreas de memoria que pueden ser de contenido de otros datos (en cuyo caso se machacan) o incluso de código ejecutable del propio servidor. En cualquier caso, hay destrucción de información que provocarán en el mejor de los casos o un malfuncionamiento, o lo mas probable una "caída" del servidor web por machacarse parte de su propio código. Evidentemente, la solución pasaría por comprobar el tamaño tecleado antes de moverlo a zonas de memoria. Este es un caso muy sencillo y muy simplificado, pero nos puede servir como idea de lo que sucede. Generalicemos un poco: un programa, se descompone en funciones. Dicho programa recibe parámetros o datos, se los guardan, y se lo pasa al resto de funciones o subprogramas que lo necesiten. El problema es cuando el propio programa o los propios subprogramas o funciones, tienen reservados tamaños inferiores de la longitud de los datos que reciben. La solución, por supuesto, es que cada programa, función, modulo, librería, DLL, etc.... no se fíe de nadie y verifique exhaustivamente todo antes de tomar ninguna acción y ni tan siquiera guardarlo en memoria. Normalmente, los controles anteriores no se hacen excepto en entrada de datos, y es debido a que esto implica sobrecargar excesivamente de código de comprobación, y en tiempo de ejecución todos los parámetros y todas las zonas de memoria a las que accede el programa. El problema surge, cuando muchas de las funciones diseñadas para ejecutarse internamente y que no tienen controles de los parámetros, deciden reutilizarse en otros programas de nivel superior, los cuales pueden no tener tampoco dichos controles. En este caso, y aunque su funcionamiento sea normal, pueden encontrarse situaciones en que alguien malintencionado lo descubra y decida "explotar" esta vulnerabilidad. Es vulnerable un programa desde el momento en que somos capaces de hacerlo "cascar". Si somos capaces de ello, también seremos capaces de hacer lo que queramos: es decir de tomar control de él. Veremos un poco más adelante y de una manera sencilla, el cómo. [B]VIENDO UN POCO DEL DIAGRAMA DE CAPAS DE EJECUCIÓN[/B] Continuamos con el ejemplo del servidor web anterior. Aunque nos estamos ciñendo a un servidor web, pensemos que en nuestras maquinas hay muchos pequeños micro-servidores, es decir, programas, rutinas, funciones que están a la espera que alguien los active, o a la espera de recibir datos. El ejemplo del servidor web que estamos viendo no deja de ser anecdótico, sino que además describe una vulnerabilidad real que ha existido en los servidores y que en su día (hace unos años) fue explotada con éxito por el mundo hacker. Veamos muy por encima las capas que componen un servidor web, o mejor, veamos que sucede desde que hacemos una petición de una URL (dirección de internet) hasta que el servidor nos devuelve datos. Primero, existe una serie de capas del tcp/ip que reciben los mensajes. Estas capas lo que hacen es pasarlo al siguiente nivel. En nuestro caso, al punto de entrada de los datos del servidor web. Éste a su vez, analiza completo el mensaje solicitado. Pensemos que una URL pueden viajar muchas cosas: usuario / password, la máquina que lo va ejecutar, y en el contenido de la URL, la pagina, o incluso instrucciones de ejecución. Por ello, si nos fijamos nos podemos encontrar URL's larguísimas que están enviando instrucciones al servidor. Este a su vez, está compuesto por módulos o capas: por ejemplo, un módulo para autenticar al usuario si este fuese en el mensaje, otro, por ejemplo, para analizar el literal del mensaje y si se encuentra instrucciones que entiende cómo ejecutarlo, pasarlo al modulo ejecutivo, etc. Al final, si todo es correcto, se construye la página o se muestra directamente una página almacenada y se envía. Pero lo importante, es que se ha llamado, pasando los datos tecleados por nosotros a un montón de programas y módulos. Si cualquiera de estos no tiene previsto un análisis detallado de la URL, o en algún caso falla al analizarlo en este sentido se provocará probablemente un desbordamiento de buffer: un machaque de áreas de memoria que llevarán al programa a caerse casi con toda probabilidad. [B]EL ATAQUE[/B] Si un hacker, en algún momento, consigue en este ejemplo hacer que un servidor se caiga por enviar una URL inválida...... ya tiene todo resuelto. Si es capaz de hacer "cascar" al programa servidor, también será capaz de enviar dentro de la URL código ejecutable en unas posiciones muy determinadas de la URL. Si este "trozo" de código enviado entra en ejecución... ya tenemos el "exploit". Es decir, antes que el servidor se "caiga", habrá ejecutado un código dejado por el hacker. Este código puede hacer cualquier cosa: si el hacker ha tenido la imaginación y ha sido capaz de realizar pruebas para encontrar un agujero que antes no se le había ocurrido a nadie, ni al programador, ni al equipo de programación, ni tan siquiera al equipo de pruebas, y que posiblemente lleve oculto años sin que haya sucedido nada, si ha tenido dicha imaginación está claro que también la tendrá ahora para saber que "código" nos va a "inyectar" en nuestra máquina. Estas inyecciones de código ya están muy estudiadas por el mundo hacker. Estudiadas, realizadas y probadas: únicamente consiste ahora en buscar la vulnerabilidad para "inyectar" el código. [B]EL MUNDO HACKER[/B] El mundo hacker se ha idealizado porque interesa mucho dicha idealización, y porque quizás los primeros hackers no perseguían fines claramente dañinos, sino simplemente la posibilidad de entrar en una máquina ajena, bien para usarla, o bien como un reto. Pero esto es una idealización. Un hacker es un delincuente. Aunque dejemos la puerta de nuestra casa mal cerrada o por descuido abierta, si encontramos a alguien entra de nuestra casa... no será con fines "educativos" ¿no? Pues bien, eso es lo que es un hacker: alguien que sin nuestro permiso entra en nuestra casa. Aunque no haga nada más que dejarnos un mensaje en el espejo del baño diciendo "he pasado por aquÍ", no creo que nos gustase mucho. Y es un delito. Los hackers "buenos" o "éticos" no existen. Serán consultores de seguridad, expertos de seguridad, empresas de seguridad que venden sus servicios o su trabajo para evitar accesos no autorizados. Pero no serán hackers. Dentro de este submundo de delincuentes existen los llamados script-kiddies (o niños script). Son simplemente gente sin conocimientos informáticos pero con ganas de hacer daño, o por sentirse importantes, o bien por ser graciosos, patético. No saben informática, pero aprenden de una manera mecánica a usar "exploits", código, o lo que sea, para entrar en una maquina. Tienen además muchas horas libres, por lo que único que hacen, es de una manera rutinaria y sin saber lo que hacen, lanzar "scripts" o miniprogramas preparados para ir buscando máquinas potencialmente vulnerables. Es como llamar aleatoriamente a bloque enteros de números del listín telefónico, diciendo "Soy tu primo Juan". Antes o después, alguien picará y se lo creerá realmente.... ya tenemos "al incauto".