Security Art Work

Apreciados lectores, me voy a alejar un poco de la temática de mis anteriores publicaciones, más enfocadas a aspectos organizativos de la seguridad, y en esta publicación hablaré sobre el uso de sistemas proxy cache para optimizar el uso del ancho de banda de red. Como introducción a los proxys, decir que básicamente se trata de un servidor que hace de intermediario en la conexión entre un cliente e Internet. Los proxys se emplean en distintos ámbitos y con distintas funcionalidades como puede ser seguridad (filtrado) o mejora de las prestaciones de las comunicaciones, entre algunas otras. Este artículo se centrará en los servidores Proxy Cache que permiten optimizar el uso de ancho de banda, reducir latencias y por lo general hacer un uso más racional de los recursos disponibles.

El funcionamiento de un proxy cache es el siguiente: cuando un cliente realiza una petición a un servidor web, en la que genera X peticiones a todos los objetos que componen dicha web, la petición llega al proxy, que revisa su cache para comprobar si dispone de los objetos que se van solicitando. En el caso de que el objeto buscado se encuentre en cache, el proxy verifica que no ha expirado: que el objeto se corresponde con el actual, y en ese caso se produce un HIT y el sistema devuelve al cliente el objeto en cuestión. Si por el contrario el objeto buscado no se encuentra en cache o la versión encontrada no está actualizada, se produce un MISS en cache, tras lo cual el proxy descarga el elemento solicitado y lo sirve al cliente.

Como puede verse, en el mejor de los casos nos ahorramos el enrutamiento desde el proxy al servidor sobre el que se realiza la petición y la transferencia de la información solicitada a través de Internet, mientras que en el peor de los casos añadimos un salto más en el enrutamiento. Por supuesto, cuánto más accedido sea un determinado contenido por los usuarios de la red interna, mayor probabilidad de que el objeto se encuentre en cache y por tanto, mayor incremento del rendimiento del sistema.

Veamos ahora un ejemplo enfocado a nuestro entorno. Como todos saben, la Ley 11/2007 de 22 de junio, de Acceso electrónico de los ciudadanos a los Servicios Públicos, promueve el ofrecimiento de los servicios prestados por las administraciones públicas a través de la web. El enfoque que se le está dando es que los organismos más grandes actuarán de prestadores de servicios para aquellos organismos más pequeños y con menores recursos; por ejemplo, una diputación presta la plataforma para los ayuntamientos. Teniendo en cuenta que las cifras empleadas únicamente van a servir de ejemplo y en ningún caso reflejan la realidad, apliquemos esto a lo que hemos visto hasta el momento.

Imaginemos que todas las peticiones web realizadas a los servicios prestados por los ayuntamientos se realizaran directamente contra el servidor de la diputación, que actúa no sólo de repositorio de contenidos, sino que además de frontal web para los usuarios finales. ¿Qué ancho de banda consumiría únicamente sirviendo las imágenes de la web? ¿Qué carga va a soportar el servidor? En este caso, el servidor de la diputación debería responder a cada petición de los usuarios. Sin embargo, si cada ayuntamiento dispone de un proxy cache, las peticiones de cada usuario repercutirá en una respuesta por parte del servidor del ayuntamiento, y el servidor de la diputación recibirá únicamente aquellas peticiones que correspondan a material que se encuentre obsoleto en el servidor del ayuntamiento (obviamente la parte dinámica siempre se trasladará al servidor de la diputación, por su imposibilidad de hacer uso de proxy cache para ello).

Hagamos algunos números, aunque de manera muy simplificada. Supongamos no hacemos uso de proxy caché, y que la página de un ayuntamiento está formada por 30 objetos, de los cuales 10 se actualizan cada minuto. Tenemos un total de 100 ayuntamientos que reciben 1000 peticiones por minuto, por lo que estamos hablando de un total de 3.000.000 de peticiones por minuto (30 objetos * 100 ayuntamientos * 1000 peticiones) directamente sobre el servidor de la diputación, lo que lo hace mucho más vulnerable a caídas y pérdidas de servicio en caso de existir un pico de carga que no pueda gestionar. Sin embargo, si se implementan proxys cache al nivel de los ayuntamientos, cada uno de éstos recibe un total de 30.000 peticiones por minuto (30 objetos * 1000 peticiones), y el servidor de la diputación 1000 peticiones por minuto (10 objetos que hay que actualizar cada minuto * 100 ayuntamientos). Como puede verse, ambos números son mucho más razonables y reducen tanto las necesidades de hardware como el impacto de un pico de carga. Por supuesto, para trasladar esto a un ejemplo real, deberíamos contemplar tanto el impacto de las verificaciones contra la fuente original del objeto demandado, además del impacto que tiene la cache de los propios navegadores sobre el tráfico soportado por los servidores. En cualquier caso, no es el propósito de la entrada elaborar un modelo elaborado, sino únicamente mostrar una aproximación numérica a las ventajas de la utilización de los proxy cache.

