El objetivo que se fija un pentester a la hora de hacer un test de intrusión se resumiría básicamente en intentar saber hasta donde es capaz de llegar. Por regla general, si conseguimos vulnerar una máquina que se encuentre seguramente en una DMZ, estaremos en una posición ventajosa para acceder a recursos que no están accesibles directamente desde Internet. Todo depende claro está de cómo de restringida se encuentre dicha máquina.

Una técnica que se suele utilizar y que sorprendentemente da buenos resultados es conseguir las credenciales de administrador del equipo vulnerado y comprobar si el resto de máquinas accesibles comparten la misma contraseña. En el caso de sistemas Windows, el sistema operativo almacena las contraseñas cifradas en el fichero SAM con los algoritmos LM o NTLM. En sistemas anteriores a Windows Vista o Windows 2008, el algoritmo de cifrado por defecto es LM. Desgraciadamente (o por suerte para el pentester) este cifrado es muy débil por su diseño: soporta un tamaño máximo de contraseña de 14 caracteres, no distingue mayúsculas de minúsculas, almacena el hash en dos mitades de 7 caracteres, y no añade “sal” en el almacenamiento para añadirle aleatoriedad, haciéndolo muy vulnerable a ataques por fuerza bruta o por tablas precomputadas.

Hace unos días recibí la revista de ISACA “ISACA Journal Vol. 5 Governance, tying together the three lines of defense”. En esta publicación encontramos un artículo sobre el Risk Governance (en adelante, Gobierno del riesgo). El artículo me pareció interesante pero un poco alejado de la realidad con la que solemos encontrarnos. Si me permitís la expresión, creo que está redactado un poco “a la Americana“. En más de una ocasión, al leer sobre estos temas de gestión “de tan alto nivel” me quedo con una sensación un tanto extraña, es como si esas empresas con increíbles estructuras organizacionales no existieran por aquí. Eso me lleva a preguntarme: ¿tan distintas son unas organizaciones de otras? ¿O simplemente es que usamos distintos términos para referirnos a lo mismo? Gobernar, gestionar, administrar… el lenguaje es caprichoso.

En lo que resta de entrada quiero aportar mi interpretación sobre el artículo “The three lines of defense related to Risk Governance” (Las tres líneas de defensa relacionadas con el Gobierno del Riesgo) procurando ofrecer una visión más cercana y similar a la que nos podemos encontrar en nuestras empresas. Pero antes de centrarnos en el artículo creo que es conveniente revisar algunos conceptos para situarnos en contexto.

Introducción

En la entrada de hoy les proponemos “cacharrear” un poco con OpenBSD, un sabor de UN*X descendiente de 4.4BSD, y ALIX, una placa de bajo consumo fabricada por PC Engines. El objetivo es montar un cortafuegos barato y de bajo consumo.

Ingredientes

La ISO de instalación de OpenBSD 4.9:

$ wget http://mirror.cdmon.com/pub/OpenBSD/4.9/i386/install49.iso

$ sha256sum install49.iso
5e3f9e961c0f37fd12f2d0719df50cfa9a0fdcac93e337f7bb5a52ea1de0f485  install49.iso

Un placa ALIX 2C3, aunque las instrucciones que siguen deberían funcionar con los demás modelos sin demasiados cambios. El sabor 2C3 lleva una CPU AMD Geode LX800 a 500 MHz, 256 MB de RAM y 3 interfaces Ethernet a 10/100. Además, le podemos pinchar…

… una tarjeta Compact Flash de al menos 512 MB de capacidad. En nuestro caso, hemos utilizado una Kingston de 4 GB.
… un lector/grabador de tarjetas Compact Flash. Hemos utilizado un modelo “todo-en-uno” USB estándar.
… un PC con Linux y qemu, para instalar OpenBSD en la tarjeta. Hemos utilizado un i386 con Debian Squeeze y el qemu de paquete.
… un cable serie (RS-232) “null modem” DB9-DB9 (hembra-hembra), para acceder a la consola de la ALIX desde el PC.

Desde finales del mes pasado, estamos detectando en nuestros Sistemas de Detección de Intrusos un aumento en los ataques dirigidos al puerto 3389 (servicio de Terminal Service). Se pensó que este aumento podía ser debido a una vulnerabilidad no conocida de este servicio, pero analizando el tráfico capturado, pudimos comprobar que se trataba de intentos de acceso utilizando el mismo usuario y un grupo de contraseñas débiles fijas.

Investigamos un poco y vimos que este aumento podría ser debido a un nuevo virus identificado como Morto. Se trata de un gusano que se propaga por la red aprovechándose de contraseñas débiles conocidas configuradas en los sistemas.

Pegando un vistazo a las presentaciones de la última Black Hat me sorprendió bastante la última de Mark Russinovich sobre “Zero Day Malware Cleaning with the Sysinternals Tools”. Mark ha incorporado mejoras notables en esta suite de herramientas gratuitas, para contribuir a la causa y profundizar un poco más en ellas, me animé a comprar el libro. En tan solo 23 páginas ya había amortizado los 31$ con cositas tan interesantes sobre estas tools y el sistema operativo de Microsoft, como las que paso a comentar.

