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 tomar el control absoluto de nuestra máquina, o bien a un atacante remoto, o bien a gusanos / virus (Blaster, por ejemplo) que usan dicha vulnerabilidad.

"Desbordamiento de buffer" es una de las frases que muchas veces asumimos sin preguntar -aunque sólo sea en plan curiosidad-, qué es lo que significa. En el presente artículo, creado para neófitos en informática, vamos a intentar clarificar este concepto: qué 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 artículo la palabra "exploit". Un exploit no es nada más 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.

¿como funciona un programa?

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 páginas web. Cuando el usuario teclea en un navegador: "http://www.microsoft.com/directx", el texto tecleado: "www.microsoft.com/directx" viaja como dato al servidor web de Microsoft. Dicho servidor 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 que 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 sólo una cantidad, digamos razonable de 1000 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 mal funcionamiento, o lo más probable, una "caída" del programar servidor web por machacarse parte de su propio código

Evidentemente, la solución pasaría por comprobar el tamaño de lo 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 guarda, y los 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 a 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, 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.

Continuamos con el ejemplo del servidor web anterior. Aunque nos estamos ciñendo a un servidor web, pensemos que en nuestras máquinas hay muchos pequeños, llamémosles, micro-servidores, es decir, programas, rutinas, funciones que están a la espera que alguien les active, o a la espera de recibir datos. El ejemplo del servidor web que estamos viendo no es anecdótico, sino que 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 qué sucede desde que hacemos una petición de una URL (dirección de Internet) hasta que el servidor nos devuelve datos.

Primero, existen 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. Este a su vez, analiza por completo el mensaje solicitado. Pensemos que en una URL pueden viajar muchas cosas: usuario / password, la máquina que lo va ejecutar, y en el contenido de la URL, la página, 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 encuentra instrucciones que entiende como de ejecución, pasárselo 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 analizarla en este sentido... se provocará probablemente un desbordamiento de buffer: un machaque de áreas de memoria que llevará al programa a caerse casi con toda probabilidad.

El Ataque

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 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 qué"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

Hackers

El mundo hacker se ha idealizado porque interesa mucho dicha idealización, y porque quizá 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 dentro 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 máquina Tienen además muchas horas libres, lo ú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 bloques 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".

Fuente: http://www.multingles.net/jmt.htm
José Manuel Tella Llop