Como herramientas de servidor cache destaca SQUID, un programa de software libre que implementa un servidor proxy y un demonio para caché de páginas web, publicado bajo licencia GPL. SQUID es un proyecto que lleva tiempo disponible y que tiene muy buena aceptación por parte de la comunidad. Aunque orientado a principalmente a HTTP y FTP, es compatible con otros protocolos como Internet Gopher (sí, Gopher, ¿se acuerdan?). Implementa varias modalidades de cifrado como TLS, SSL, y HTTPS. Como herramientas para analizar los logs generados por el proxy, tenemos A CALAMARIS y SARG. Ambas ayudan a entender el funcionamiento de la red y permiten reconfigurar el proxy para mejorar las prestaciones del mismo.

Resumiendo, un proxy cache permite optimizar y mejorar las prestaciones, reduciendo (y limitando si es preciso) el consumo de ancho de banda, que puede ser utilizado para otros aspectos como puede ser trafico QoS (aunque este es más dependientes de latencias y jitter que de ancho de banda). En cualquier caso, aunque son patentes los beneficios de esta tecnología, es obvio que está enfocada a infraestructuras que soportan un importante número de peticiones web. Por otra parte, para mejorar su eficiencia es importante que exista un proceso de mejora continua, de modo que se aproveche el feedback que proporcionan los registros producidos por el servidor, ajustando la configuración del proxy a los requisitos de nuestra organización.

Hace un par de semanas tuvo lugar en Madrid el primer encuentro internacional CIIP sobre Ciberseguridad y Protección de Infraestructuras Críticas. El encuentro se desarrolló en la División de Formación y Perfeccionamiento de la Subdirección General RRHH de la DG de la Policía y la Guardia Civil con una muy alta participación tanto de gestores de Infraestructuras Críticas como de consultores que estamos trabajando en estos temas.

La inauguración oficial de las jornadas corrió a cargo del Secretario de Estado de Seguridad, D. Antonio Camacho, quien destacó la importancia que en los últimos tiempos ha tomado la seguridad para el conjunto de la sociedad y especialmente la seguridad de las infraestructuras críticas para todos los gobiernos del mundo. En su intervención lanzó una serie de datos que ponen los pelos de punta a cualquiera y que ponen de manifiesto la importancia de los temas tratados en el encuentro durante estos días. Habló, en términos generales, del ya disponible Catálogo de Infraestructuras Estratégicas de España, promovido a instancias proyecto de Directiva de la UE para la identificación y designación de infraestructuras críticas europeas (ICE) de diciembre de 2006, y desarrollado en España en base a lo establecido por del Acuerdo del Consejo de Ministros sobre Protección de Infraestructuras Críticas. Este Catálogo, tal y como se establece en el Real Decreto está considerado como material SECRETO y recoge información de unas 3.700 Infraestructuras Estratégicas en España, algunas de las cuales son Críticas. El Secretario de Estado comentó que aproximadamente el 80% de las Infraestructuras Estratégicas catalogadas están en manos privadas y que en los estudios que se han realizado en materia de seguridad sobre una población de unos 600 directivos de ICs, el 54% de las encuestadas reconocen haber sufrido ciberataques organizados.

A priori estos datos estremecen a cualquiera, y más cuando uno empieza a profundizar sobre las medidas de protección que algunas de estas instalaciones tienen en términos generales. En este blog ya hemos escrito en varias ocasiones sobre estos temas; hace algún tiempo, incluso antes de crearse el CNPIC, nos preguntábamos sobre si podíamos o no dormir tranquilos en un post que escribimos poco después de realizar una auditoría de seguridad en una instalación que no podemos ni debemos citar.

Para terminar su intervención, D. Antonio Camacho destacó la importancia del tema anunciando la próxima publicación del Real Decreto sobre la Protección sobre Infraestructuras Críticas Nacionales. El Plan Nacional de Protección de Infraestructuras Críticas define como Infraestructuras Críticas: “Aquellas instalaciones, redes, servicios y equipos físicos y de tecnología de la información cuya interrupción o destrucción tendría un impacto mayor en la salud, la seguridad o el bienestar económico de los ciudadanos o en el eficaz funcionamiento de las instituciones del Estado y de las Administraciones Públicas”, y contempla la inclusión de éstas en 12 Sectores estratégicos, subdivididos a su vez en Subsectores, Ámbitos y Segmentos que son los siguientes:

• Administración
• Alimentación
• Energía
• Espacio
• Sistema Financiero y Tributario
• Agua
• Industria Nuclear
• Industria Química
• Instalaciones de Investigación
• Salud
• Tecnologías de la Información y las Comunicaciones
• Transporte

En términos generales, constatamos el incipiente desarrollo de actividades en todos los sectores en esta materia y que es mucho el camino que queda por recorrer. No se puede decir, ni mucho menos, que sea un problema maduro en su definición, con soluciones maduras por parte del mercado. Mucha intención, mucho proyecto de I+D+i y mucho futuro para problemas que no obstante más que de futuro son totalmente presentes. Los asistentes tuvimos la oportunidad de recibir información sobre la perspectiva nacional, la internacional, la visión de algunos gestores de Infraestructuras Críticas y las tímidas soluciones de la Industria al problema planteado.

