Diversión con CRC. Introducción

Una de las áreas probablemente menos trabajadas por los "pentesters" de hoy en día es la criptografía. Sin embargo, poseer habilidades básicas en este tema será cada vez más y más obligatorio para hacer nuestro trabajo de forma adecuada. Este artículo es el primero en una serie dedicada a la criptografía y su aplicación en las pruebas de penetración modernas.

El algoritmo de CRC (Cyclic Redundancy Code) fue standarizado alrededor del año 1975, en la decada que parece ser donde todo lo importante se inventó. El objetivo de sus creadores era contar un código de verificación que permitiera detectar errores de transmisión de datos en las nacientes redes digitales. A pesar de que hoy en día contamos con redes muy confiables en donde errores "ocasionales" no son un verdadero problema, el algoritmo es todavía utilizado con relativa frecuencia y con desastrozas consecuencias para la seguridad.

El punto clave es que los algoritmos de CRC fueron diseñados para detectar modificaciones "no-intencionales." Sus autores nunca pensaron en que tendrían que enfrentarse a una red de redes con atacantes activamente modificando e interviniendo sus comunicaciones. En consecuencia, la utilización de esta clase de algoritmos con la idea de detectar modificaciones maliciosas en nuestra Internet está condenada a ser inefectiva en la mayoría de los casos. El ejemplo más conocido es probablemente el ataque fulminante que recibió WEP en donde la debilidad del CRC32 jugó un papel muy importante. Sin embargo, hay todavía muchos ejemplos vigentes asi que el entendimiento de las debilidades de este algoritmo significa entretenimiento garantizado por todavía un muy buen tiempo :D

La clase de algoritmos CRC están basados en simples operaciones módulo un polinomio (irreducible en muchos casos, aunque primitivo es preferible) en un cuerpo finito, específicamente GF(2). Ésto significa que las sumas se convertien en operaciones "XOR" y los inversos están garantizados cuando el polinomio es irreducible. Básicamente, las operaciones en este cuerpo (o campo) son muy similares (isomorficas de hecho) a las operaciones algebraicas elementales a las que estamos acostumbrados. Pero toda esta teoría es suficiemente aburrida, y esto se supone que sea divertido. La diversión comienza ahora:

Una de las construcciones criptográficas más prominentes en nuestros protocolos de comunicación segura involucra transformar texto claro en cifrado mediante la operación "XOR" del mensaje a proteger con una cadena "aleatoria" y de dificil deducción por parte de nuestro atacante. La razón de usar esta construcción es que nuestras computadoras pueden hacer las operaciones necesarias de forma muy rápida. Por ejemplo, si el mensaje que quiero proteger es "Minas al suroeste" y mi cadena aleatoria es la secuencia de bytes: "506f77735727601cdf3609a8c9d7dc1a9f", entonces lo que tengo que enviar por el canal inseguro es el resultado del siguiente calculo:

A medida que la cadena de cifrado se hace más aleatoria, el trabajo de mi atacante se hace más dificil. Sin embargo, este esquema es muy fácil de vulnerar simplemente aprovechando dos problemáticas muy evidentes: 1) la disponibilidad de la estructura del mensaje y 2) la falta de protección de integridad del texto cifrado. El primer problema estará siempre presente en protocolos estándares y abiertos pues sería inutil pensar que la estructura de mis mensajes permanecera oculta para mi atacante por mucho tiempo.  Sin embargo, el segundo problema es el tema que abordan los "codigos de verificación criptográfica" y es donde se ha intentado utilizar CRC de forma muy poco efectiva. Pero primero veamos cómo mi atacante es capaz de vulnerar el esquema inicial.

Si mi atacante quisiera confundir a mi interlocutor, y modificar el mensaje para que en lugar de decir "Minas al suroeste", dijera, "Minas al noroeste", todo lo que tiene que hacer son unas cuantas simples operaciones con XOR, como siguen:

Ahora, cuando mi interlocutor reciba el texto cifrado modificado por mi atacante, y lo "desencripte" utilizando la cadena aleatoria, obtendra el mensaje "Minas al noroeste" en lugar de obtener el mensaje original.

