Cómo un atacante puede tomar el control de nuestros equipos
Agosto 31, 03 by adminHa aparecido en ibrujula un artÃculo, escrito por José Manuel Tella, en el cual se hace alusión a métodos de intrusión usados por atacantes de forma básica. Este es parte del texto:
"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.
¿CÓMO 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 paginas web. Cuando el usuario teclea en un navegador: http://www.microsoft.com/directx, 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.
VIENDO UN POCO DEL DIAGRAMA DE CAPAS DE EJECUCIÓN
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.
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 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."
El artÃculo completo lo podeis encontrar en http://iblnews.com/news/noticia.php3?id=85381