Las jornadas finalizaron con la creación de 4 talleres en torno a los temas que la organización consideró más urgentes e importantes:

• Taller I: Gestión de incidentes y Sistemas de detección preventiva
• Taller II: Gestión de Riesgos
• Taller III: Gestión de continuidad
• Taller IV: Seguridad en productos de sistemas y control industrial

En próximas entradas que escribirá el equipo que asistió al evento, intentaremos resumir las conclusiones que hemos sacado de cada uno de estos talleres. Por último, desde este blog queremos enviar nuestra más sincera enhorabuena al joven Centro Nacional de Protección de Infraestructuras Críticas (CNPIC) por la organización del encuentro, y nuestro mensaje de ánimo a su Director, D. Fernando Sánchez, para afrontar el duro trabajo que tienen por delante. Desde S2 Grupo seguiremos trabajando en labores de I+D+i, concienciación y consultoría para aportar nuestro granito de arena en una labor tan importante para los estados como es la protección de sus Infraestructuras Críticas.

Si recuerdan el post que publicamos hace poco más de una semana titulado OWASP Top 10 2010. Release Candidate, éste iniciaba una serie de entradas a través de las que pretendemos mostrar en qué consiste cada una de las vulnerabilidades que forman el TOP 10 de OWASP, así como ofrecer algunas indicaciones y recomendaciones sobre la mejor forma de evitar que nuestras aplicaciones sufran estas conocidas vulnerabilidades. Con algo de retraso sobre la fecha prevista, he aquí el primero.

La vulnerabilidad más comúnmente explotada desde el año 2004 que OWASP lleva realizando esta clasificación es la inyección. Aunque la más común sea probablemente la Inyección de SQL, existen otros tipos de inyecciones que es posible que no nos resulten tan familiares: LDAP, XPath, XSLT, XML, OS injection, etc., y que al igual que la Inyección SQL se aprovechan de la sintaxis del interprete que se va a encargar de ejecutar una determinada acción. Las vulnerabilidad de inyección pueden permiten a un atacante obtener cualquier tipo de información disponible en la aplicación, pudiendo llegar a comprometer totalmente la aplicación, así como los sistemas relacionados con ésta. Y ya saben que de ahí al infinito y más allá.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en los que podemos encontrar una inyección SQL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para obtener el listado de artículos de una determinada categoría:

Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo:

De esta forma, el atacante podría obtener el listado de todos los artículos de la base de datos con una simple modificación que puede ser realizada directamente desde el navegador con, por ejemplo, el plugin Hack Bar de Firefox. Aunque esto parezca trivial y quizá en algún caso pueda interesar que un usuario se pase toda la tarde viendo mi página web para comprar un cabecero para su dormitorio, la cosa cambia sustancialmente cuando la información que se pretende mostrar son los ingresos de un trabajador o el grado de minusvalía de una determinada persona. Si a esto le añadimos la posibilidad de algunos sistemas gestores de base de datos de concatenar sentencias en una misma ejecución, el resultado podría ser la modificación de una tabla o incluso el borrado de la propia base de datos.

Pasando a otra tipología, veamos ahora una inyección de sistema operativo. Supongamos que en la interfaz de administración de la aplicación de catálogo comentada anteriormente existe una interfaz de administración que permite ejecutar unas tareas administrativas sobre el servidor, cuyo resultado es mejorar la indexación de las distintas bases de datos que componen la aplicación. Una vez seleccionada la base de datos, el usuario pulsa el botón de optimizar y se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para optimizar la base de datos solicitada:

Cuando el proceso termina se envía un mensaje al espacio privado del usuario con el resultado de la ejecución. Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo de la siguiente manera:

De esta forma, podría obtener el listado de todos los usuarios y sus contraseñas en su espacio de usuario, únicamente esperando a que el proceso termine su ejecución (seguro que en lugar de /etc/passwd pueden pensar alternativas mejores).

Aunque los ejemplos de vulnerabilidades se han mostrado siempre con peticiones GET, las aplicaciones son igualmente vulnerables a peticiones POST. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor, aunque el uso de determinados frameworks puede mitigar la existencia de estas vulnerabilidades. Los dos ejemplos mostrados son sólo un par de situaciones en las que es posible encontrar vulnerabilidades de inyección, pero la filosofía es extensible al resto de tipos de inyecciones.

La primera manera de protegerse, independientemente del tipo de inyección que podamos sufrir, es asegurar que los datos que se utilizan para componer la visualización dinámica de la aplicación —aquella que depende de la petición del usuario— se encuentran correctamente validados antes de su interpretación. Es decir, si “estamos esperando” un número, se debe validar que el parámetro utilizado será un número, y si por el contrario esperamos una dirección de correo electrónico, utilizaremos ese dato únicamente si éste es conforme al formato establecido. En segundo lugar, es importante prestar especial atención a la existencia de determinadas secuencias de caracteres y cuando se presenten, “escaparlas” mediante las funciones apropiadas. Por último, la mayoría de lenguajes disponen de APIs con funciones diseñadas para proteger la aplicación, y que ofrecen la posibilidad de ejecutar consultas especialmente preparadas para evitar este tipo de problemas de seguridad.