En primer lugar Mark pasa a comentar aspectos generales del funcionamiento interno de Windows Vista, 7 y 2008 en cuanto al control de la autorización de seguridad. Cuando por ejemplo un usuario administrador se loguea en estos sistemas mencionados, se crean 2 tokens de sesión (creados por el LSA, Local Security Authority), uno con todos los privilegios y otro con los privilegios acotados. Este último se utiliza para crear los procesos iniciales userinit.exe y explorer.exe, así como los hijos de los mismos. Para ejecutar un proceso con el full token se requiere de una elevación UAC (User Account control), realizada por el servicio Aplication Information (Appinfo). Por lo tanto si queremos ejecutar por ejemplo un runas.exe con las credenciales de un administrador, deberemos tener en cuenta que se ejecutará con los privilegios de usuario estándar de esa cuenta. Solo hay una excepción y es el usuario administrador por defecto (que viene deshabilitado inicialmente). Por lo tanto se ha de especificar que se quiere ejecutar con permisos elevados, si queremos hacer algo que requiera privilegios más allá de un usuario normal. El modo de trabajo en UAC se puede deshabilitar y por lo tanto se vuelve al modelo de Windows XP (peligroso ya que incluso el Internet Explorer corre con máximos privilegios).

Como todos sabréis la ultima semana de agosto el huracán Irene aterrizó en la costa este de Estados Unidos. Por suerte o por desgracia coincidió que un día antes de que el huracán llegase a Nueva York aterricé en aquella misma ciudad dispuesto a disfrutar de mis vacaciones veraniegas por mucho huracán que hubiese. Antes de coger el avión te mentalizas de que seguro que no será para tanto, de que estos americanos no saben lo que es llover de verdad, o que aquello es muy grande y que sería mala suerte que coincidiese en los sitios que vas a visitar.

Cuando cogimos el avión, desde España no tenia muy mala pinta ya que el huracan estaba a dos días de Nueva York, pero una vez allí el nivel de alerta/paranoia era extremo: en cualquier hotel, bar o restaurante con televisión la gente se quedaba mirando las noticias con cara de miedo, y la verdad es que con las imágenes que mostraban no era para menos.

Esta va ser la primera de las n entradas que vamos a dedicar a Spring Security. Para los que todavía no lo conocen, Spring Security es uno de los framework de seguridad J2EE más populares y completos usado por parte de instituciones, empresas e universidades muy importantes. Con Spring Security es bastante trivial incorporar la infraestructura básica de seguridad en una aplicación ya implementada sin necesidad de escribir ni una línea de código gracias a su naturaleza no invasiva. Además, posee componentes ya implementados que permiten la integración con sistemas externos con mucha facilidad. Inicialmente fue basado en el proyecto Acegi Security, que con los años se fue convirtiendo en un producto robusto y maduro, actualmente miembro de la familia de productos Spring. Debido a que muchos de los conceptos como la inyección de dependencias y programación orientada a aspectos los hereda de Spring, es aconsejable que tengamos nociones básicas de las mismas.

La seguridad de la aplicación en sí se considera como un requisito transversal, y por lo tanto se puede encapsular en forma de aspecto y más tarde aplicarse de forma declarativa en cualquier punto de nuestra aplicación. Spring Security ofrece módulos que aíslan ese tipo de lógica, permitiendo además que la aplicación tenga una arquitectura robusta, limpia y débilmente acoplada.

…mañana puede que a ti.

Hace casi una semana el nombre de Anonymous volvió a surgir de nuevo en las redes sociales y medios de propósito general, debido a un comunicado donde se indicaba un supuesto robo de información que obligó a las autoridades españolas a cerrar la web de la Policía Nacional durante unas horas. En este comunicado se hacía público el listado de los escoltas del actual presidente del gobierno español (Zapatero) y se amenazaba con la posibilidad de publicar datos del Grupo Especial de Operaciones (GEO) del Cuerpo Nacional de Policía. Unos días después el grupo Anonymous desmentía cualquier tipo de relación con el robo de información mediante un comunicado, lógicamente sin la certeza de que realmente dicho comunicado sea auténtico.

Pues bueno, hoy, cinco días después, se ha hecho público un listado de once supuestos miembros de los GEO: nombre, DNI y cargo. Lógicamente esta información no ha podido ser contrastada todavía, pero el comunicado comienza con el siguiente párrafo:

En este post vamos a hablar acerca de una vulnerabilidad descubierta por el equipo de CSIRT-cv y publicada ayer, como podéis ver en su página de alertas. La aplicación afectada es JasperServer, un servidor para generación de informes, análisis de datos y Business Intelligence ampliamente utilizado, y que tiene una versión de código abierto, que es la que se ha demostrado vulnerable.

Durante un test de seguridad realizado a la versión 3.7.0 CE, se detectó que, además de los parámetros necesarios para ubicar al usuario en la aplicación, había un parámetro llamado _flowExecutionKey que iba cambiando cada cierto tiempo, probablemente para controlar el flujo del usuario dentro de la aplicación. A continuación se puede ver un ejemplo de petición válida en el sistema:

Para hoy martes traemos una nueva entrada de Cristina Martínez Garay, de la firma Rocabert & Grau Abogados, bufete que colabora con Security Art Work, en este caso al respecto de la implantación (o mejor, “no-implantación”) de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

Esperamos que les resulte interesante.

Han transcurrido más de cuatro años desde la promulgación de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos y dos desde la publicación de su Reglamento de desarrollo y apenas observamos algun cambio en las Administraciones ni tampoco la intención de acometerlo pese que, la Disposición Final 3ª concedió un aplazamiento para la adaptación a la citada Ley (hasta 31/12/09 y para las Comunidades Autónomas y Entidades Locales supeditado a sus disponibilidades presupuestarias). No obstante, habida cuenta que la implantación de la Administración Electrónica es un proyecto complejo y costoso, es por lo que nuevamente el legislador otorgó una tregua a las Comunidades Autónomas y Entidades Locales para aprobar y hacer público los programas y calendarios de trabajo con mención particularizada de las fases en las que los diversos derechos serán exigibles por los ciudadanos.