Nótese que mi atacante no necesitó adivinar la complicada cadena aleatoria. Tódo lo que necesitó fue aprovechar un poco la estructura del mensaje, i.e. la posición donde estaba el mensaje que deseaba modificar, y ese pedazo del texto claro, i.e. "sur". Esto puede parecer un requerimiento demasiado grande, pues el atacante necesita conocer un pedazo del mensaje original ("sur"). Sin embargo, este requermiento no es nada dificil de cumplir en la práctica cuando consideramos lo altamente predecibles que pueden llegar a ser nuestras comunicaciones. Al iniciar una carta, ¿no esperamos siempre un "saludo"? ¿una fecha? ¿una localidad?

Ahora bien, aceptemos por un momento que es imposible eliminar la redundancia de nuestras comunicaciones de tal forma que asumamos que nuestro atacante siempre tendrá un pedazo de información con la cual perpretar este ataque. ¿Acaso no podemos hacer nada para defendernos? Intentemos usar el chequeo CRC. Específicamente, utilizaremos el algoritmo CRC32 que es el más usado. La utilización de este algoritmo en este tipo de situaciones y las formas en que puede abusarse para perpetrar ataques altamente efectivos serán el tema de los siguientes artículos de esta serie. Sin embargo, para terminar esta introducción al tema, veamos cómo se calcula y como se usa el CRC32.

El CRC32 más popular está basado en el polinomio:

x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1

El cual representaremos con la secuencia de bytes: 0xEDB88320. A cada mensaje, le corresponde un código CRC32 cuyo cálculo detallado es un poco involucrado, pero en el corazón del algoritmo está la determinación del residuo de la división de nuestro mensaje por este polinomio, asumiendo coeficientes módulo 2. La mejor forma de describirlo para nosotros los informáticos es un algoritmo. La implementación en python que presento aquí es muy utilizada, y está basada en una tabla cuya generación veremos a continuación:

def CRC(mensaje,INITXOR,OUTXOR):
    r = INITXOR
    for c in mensaje:
        r = crc32_table[(r ^ ord(c)) & 0xFF] ^ (r >> 8)
    r ^= OUTXOR

La función anterior utiliza dos parametros adicionales (INITXOR y OUTXOR) que no hemos mencionado todavía, pero que para el caso CRC32, los valores son simplemente 0xFFFFFFFF en ambos casos. Ahora bien, hace falta conocer los valores de crc32_table. Esta tabla se puede generar utilizando la siguiente función:

def gen_crc_table(CRCPOLY):
    res = [0 for i in xrange(256)]
    for n in xrange(256):
        c = n
        for k in xrange(8):
            if ((c & 1) != 0):
                c = CRCPOLY ^ (c >> 1)
            else:
                c = c >> 1
    return res

Para el caso de CRC32 el parámetro CRCPOLY de la función anterior es simplemente el valor 0xEDB88320 mencionado anteriormente. Esto es todo. Veamos como funciona esto en la consola de python:

Ahora que sabemos como se calcula el código CRC32 para un mensaje, estamos listos para intentar usarlo y prevenir que nuestro atacante envíe a nuestra tropa al campo minado del noroeste. La idea es muy natural, en lugar de enviar sólamente mi mensaje encriptado con mi cadena de bytes aleatoria, lo que voy a enviar es la encripción de la concatenación del mensaje original con el código CRC32 recien calculado. La idea sería que cuando mi atacante modifique el mensaje encritpado, mis interlocutores se den cuenta e ignoren el mensaje falso. El código CRC de mi mensaje es: 0xf60ebe68, pero lo concatenamos al mensaje con los bits menos significativos primero. Esta concatenación la podemos ver en la figura anterior. Por lo tanto, lo que enviaré a la tropa es:

El texto cifrado es básicamente el mismo, pero concatenado con el cifrado del código CRC32 que calculamos. Nuestro atacante puede hacer ahora exactamente el mismo procedimiento anterior. Sin embargo, ahora cuando la tropa obtenga el texto falsificado, tendremos un código CRC32 con que validarlo:

y al calcular el CRC32 del mensaje que modificó mi atacante, encontrará:

El cual no es igual al CRC que enviamos en el texto cifrado. La tropa descartará el mensaje y todos felices. Sin embargo, resulta que por las propiedades del algoritmo de CRC, mi atacante tiene una gran cantidad de posibilidades para atacar este nuevo esquema. El detalle de algunas de estas fórmulas de ataque serán el tema de los siguientes artículos de esta serie.

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í.

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:

@EnfoqueSeguro 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). :-(

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.