Y hasta aquí todo lo referente a ataques de inyección, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no tienen más que indicarlo en los comentarios.

El pasado 18 de enero, nuestro compañero y “alma mater” de este Blog, el ínclito Manuel Benet, nos sorprendió con una nueva entrada que titulaba “MAGERIT: ¿Sí, o no?“, donde transcribía el artículo 13 del aún por entonces no publicado Esquema Nacional de Seguridad (ENS), y sometía la cuestión a una encuesta informal.

Para los que no conozcan el tema, en España, especialmente en las Administraciones Públicas, tenemos un referente indiscutible en el ámbito de la Seguridad de la Información cuando nos planteamos la metodología de análisis y gestión de los riesgos a seguir: MAGERIT, actualmente en su versión 2.0 y elaborada por el Consejo Superior de Administración Electrónica (CSAE), órgano del Ministerio de Administraciones Públicas encargado de la preparación, elaboración, desarrollo y aplicación de la política informática del Gobierno Español.

Por otro lado, el Esquema Nacional de Seguridad (ENS), Real Decreto 3/2010 de 8 de enero (BOE de 29 de enero), tiene por objetivo establecer la política de seguridad en la utilización de medios electrónicos, y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información en el ámbito de acceso electrónico de los ciudadanos a los Servicios Públicos.

Volviendo al tema en cuestión, en el área de consultoría de S2 Grupo teníamos nuestro pequeño debate acerca de porqué en el ENS no se aconsejaba directamente el uso de MAGERIT, ni se mentaba implícitamente. Quizás la respuesta estaba en un explícito reconocimiento internacional. Así pues, decidimos investigarlo buscando referencias en ámbitos superiores y encontramos alguna referencia en ENISA (European Network and Information Security Agency) que la identifica junto a otras metodologías europeas e internacionales. Encontramos múltiples referencias en la documentación electrónica accesible de esta agencia, donde cabría destacar una ficha en la que se afirma que su extensión geográfica va más allá de los miembros de la UE y que cumple con determinadas normas nacionales e internacionales. Sin embargo, por otro lado, en el “Inventory of Risk Management / Risk Assessment Methods“, afirma que hay métodos que fueron excluidos deliberadamente de la encuesta, porque los documentos pertinentes no estaban disponibles para los miembros del grupo de trabajo (por ejemplo MAGERIT desde España).

Esta referencia nos dejó estupefactos por las consecuencias que ello pudiera tener. Trabajamos con clientes en las distintas administraciones públicas, donde utilizamos esta metodología, incluso en el sector privado, y su grado de aceptación e implantación es muy alto. Por tanto, valoramos las oportunidades de dirigirnos a personalidades que son referencias en nuestro negocio, por lo que decidimos pensar bien cómo plantear la pregunta y dirigirla, en principio, a quien publicaba el ENS: el Consejo Superior de Administración Electrónica (CSAE), a través de su dirección de contacto (secretaria.csae [en] map [punto] es).

La contestación nos ha agradado mucho, en especial porque la contestaba personalmente Miguel A. Amutio Gómez, Jefe de Área de Planificación y Explotación de la Dirección General para el Impulso de la Administración Electrónica del Ministerio de la Presidencia. Como verán, es suficientemente esclarecedora y no veo oportuno comentarla ni resumirla. Tras solicitar el preceptivo y oportuno permiso para publicarla, aquí la tienen.

Desde aquí, agradecer a Miguel A. Amutio su respuesta y el honor de hacernos partícipes de esta aclaración. Ahora le toca a nuestras administraciones ponerse manos a la obra en la implantación de ese necesario y ambicioso proyecto que es el Esquema Nacional de Seguridad. Por lo demás, nosotros nos vamos hasta el lunes; sean felices y pasen un buen fin de semana.

Hace ya unos meses, en este mismo blog, comentábamos la seguridad de los procesos de negocio y de los diferentes factores de riesgo (legal, técnico…) que pueden degradar dichos procesos; hablábamos en ese post del riesgo humano, ya que las personas son un activo crítico de las organizaciones y, como tal, pueden introducir riesgos en éstas, riesgos que como siempre debemos tratar de forma adecuada. Pero el paso previo al tratamiento de riesgos es, como siempre, su análisis, y para analizar estos riesgos debemos ser capaces de determinar amenazas, probabilidades e impactos que pueden causar las pesonas en la organización.

Bajo mi punto de vista, las amenazas derivadas del factor humano son claras: todas las englobadas bajo el paraguas de amenazas corporativas (errores), las derivadas de actividades sociales (accidentes) y las derivadas de actividades antisociales (delitos); incluso rizando el rizo, podríamos hablar del factor humano en las amenazas de origen industrial y, siendo todavía más retorcidos, en las de origen natural. De la misma forma, los impactos asociados a estas amenazas también suelen estar más o menos claros, y estarán —con toda probabilidad— en la parte más alta de la escala de impactos que queramos utilizar en nuestro análisis. ¿Dónde está entonces lo que más nos interesa? En la medida de la probabilidad, como casi siempre…

Para analizar probabilidades a la hora de hablar del riesgo humano, una aproximación que me gusta mucho —adaptándola a nuestras circunstancias, por supuesto— es la presentada en [1]. La idea resumida y simplificada es que cualquier persona está modelizada por una serie de perfiles que la definen, perfiles afectados además por una serie de condiciones de contorno (relaciones, privilegios, motivaciones…) y de eventos externos o internos a la organización que pueden provocar cambios sustanciales en el perfil de una persona (un cambio de estado civil, un ERE, la muerte de un familiar…). Si somos capaces de monitorizar esto, de una u otra forma, seremos capaces de establecer controles cuando sea necesario, y por tanto de mitigar los riesgos humanos no asumibles en la organización.

¿Cuáles son los perfiles que definen a las personas? Según el trabajo anterior, son los siguientes (existe un último perfil identificado en el trabajo, el de utilización de recursos informáticos, bajo mi punto de vista demasiado ad hoc para la detección de insiders y no tan apropiado para la modelización del riesgo humano en general):

• Perfil económico (estabilidad, actividades sospechosas…).
• Perfil social (estado civil, personas dependientes, hobbies…).
• Perfil psicológico (adicciones, comportamientos anómalos, falta de carácter…).
• Perfil profesional (inteligencia, satisfacción, implicación, reconocimiento…).
• Perfil legal (antecedentes penales, procesos pendientes, sanciones…).
• Perfil ideológico (implicaciones políticas, religiosas…).

Si somos capaces entonces de crear estos perfiles, y lo que es más importante, de monitorizarlos en el tiempo para detectar cambios sustanciales que puedan introducir riesgos en nuestra organización, habremos dado un paso importante para reducir los riesgos derivados del factor humano. Ahora la pregunta del millón: ¿cómo monitorizar todo esto? Lo ideal sería, como siempre, hacerlo todo de forma automática, con sensores que nos avisan en tiempo real de cambios potencialmente peligrosos en la modelizacion de una persona. Para empezar, esto no es siempre posible (¿cómo diseño un sensor que detecte comentarios sospechosos durante la hora del café? ¿y rasgos faciales que puedan implicar falta de interés o cansancio?) y, cuando lo es, no suele ser fácil; seguramente para el gobierno estadounidense puede ser trivial controlar en tiempo real las transacciones económicas o los antecedentes de sus ciudadanos, pero desde luego, para nosotros (pobres mortales) ni es fácil ni muchas veces sería legal.

¿Qué hacer entonces? Mientras trabajamos en monitorización automática de personas para calcular probabilidades cambiantes que puedan aumentar los niveles de riesgo (¡toma ya!), podemos conformarnos con realizar manualmente una modelización de las personas de nuestra organización, teniendo en cuenta los perfiles anteriores —u otros cualesquiera que nos sean útiles — y por supuesto con las consideraciones legales oportunas. En base a este análisis, y pensando un poco, seguramente no hará falta ser psicólogo para darnos cuenta de posibles riesgos (en cualquiera de los ámbitos de la seguridad, desde un insider a un riesgo reputacional) que pueden existir derivados de las personas, y por supuesto cuando identifiquemos un nivel de riesgo no asumible, deberemos tomar medidas -aplicar controles- contra el mismo. Ojo, estos controles no tienen por qué ser ni caros ni complejos: como casi siempre en seguridad, simplemente hace falta pensar.

[1] Mitigating insider sabotage and espionage: a review of the United States Air Force’s current posture. Erika C. Leach, Air Force Institute of Technology. Marzo, 2009.

Aparte de la conocida seguridad por oscuridad, o la inseguridad de sentirse seguro, podemos hablar de la “seguridad por código binario”, y me explico. Hay muchos proyectos en los que todo es auditable, inspeccionado y revisado… excepto el código binario. Es muy habitual que éste se considere como algo seguro, inescrutable y secreto, ya que se considera que la ingeniería inversa es algo así como una tarea inabordable y de demasiada complejidad para ser llevada a cabo, si acaso por superexpertos.

Como ejemplo de este tipo, hoy en día existen numerosos binarios cerrados por diversas razones como DRM, licencias de producto, aplicaciones cliente servidor, o programación cerrada en sí misma. Ni que decir tiene que la mayor parte de ellos no son a día de hoy tan cerrados como a las empresas responsables de su desarrollo les gustaría. Para desmontar esa creencia de que la ingeniería inversa es para superdotados, en este post me gustaría repasar algunas de la herramientas existentes que permiten a no tan expertos el averiguar qué y cómo lo hacen los programas cerrados.

Primero de todo, no hay que olvidar que los binarios de hoy en día no son como los de antes; la complejidad del software es tal que siempre están compuestos por varios módulos y librerías dinámicas reutilizables, que son llamadas y compartidas por varios binarios a través de sus nombres de función. De esta manera es bastante sencillo identificar el funcionamiento de un binario a “alto nivel” y hacerse con la idea del programa grosso modo, sin que sea necesario analizar con detalle las instrucciones de ensamblador.

Una vez entrados en materia, pasemos a ver algunas herramientas que son útiles para averiguar qué esconde un determinado programa. Lo más sencillo que se me ocurre es la herramienta strings disponible en Linux, que como dice su nombre, al aplicarlo sobre un ejecutable muestra las cadenas del binario, en los que a veces nos encontramos con alguna sorpresa (usuarios, rutas, claves, direcciones IP, etc.):

# strings a.out

Si nuestro propósito es ver qué operaciones hace un programa a través de la red, la primera herramienta útil para averiguarlo puede ser un simple sniffer de red, de los que hay infinidad: tcpdump, wireshark, dsniff, etc.

Una herramienta curiosa para Windows que nos permite capturar tráfico cuando hay SSL interceptando la llamadas a la librería es Traceplus / Webdetective, de modo que si el binario intenta conectarse de manera cifrada para que no seamos capaces de ver el tráfico “va apañado”.

Dependiendo del tipo de binario también podemos hacer una traza de las llamadas que realiza al sistema operativo, viendo de esta manera qué fichero abre, que llamadas al sistema realiza, etc. En Linux destaca por su simplicidad strace, truss en Solaris, y Api monitor en Windows. Subiendo un poquito más de complejidad, es posible ver qué llamadas hace el binario a librerías con ltrace en Linux y con Blade Api Monitor en Windows.

En cuando a la inspección de binarios específicos de Windows (.NET y derivados), cabe destacar Reflector, un software gratuito que nos permite ver el código .net (y derivados). Por último, una técnica utilizada para desentrañar los secretos de un binario consiste en modificar y usar solo partes del programa, como llamadas a librerías. Tomando un ejemplo muy simple, si hemos descubierto el nombre de una llamada interesante como ObtainSecret();, una tarea sencilla puede ser generar un programa que realice una llamada a esa librería e imprimir en pantalla el resultado.

Y hasta aquí todas esta herramientas nos permiten ver el funcionamiento del software, sin saber ni una linea de ensamblador, viéndolo todo en alto nivel. Si queremos llegar mas lejos y tenemos conocimientos de ensamblador existen otras herramientas de depuración como IDA debugger, Ollydbg o SoftICE, mucho más especializadas y que probablemente aquellos de nuestros lectores que realicen desarrollo de sistemas o ingeniería inversa de manera habitual conocerán.

Como conclusión, si como parte de un proyecto vamos a proporcionar un binario “cerrado” a los clientes, hay que considerar todas las funciones que contenga como públicas y por lo tanto la fuerza del sistema no debe basarse en su integridad o seguridad, ya que como hemos visto con más o menos esfuerzo los funcionamientos de los binarios puede ser desvelados y modificados (el DRM tiene una curiosa historia de sistemas teóricamente inviolables que han sido rotos en cuestión de horas). Tal como si se tratara de javascript o flash, el hecho de que el códifo esté compilado en un .exe, elf o lo que sea, no lo hace impenetrable.

PD: Me tendrán que disculpar si no he puesto herramientas orientadas a Java, pero no estoy demasiado familiarizado con este lenguaje. No obstante, se trata de un lenguaje de programación complejo de alto nivel donde hay desensambladores, decompiladores, y muchas otras herramientas. Si lo desean, en los comentarios pueden aportar sus sugerencias.

(Imagen de http://www.everyjoe.com/thegadgetblog/files/2009/12/drm-locked-cd.jpg)

A continuación os presentamos un reto criptográfico que ha sido publicado por OWASP con el objetivo de promover unas conferencias en Estocolmo los días 21 al 24 de Junio organizadas por los capítulos de Suecia, Noruega y Dinamarca.

¿Qué se gana con este reto? Pues el primero en resolver el reto se lleva una entrada gratuita para estas conferencias valorada en unos 300€. Según anuncian en su página web, estos retos se realizan todos los días 21 hasta la celebración de las conferencias. En este caso, el objetivo de este reto en concreto es sencillo: obtener 8 contraseñas, compuestas por 5 caracteres codificadas en alfabeto tradicional, es decir [a-zA-z].

El esquema del reto es iterativo, como se puede comprobar en la siguiente ilustración. Es decir, obtenemos la primera contraseña, que se debe utilizar en el segundo paso para averiguar la segunda contraseña, ésta se usa para obtener la tercera y así sucesivamente.

Y cómo sabemos que la contraseña encontrada es la correcta? Pues con la información que se detalla a continuación:

• LM(pwd1) 0C04DACA901299DBAAD3B435B51404EE
• MD2(pwd2 + pwd1) 16189F5462BF906E9D88CF6F152DE86F
• MD4(pwd3 + pwd2) FA8F46A6D347087D6980C3FA77DD4DE9
• MD5(pwd4 + pwd3) 425B33D6F60394C897B8413B5C185845
• RIPEMD160(pwd5 + pwd4) 35F34671D30472D403937820DCABC1C78C837071
• SHA1(pwd6 + pwd5) AE81A30510B2931921934218636B26A803330EB1
• SHA256(pwd7 + pwd6) B2FF0269E927C6559804A37590A0688C45DF143F85CEE0E3F239F846B65C9644
• GOST3411(pwd8 + pwd7) 16CC9F1FF65688E040F5ADA82A41A258FF948769CDA4C4A17D85228A6F358971

El reto está desarrollado en Java y el código fuente que genera las hash se encuentra disponible (.ZIP), a excepción del algoritmo LM para el que se ha utilizado Bouncy Castle 1.4.5. Aunque el reto ya está resuelto en los foros, y no, no conocemos a quien lo ha resuelto —de hecho yo me he enterado cuando ya estaba resuelto—, eso no quita para intentar obtener las claves en menos tiempo que el ganador: 15 horas después de su publicación.

Siempre les quedará la victoria moral, que no es poca.

Aunque en alguna ocasión hemos hablado de OWASP (algunos de nosotros estuvimos en el pasado meeting del pasado mayo que tuvo lugar en Barcelona), lo cierto es que hasta la fecha, no hemos profundizado demasiado sobre este proyecto. Sirva esta entrada para solventar esta (relativamente) grave carencia.

Por si alguien no lo conoce, OWASP (acrónimo de Open Web Application Security Project, es decir Proyecto de seguridad de aplicaciones web abiertas), es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro, aunque su objetivo y foco de atención principal son las aplicaciones web. La comunidad OWASP, formada por empresas, organizaciones y particulares de todo el mundo, trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.

Organizativamente, OWASP se encuentra dividido en capítulos distribuidos geográficamente. Mención especial debe realizarse al capítulo ibérico, formado por los capítulos de España y Portugal, que organizó el pasado mes de Diciembre la primera conferencia de este capítulo en territorio español con el objetivo de difundir y discutir los problemas y soluciones relacionados con la seguridad de las aplicaciones, destacando la presencia del conocido Bruce Schneier, entre otros.

Una de las partes más conocidas de la documentación que genera esta comunidad, y que va a ser el objeto de las siguientes entradas de esta serie, son las revisiones de las 10 vulnerabilidades web más conocidas y explotadas dentro del sector. Muchos desarrolladores y técnicos han conocido la existencia de las inyecciones de SQL, el cross site scripting o la importancia del manejo de sesiones, entre otras, gracias a la documentación generada por esta comunidad en las versiones publicadas en el año 2004 y 2007. Está previsto que durante el año 2010 se publique una nueva versión de este documento que ya está disponible en la página web del proyecto para su validación y consulta (PDF). Entre los aspectos más destacados de esta nueva revisión podemos indicar que el top 5 no cambia, lo que a todas luces muestra que la mayor parte de la industria del desarrollo web (así como desarrollo en general) continúa considerando la seguridad como una parte prescindible y auxiliar de las aplicaciones, ignorando aspectos de seguridad críticos y en muchos casos fácilmente solventables.

Así pues, esta nueva serie de post sobre el TOP 10 de OWASP, que publicaremos semanalmente si el tiempo lo permite, mostrará en qué consiste cada una de las vulnerabilidades descritas y ofrecerá indicaciones y recomendaciones sobre la forma de evitar estas situaciones. Esperemos que les parezca interesante y nos hagan llegar sus impresiones al respecto.

Pasen, como siempre y a pesar del mal tiempo, un buen fin de semana.

(A raíz de una desconcertante experiencia de la que he sido espectador esta mañana cuando esperaba en la cola del cajero para ingresar dinero, me ha parecido oportuno recuperar esta entrada, que fue uno de los primeros posts de este blog allá por mayo del 2007, que sin duda muchos de ustedes no habrán leído y los demás seguramente la habrán olvidado)

El pasado fin de semana estuve viendo por tercera o cuarta vez Casa de Juegos, de David Mamet; confieso que la recordaba mejor. Supongo que en cierto sentido, por eso el poeta cubano decía aquello de No vuelvas a los lugares donde fuiste feliz; nuestra memoria no siempre es fiel a la realidad. La película en cuestión es de hace ya veinte años, en la que Mike (Joe Mantegna) es un timador dispuesto a desvelarle los trucos y entresijos de su “oficio” a una psicóloga (Lindsay Crouse) demasiado curiosa.

En una de las escenas, ambos se acercan a una “tienda” de envío de dinero, se sientan y esperan al siguiente cliente. A los pocos segundos, un marine que tiene que volver a la base entra en el establecimiento. Justo en ese momento, Mike se acerca al dependiente y ostensiblemente se queja de que no hay noticias de su dinero, mientras el recién llegado observa la escena; en realidad, él no sabe que ese dinero no existe. Los siguientes minutos transcurren viendo cómo en una breve conversación el timador se gana la confianza de su víctima, lamentándose de su situación y comprometiéndose a que si su dinero llega antes que el del marine, le pagará el autobús para que pueda volver a la base. Finalmente, como era de esperar, el dinero del chico llega y éste se ofrece a darle parte de éste a Mike. Dinero a un desconocido a cambio de nada. ¿Qué hemos aprendido hoy?, le pregunta él a ella cuando salen del establecimiento (rechazando la oferta). A no fiarse de nadie, contesta él mismo.

No, no teman, no nos hemos convertido en un blog cinematográfico. Pero me pareció que esa escena es una buena forma de mostrar qué y cómo actúa a menudo la Ingeniería Social. Según Melissa Guenther, ésta puede definirse como «la adquisición de información sensible o accesos privilegiados por parte de terceros, a partir de la creación de falsas relaciones de confianza con personal interno de la organización», o en otras palabras, ¿porqué intentar forzar la puerta de atrás cuando pueden abrirte la principal desde dentro? Según esta autora, y para acabar, la ingeniería social se rige por los tres siguientes principios:

(1) El deseo de ser de ayuda,
(2) la tendencia a confiar en la gente, y
(3) el miedo a meterse en problemas (Le entiendo, pero si no me ayuda, voy a tener que dar parte a…).

No vamos a llegar hasta el punto de aconsejarles que, como suele decirse, no se fíen ni de su padre, ni es nuestra intención extender un estado de desconfianza entre las personas, pero por lo general, cuando se trate de temas de seguridad, desconfíen. Esa suele ser una buena política.

Hoy un cliente me preguntaba sobre posibles medidas a implantar para evitar la fuga de información corporativa, y me apuntaba a la utilización de DRM (Digital Rights Management) y DLP (Data Loss Prevention) para controlar el flujo de información, sobre lo que además tal y como me indicaba no hemos escrito nada en el blog. Me comprometo ya mismo a escribir sobre ello en las próximas semanas (si no pueden esperar hasta entonces, sobre DLP la gente de Websense tiene un PDF bastante detallado en este enlace), pero en cualquier caso, es pertinente comentar unos puntos básicos al respecto de estas tecnologías:

• Este tipo de soluciones suelen tener un coste de adquisición e implantación no despreciable, si se pretende obtener una buena efectividad.
• Además del coste económico implícito, el mantenimiento y gestión de estos sistemas y la información que generan requiere su tiempo, que puede ser significativo y que al final se traslada en un mayor coste.
• Estos sistemas no son infalibles 100%; aunque limitan mucho la gestión no autorizada de información, no son la panacea ni hay que olvidar el resto de medidas (que incluyo en la segunda parte de esta entrada).
• Finalmente, estos sistemas introducen restricciones al flujo de información que pueden generar un torrente de quejas entre el personal, que el Departamento de Informática debe estar listo para asumir y gestionar; dicho de otra forma, es bueno que la organización sea consciente de qué está implantando y que Dirección ofrezca todo su respaldo… para poder utilizarla de escudo en caso de apedreamiento público.

Teniendo estos puntos en cuenta, es lógico que algunas organizaciones decidan llevar a cabo la implantación de DRM/DLP, por las indudables ventajas que aportan al control de la información que fluye por la organización. No obstante, sin que sirva de comparación o contrapartida, dejando de lado sistemas específicos, mis recomendaciones (bastante más baratas, por otro lado) son las siguientes:

• Disponer de normativas internas que especifiquen las funciones y obligaciones del personal, y de contratos de confidencialidad firmados con los empleados, que garanticen un respaldo legal en caso de robo “evidente” de información (el problema es que a veces no tiene nada de evidente).
• Implantación de controles técnicos que eviten que una persona pueda acceder a recursos y documentación a la que no debería tener acceso.
• Seguir la regla del need-to-know, y que a cada usuario se le otorgue acceso exclusivamente a lo que necesita para su trabajo, y no más que eso.
• Definir niveles de confidencialidad que establezcan de manera incremental los controles necesarios para el acceso a los recursos.
• Por último, pero casi lo más importante, concienciar a los usuarios sobre el buen uso de la información corporativa; quizá compartir el identificador de usuario con “el nuevo” que acaba de llegar y todavía no tiene acceso no sea tan buena idea, después de todo.

Todas estas medidas forman parte de un SGSI implantado y bien gestionado, que añade muchas más. Una opción alternativa es establecer restricciones a aquellos medios que pueden ser utilizados para la extracción de información, como son el acceso a Internet, los puertos USB y las grabadoras de CD/DVD, pero es algo para lo que también hay que estar (muy) preparado.

En definitiva, mi opinión es que una solución DLP/DRM es útil cuando se ha alcanzado un buen nivel de madurez en la gestión de la seguridad de la organización; hacerlo antes implica muy probablemente una implantación ineficaz que no (a)traiga más que problemas. ¿Cuál es su opinión al respecto?