30 abril 2012

Libro: Hacking de Aplicaciones Web: SQL Injection

Pese a que me manejo en inyecciones de SQL, sobre todo en MySQL, compre un ejemplar de este libro que detalla exclusivamente esta vulnerabilidad para fortalecer las partes en la que estoy pez, como por ejemplo SQL Server o las técnicas de "Serialized", a la que dedican un capítulo entero. Además siempre aprovecho para poder escribir luego una entrada como esta en el blog :-)

Los autores son Enrique Rando y Chema Alonso, que ya han publicado otros libros como Hacking con buscadoresAnálisis Forense Digital en Entornos Windows.

El libro consta de más de 250 páginas divididas en cinco capítulos, desde la detección más básica hasta un análisis de las diferencias entre los distintos motores de bases de datos. En concreto su índice a grandes rasgos es el siguiente:

1.- SQL Injection a partir de (casi) cero
2.- Serialized SQL Injection
3.- Blind SQL Injection
4.- Objetivos Llamativos
5.- Otras diferencias entre DBMS

De todas las técnicas que se van exponiendo se muestran scripts de ejemplo para que el lector haga su propio laboratorio y las pruebas que quiera, y a partir de ahí, se describe como se detecta, analiza y explota la vulnerabilidad. El resultado es realmente práctico, ya que si sigues los pasos es prácticamente imposible que no lo entiendas a la perfección. Eso sí, hubiera estado bien que las páginas de prueba se pudieran descargar desde alguna web, ya que tener que "picarlas" desde el libro es un poco tedioso.

Además del detalle técnico, también se habla de herramientas que automatizan el proceso, describiendo su funcionamiento y sus características, ¡y se han acordado de bfsql!, que por cierto, otra persona ha continuado desarrollando en la v2.


El libro cuesta 20€  y hay que solicitarlo en la página web de la editora: Informatica64, la futura O'Reilly.

Leer más...

29 abril 2012

Enlaces de la SECmana - 121


Leer más...

28 abril 2012

Crónica de ConectaCon Jaen


El lunes a las 2 de la tarde dejé el buen clima alicantino para dirigirme en coche hacia Jaén, al esperado evento de seguridad informática ConectaCon, que organizó la gente de @enred20. Llegué a tierras jiennenses allá sobre las 18:30, donde me dispuse a aparcar en una no demasiado señalizada zona de carga y descarga. 

Tras dejar las cosas en el hotel, vinieron a recogerme Raimundo Alcázar (@ralcaz) y Encarni Moreno (@maminen), de la asociación, junto con otros ponentes, Daniel Medianero (@dmedianero) y Alejandro Nolla (@z0mbiehunt3r), dos verdaderos cracks. Como se respiraba algo de tensión, ya que era la primera CON que celebraban, nos relajamos con unas cervezas de bienvenida. Más tarde, fuimos a ver la sede de la asociación, donde conocimos a Antonio Cruz (@acruzgomez), actual presidente y, a partir de ese momento, nuestro chofer personal, y a Pedro (@knrl64), otro miembro de la asociación y padre del CTF que saldrá en breve online para que todo el mundo pueda disfrutar.

He de decir que Antonio se ha portado genial con todos nosotros (al igual que el resto de organizadores) y que lo hemos llevado loco durante todo el congreso.

Luego, tras una cena donde no faltó el marisco y la cerveza, seguida de unos chupitos de orujo, nos fuimos (mejor dicho, nos llevó Antonio) Daniel, Alejandro y yo al hotel, a descansar, no sin antes hacer una parada en el bar para tomar 'la última'.

Como anécdota, comentar que es cierto eso de que un buen hacker nace, y no se hace. Resulta que al entrar en el ascensor, había un bonito monitor colgado dentro y, como buenos hackers, Dani y Alex se dedicaron a buscar un Ethernet Exposed para SbD mientras subíamos a las habitaciones. El caso es que al día siguiente, quedamos para desayunar en el buffet pero me vi desayunando sólo. Resultó que mientras ellos analizaban el monitor, yo lo leía, y ponía que el desayuno era en el entresuelo, así que mientras yo me ponía ciego de bollería, zumos y demás, ellos se pagaron un café con tostadas en el bar de abajo :)

Tras el desayuno, cómo no, teníamos al pobre Antonio esperando abajo para llevarnos a la Universidad. Y por fin comenzaron las charlas, en una sala llena hasta la bandera, donde hasta había gente sentada en las escaleras por falta de sitio.

Recuerdo que le comenté a Rai que poner un día de charlas orientado a empresarios y otro a estudiantes iba a ser una locura, y que era mejor mezclar las ponentes. Pero evidentemente, viendo la cantidad de gente que había ambos días, me equivoqué. Y además, al contrario de lo que pensaba, todas las charlas estuvieron geniales, incluso aquellas que no venían relacionadas con la seguridad.


El primer día de charlas se habló de la LOPD, de los certificados electrónicos, de lo bonito que es Panda Antivirus y finalizando por una charla muy divertida de la Guardia Civil.

He de decir que no me disgusta Panda en absoluto, de hecho tengo buenos amigos trabajando allí, pero sí que me dan mucha grima las charlas comerciales y no las que da un técnico, ya que muchas cosas que dice, además de meter gambazos, tira por los suelos el prestigio de muchos profesionales de la informática.

A mitad de la jornada, en medio de una charla, entró Encarni y me hizo un gesto para que saliera un momento y yo, todo confiado bajo las escaleras, salgo y me encuentro a una reportera de Canal Sur arrimándome el micro y con el cámara enfocando (Encarni, esta te la debo xDD). Me preguntó que quién era y de qué iba a hablar, y le dije que de VoIP. Tras poner cara de poker me preguntó, ¿y eso qué es? … Y bueno, al rato salieron Dani y Alex que tras verse el percal, se hicieron los locos ... 

Y después de una mañana muy amena, comimos, y comenzó el taller que impartí de Seguridad en Redes Inalámbricas. La verdad es que me sorprendió muchísimo la acogida que tuvo, ya que se llenó la sala e incluso se quedó gente a verla, en un lateral del aula, sin ordenador. Aprovecho para mandar un saludo a todos los asistentes y espero que disfrutaran con el taller.

Otra persona que asistió al taller y que a pesar de conocer hace mucho, aún no había puesto cara, fue mi amigo Luis (@streaming10) que al parecer lo habían echado de Sevilla por altercados públicos y nos lo mandaron para Jaén un par de días. Con él era imposible llegar puntuales, pues se paraba a hablar con todas las mujeres que se cruzaban.

Luego, para terminar bien el día, nuestro querido Antonio nos llevó al hotel para ducharnos y cambiarnos en 15 minutos y, nos fuimos a seguir disfrutando de la gastronomía de Jaén, donde cenamos Rai, Dani, Alex, Luis y yo. Tras dejar a Rai volver a casa con la familia, nos fuimos a recoger a otro conocido crack, Sebastián Guerrero (@0xroot), que también la lió nada más llegar a Jaén. Pues partió la llave de la habitación al intentar abrir la puerta.


Y como yo estaba un poco griposo, me fui a descansar, dejando a mis 4 compañeros (Dani, Alex, Luis y Sebas) peleándose mano a mano con una botella de Ron, en la habitación de Sebas.

Al día siguiente, tras desayunar todos juntos en el hotel (esta vez si) nos llevó Antonio de nuevo a la Universidad para comenzar la segunda jornada de charlas. Comenzando por Manuel Lucena (@mlucena), Doctor en informática y profesor de Criptografía en la Universidad, que dio una charla muy interesante sobre seguridad en comunicaciones electrónicas, seguido por Alejandro, que nos mostró, de forma muy amena y divertida, cómo se realizan las auditorías de seguridad, y finalizando con mi charla de seguridad en entornos de VoIP y la genial charla de Sebas sobre Android.

Tras llenar de nuevo el estómago con la estupenda comida que nos dieron, Sebas finalizó el congreso con un taller de Reversing y Malwares en Android, al cual no nos pudimos quedar por falta de espacio ya que, al igual que el resto de charlas, estaba lleno hasta la bandera.

Para finalizar el día, tuvimos una cena con otros ponentes y patrocinadores en un lugar exquisito donde, de nuevo, nos pusimos hasta arriba de buena comida. Y ya, estábamos tan casados que nos fuimos directamente a dormir.

Al día siguiente, tras darme cuenta de que un policía muy simpático había llevado mi coche al 'parking municipal', a las afueras de Jaén, donde permaneció seguro y resguardado de vándalos y delincuentes, de nuevo Antonio nos llevó a recogerlo.

Y como Sebas se fue de madrugada hacia Barcelona (recorriendo media Andalucía por problemas de temporal :) nos fuimos Alex (el Lego-adicto), Dani y yo a comer. Siguiendo los instintos, no muy fiables, de Alex, entramos al garito más cutre de toda Andalucía, donde comimos unas patatas bravas congeladas (no es que las cocinaran congeladas, sino que nos las sirvieron así), acompañadas con pan de hace 2 días y un buen vaso de agua del grifo con mosquitos flotando.

Como nota final, comentar que lo he pasado genial y me he reído muchísimo con Dani y Alex, que son unos fenómenos! Y por supuesto, me ha encantado conocer a Sebas, que aún no había visto en persona.


También agradecer a toda la organización de enred2.0 todo su trabajo organizativo y lo bien que nos han tratado. No es que haya asistido a muchos congresos pero este realmente ha sido sorprendente. Teniendo en cuenta que es el primero que realizan, han conseguido salir en la radio, en la televisión y en todos los periódicos de Andalucía. Además de conseguir patrocinadores que han colaborado económicamente, confiando en un proyecto totalmente desconocido para ellos y que, finalmente ha resultado ser todo un éxito.

Estoy totalmente convencido de que el año que viene habrá una ConectaCon 2, con una sala mucho más grande para dar cabida a toda la gente que ha venido y a los que se han quedado fuera por falta de espacio.

Y aprovecho para recordar a todos los amantes de los CTFs que en breve publicarán online los retos que ha estado Pedro preparando y que podrá participar todo el mundo. Además, habrá premio para los ganadores; eso sí, como requisito para optar a premio hay que residir en España.

Un saludo y hasta el año que viene.

----------------------------------------

Contribución por Pepeluxx
Leer más...

27 abril 2012

Recuperar la contraseña de un backup de iTunes

Ivan Golubev es un desarrollador conocido por crear la herramienta IGHASHGPU para crackear hashes MD5/SHA-1 usando la GPU y este año ha liberado Ivan Golubev's Password Recovery Suite (IGPRS) para hacer fuerza bruta sobre otro tipos de hashes con la misma técnica, como son los volúmenes cifrados TrueCrypt, WPA/WPA2 y las copias de seguridad de BlackBerry y del iTunes de Apple.

iTunes permite cifrar el contenido de los archivos que almacena en la carpeta de backup con una contraseña definida por el usuario entre una de sus opciones:



Esta contraseña está almacenada usando el algoritmo PBKDF2 (RFC 2898) con 10.000 iteraciones y su recuperación es muy lenta, pero posible. Para ello tan solo hay que abrir la aplicación y seleccionar el archivo Manifest.plist que está en la ruta: C:\Users\(usuario)\AppData\Roaming\Apple Computer\MobileSync\Backup\(hash)\Manifest.plist en el caso de Windows 7 o C:\Documents and Settings\(username)\Application Data\Apple Computer\MobileSync\Backup\(hash)\Manifest.plist para los Windows XP.

Leer más...

26 abril 2012

Un nuevo Totum Revolutum en materia de protección de datos


Recientemente se publicó por parte de la Comisión Europea, la propuesta de Reglamento relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de datos.

Si bien el marco jurídico actual a través de la Directiva 95/46/CE, sigue siendo adecuado por lo que respecta a sus objetivos y principios. La Comisión, considera que existe una fragmentación en la aplicación de la normativa sobre protección de datos, que genera escenarios de inseguridad jurídica y la percepción generalizada de la opinión pública de que existen riesgos significativos, llegando el momento de establecer un marco más solido y coherente que la actual Directiva.

La rápida evolución tecnológica ha supuesto nuevos retos para la protección de datos  dentro de la UE. Se ha incrementado enormemente la magnitud del intercambio y la recogida de datos. La tecnología permite la utilización de datos personales en una escala sin precedentes y el tratamiento de datos tiene lugar en un entorno electrónico en el que las fronteras internas entre los Estados miembros han perdido relevancia.

Por estos motivos entre otros, la Comisión ha considerado necesario una política más integradora y coherente en esta materia, mediante la promulgación de un Reglamento General de Protección de Datos (El Supervisor Europeo de Protección de Datos en su Dictamen, 2011/C 181/01, de Junio de 2.011, ya proponía un Reglamento en estos términos)

Se ha optado por la figura del Reglamento, que frente a la Directiva, se caracteriza por ser directamente aplicable a los Estados Miembros, sin necesidad de que la Disposición sea traspuesta al ordenamiento jurídico de los Estados. Se contrapone a la Directiva (Según la reiterada Jurisprudencia del Tribunal de Justicia de la Unión Europea, siempre que las Disposiciones de una Directiva resulten ser desde un punto de vista de su contenido incondicionales y suficientemente precisas, los particulares podrán invocarlas frente al Estado, en particular cuando estos no hayan adoptado, el derecho nacional a la Directiva, dentro del plazo señalado o cuando hayan adoptado la norma de manera incorrecta), también de alcance general, porque mientras ésta fija unos objetivos y un plazo vinculantes, dejando libertad a los Estados para escoger los medios adecuados (mecanismo de transposición), el reglamento es directamente aplicable y obligatorio en todos sus elementos desde su publicación en el Diario Oficial de la Unión Europea.

Por tanto, estamos frente a todo un Acto Legislativo de la Unión, que busca:
  • Una armonización real y efectiva dentro de los países miembros, reduciendo la actual fragmentación jurídica y ofrecerá una mayor seguridad jurídica, la mejora de la protección de los derechos fundamentales y la contribución al funcionamiento del mercado interior.
  • Un enfoque global y  de derecho aplicable.
  • Reforzar los derechos de las personas, los organismos de Supervisión y Control y el papel de los responsables del tratamiento.
La propuesta de Reglamento, se compone de 91 artículos (frente a los 34 de la Directiva), estructurados en 11 capítulos (frente a los 7 de la Directiva). 

Este nuevo Reglamento no supone una variación sustancial a requerimientos ya consolidados a través de nuestra legislación interna y nuestra jurisprudencia más reciente, con la excepción de las siguientes salvedades que he buscado sintetizar en 18 puntos y que en determinados casos puede suponer un nuevo totum revolutum para las organizaciones:

1. Incorporación de dos nuevos derechos:
  • Derecho al olvido (El pasado 27 de Febrero de 2.011, la Audiencia Nacional, Sala de lo Contencioso Administrativo, Sección Primera, emitió un Autoa través del cual plantaba al Tribunal de Justicia de la UE, una serie de cuestiones prejudiciales con relación a esta materia - CasoGoogle). Cancelación de los datos hechos públicos, como la cancelación automática de los datos.
  • Derecho a la portabilidad de los datos. Es decir, a transferir datos de un sistema de tratamiento a otro, sin que se lo impida el responsable del tratamiento. El derecho a obtener una copia de los datos objeto de tratamiento en un formato electrónico y comúnmente utilizado que le permita al titular del dato, seguir utilizándolo.

La portabilidad de los datos y el derecho a ser olvidado, son dos nociones interrelacionadas que buscan reforzar los derechos de los interesados. Vienen a complementar los principios ya indicados en la Directiva, que establecen el derecho del interesado a expresar una objeción al tratamiento ulterior de sus datos personales, así como una obligación para el responsable del tratamiento de suprimir la información cuando ya no sea necesaria a los fines del tratamiento.

Estos dos nuevos conceptos tienen, ante todo, un valor añadido en el contexto de la sociedad de la información, en la que cada vez es mayor el número de datos que se almacena de manera automática y se conservan durante períodos indeterminados. En la práctica se demuestra que, incluso cuando es el propio interesado quien aporta los datos, su grado de control efectivo sobre los mismos es muy limitado, lo cual resulta aún más incuestionable a la vista de la enorme memoria que representa hoy en día Internet. Además, desde un punto de vista económico, resulta más costoso para el responsable del tratamiento suprimir los datos que conservarlos almacenados. El ejercicio de los derechos de las personas es contrario, por tanto, a la tendencia económica natural. 

Tanto la portabilidad de los datos como el derecho al olvido, buscan contribuir a inclinar la balanza a favor del interesado. La portabilidad de los datos tendría por objeto proporcionar un mayor grado de control a las personas sobre su información, mientras que el derecho al olvido garantizaría que la información desaparece automáticamente al cabo de un determinado período, incluso si el interesado no realiza ninguna acción en este sentido o desconoce que los datos fueron almacenados. 

Con la codificación de un nuevo «derecho al olvido» se garantizará la supresión de los datos personales o la prohibición de un uso posterior de los mismos, sin necesidad de acción alguna por parte del interesado, a condición de que estos datos ya hubieran sido almacenados durante un período determinado. Dicho de otro modo, se podría atribuir a los datos una especie de fecha de caducidad. Este principio ya ha sido invocado en litigios ante los tribunales nacionales o aplicados en sectores específicos como, por ejemplo, los expedientes policiales o los antecedentes penales o disciplinarios.

2. Posibilidad de ejercitar los derechos de acceso, rectificación, cancelación y oposición de manera telemática. En España, ésta medida solo era exigible por la Ley de Impulso de la Sociedad de la Información, sobre aquellas empresas que prestasen servicios  al público en general de especial trascendencia económica, mientras que la nueva Reglamentación lo establece con carácter general.

3. Posibilidad de cargar una tasa frente a solicitudes de derecho de acceso reiteradas o excesivas.

En este caso, el Responsable del Fichero debe acreditar el carácter manifiestamente masivo. En esta materia, se quiere poner freno a situaciones claras y manifiestas de mala fe. Recientemente la Sentencia del Tribunal Supremo de 26 de Octubre de 2.010 calificaba como un derecho de acceso ejercitado de manera desleal y eximia de toda responsabilidad a una entidad: “una solicitud de acceso a datos personales resulta injustificada desde el momento en que el solicitante disponía ya de la posibilidad permanente  de acceso a sus datos personales por la informática (…) es claro que la solicitud de acceso a su datos personales era reiterativa, cuando no meramente retorica y por esa misma razón presentar una reclamación ante la Agencia Española de Protección de Datos por incumplimiento del deber de permitir el deber de acceso a los datos personales, supone, sin duda alguna un comportamiento contario a la buena fe. No es leal reprochar a otro no haber hecho algo que en realidad ya ha hecho. Y justificar esta imputación en la inobservancia de plazos y formas previstos en la Ley no deja de ser un abuso de los requisitos formales, algo que ha sido tradicionalmente visto como uno de los supuestos arquetipos de vulneración del principio de la buena fe

4.  Obligación para los Responsables de Fichero y Encargados del Tratamiento de llevar a cabo una evaluación de impacto de la protección de datos, antes de efectuar operaciones de tratamiento arriesgadas, siendo en determinados casos, necesaria una autorización previa. 

Es un nuevo concepto, que el Supervisor Europeo de Protección de Datos, denominó intimidad mediante el diseño. Integración de la protección de datos y la protección de la intimidad desde la fase de concepción de nuevos productos y servicios y procedimientos, que impliquen el tratamiento de datos de carácter personal. Esta intimidad mediante el diseño constituye un elemento del principio de responsabilidad.

5. Realización de análisis de riesgos (Por riesgo debemos entender, el potencial de que una amenaza determinada explote las vulnerabilidades de un activo o grupo de activos. El impacto o la severidad relativos del riesgo es proporcional al valor de la perdida/ daño y la frecuencia estimada de la amenaza para el negocio. Por tanto dentro de las organizaciones se tendrán que analizar los procesos de administración de riesgos, para identificar, evaluar y administrar los riesgos a los que se enfrenta) con el objeto de adoptar las medidas necesarias, a fin de garantizar los datos personales, contra su destrucción accidental o ilícita, o su perdida accidental y de impedir cualquier forma de tratamiento ilícito, en particular la comunicación, la difusión o el acceso no autorizado o la alteración de los datos personales. Una nueva estrategia de seguridad, evolucionando el actual modelo reactivo al preventivo.

La realización de análisis de riesgos es una práctica recomendada en términos de estándares internacionales (Normativa UNE ISO 27002 de Código de Buenas Practicas para la Gestión de la Seguridad de la Información). En derecho administrativo, el Esquema Nacional de Seguridad, establece que el análisis y gestión de riesgos debe ser parte esencial del proceso de seguridad y debe mantenerse permanentemente actualizado.

6. Los responsables de tratamiento deben establecer los plazos de conservación de los datos y deben implantar mecanismos para garantizar que se respetan los plazos fijados para la supresión de los datos y/o para el examen periódico de la necesidad de conservar los datos. Un nuevo cambio de modelo. Los datos deben ser por defecto eliminados transcurridos los plazos estipulados.

7. Se formaliza una figura equivalente en parte al Responsable de Seguridad, denominado Delegado de Protección de Datos, bajo una cualificación profesional, por mandato de dos años, debiendo notificar su nombramiento y cese a la Autoridad de Control  y debe permitirse la interactuación con él, por parte de los afectados o interesados.

8. Obligación de notificar la violación de datos, basándose a estos efectos, en lo estipulado en el artículo 4 de la Directiva 2002/58/CE sobre la Privacidad y las Comunicaciones Electrónicas, o como venia recomendando el Supervisor Europeo de Protección de Datos en su Dictamen 2011/C 181/01- Un enfoque global de la protección de datos en la UE.

La notificación de violaciones de la seguridad persigue fines y objetivos diferenciados. El más evidente, resaltado en la Comunicación, es el de servir como herramienta de información para que la ciudadanía cobre conciencia de los riesgos a los que se enfrenta cuando sus datos personales se ven afectados. Además, los requisitos de notificación de violaciones de la seguridad animan a los responsables del tratamiento a aplicar medidas de seguridad más estrictas con objeto de evitarlas. Ir a una política de máximos en vez de mínimos. Por último, sirve como herramienta para la ejecución, por parte de las autoridades encargadas de la protección de datos para iniciar una investigación sobre las prácticas generales de los responsables del tratamiento de datos. 

Esta materia me genera múltiples dudas, desde la perspectiva que si por la mera notificación a la autoridad de control de un fallo de seguridad, puede ocasionar la incoación de un procedimiento administrativo sancionador y su correspondiente sanción, puede suponer una vulneración de derechos hacia el responsable de tratamiento, al obligarle a declarar contra si mismo. 

Para que se active la potestad administrativa sancionadora, dada su especialidad y las consecuencias que se derivan de su aplicación, han de observarse todas las cautelas necesarias para la legitimación de ejercicio del “ius puniendi” que éste implica, y en aplicación de los principios que le son propios al derecho penal, y que a su vez, son compartidos por el derecho administrativo sancionador. El derecho a un procedimiento sancionador con todas las garantías de defensa, que se constituyen como derecho fundamental a un procedimiento justo y equitativo, es una interpretación sistemática de los artículos 24 y 25 de la Constitución y del artículo 6.1 del Convenio Europeo de Derechos Humanos, que engloba entre otras garantías, el no declarar contra si mismo. 

9. Certificación. Se introduce la posibilidad de creación de regímenes europeos de certificación para los productos y servicios que sean conformes a las normas de protección de la intimidad. 
Los regímenes voluntarios de certificación permitirían verificar que un responsable del tratamiento de datos ha adoptado medidas para cumplir lo dispuesto en el instrumento jurídico. Asimismo, es probable que los responsables del tratamiento de datos, o incluso los productos o servicios, que dispongan de una marca de certificación, obtengan una ventaja competitiva frente al resto. Dichos regímenes también ayudarían a las autoridades encargadas de la protección de datos en su papel de supervisión y ejecución.

La certificación de procesos, en nuestro ordenamiento jurídico, vino a ser considerado como un “atenuante” por la Audiencia Nacional, en su Sentencia de 15 de Octubre de 2.009 (Fundamento Jurídico Cuarto: “Y también que la excelencia de los procedimientos y métodos de actuación seguidos por dicha empresa actora para el desarrollo de su actividad, ha sido certificada por AENOR, tal y como la misma acredita documentalmente. De todo lo cual es necesario concluir que concurre en el caso una cualificada disminución de la culpabilidad de tal entidad sancionada (…)”), quien aplicó el artículo 45.5 de la LOPD, procediendo a la reducción del tipo de infracción, entre otros elementos, porque contar la empresa con unos procedimientos certificados por Aenor

10. Mención expresa a las normas corporativas vinculantes (Binding Corporate Rules) para los supuestos de movimiento internacional de datos para grupos de empresa.

11. Mayor exigencia de cooperación e independencia de las Autoridades de Control.

Las autoridades nacionales de protección de datos están sujetas a normas sumamente divergentes en los 27 Estados miembros, en especial en lo que se refiere a su estatuto, recursos y competencias. El artículo 28 de la Directiva ha alimentado en parte dichas divergencias debido a su imprecisión y debe especificarse más, con arreglo a lo establecido en la Sentencia del Tribunal de Justicia Europeo en el asunto C-518/07 (El Tribunal de Justicia Europeo había adoptado recientemente una resolución sobre esta cuestión en el asunto C-518/07 (54), en el que hacia hincapié en que la independencia significa inexistencia de toda influencia externa. Para desarrollar sus funciones, las autoridades encargadas de la protección de datos, deben contar con los suficientes recursos humanos y económicos.). Por este motivo, el nuevo Reglamento General de Protección de Datos ha desarrollado toda esta materia en profundidad, bajo los siguientes pilares: Autoridad, independencia, normas, competencias, funciones, poderes, todo ello con el objeto de armonizarlos a todos.

12. Se crea el concepto de ventanilla única en las Autoridades de Control. Cualquier interesado tendrá derecho a presentar una reclamación ante la autoridad de control de cualquier estado miembro, si considera que el tratamiento de los datos no se ajusta a lo dispuesto en el Reglamento.

13. Sustitución del Grupo de Trabajo del artículo 29 por el Consejo Europeo de Protección de Datos.

14. Posibilidad de denunciar o demandar por parte de organismos, organizaciones o asociaciones, en nombre del interesado (Legitimación activa).


15. La no obligatoriedad de declarar ficheros (La UE ha optado por una política de simplificación y racionalización sobre una medida que consideraba ineficaz y que ocasionaba un coste estimado de 130 millones de Euros en la EU) frente a los organismos de supervisión y control, salvo tipos específicos de operaciones de tratamiento que presentan riesgos específicos. Sin embargo será necesario seguir contando con las autorizaciones correspondientes en materia de movimiento internacional de datos y por otro lado, será necesario remitir los informes de evaluación de impacto.

16. Nuevo régimen económico- sancionador. Partiendo de la base que las sanciones deben ponerse en su cuantía mínima, salvo motivación objetiva y concisa del organismo de supervisión y control, a riesgo en su defecto de vulnerar los principios de motivación y proporcionalidad, suponen un incremento sustancial:



17. Nueva tipificación de sanciones

18. Al igual que con la reforma de la Ley Orgánica de Protección de Datos, mediante la Ley de Economía Sostenible, se abre la posibilidad del mero apercibimiento pero solo bajo dos supuestos: (i) Persona física que realiza el tratamiento sin interés comercial, (ii) Empresa u organización de menos de 250 trabajadores que trata datos como actividad auxiliar de su actividad principal.

Como diría Séneca: El quehacer es largo y la vida corta. Un nuevo giro regulatorio y nuevas medidas a adoptar dentro de las organizaciones.

------------------------------
Artículo cortesía de Gonzalo Salas Claver
Senior Manager
Grupo SIA
Leer más...

25 abril 2012

Seguridad en Tomcat - JSESSIONID en la URL

En una análisis de seguridad reciente me he encontrado una vulnerabilidad (funcionalidad) del manejo de sesiones dependiente de los Servelts  de Java que no conocía.

Según parece, añaden la sesión de un usuario a la URL como parámetro con el objetivo de controlar aquellos navegadores que no soporten el manejo de esta cabecera (wtf?).

Este comportamiento provoca que esta información sea almacenada en registros de pasarelas HTTP intermedias o historiales de navegación. Una vulnerabilidad de sobra conocida y documentada.

La siguiente captura muestra un ejemplo del comportamiento descrito anteriormente:


Para solucionar el problema en Tomcat 7, que soporta la versión 3.0 de la especificación de Servlets, basta con añadir la siguiente configuración al fichero web.xml:



En el caso de Tomcat 6, que se basa en la versión 2.5, se ha de deshabilitar de la siguiente forma:


Leer más...

24 abril 2012

Welcome to your secure /home, $user [RootedCON 2012] #rooted2012


Al igual que han hecho mis compañeros Jose Antonio Guasch y Yago Jesús, quiero publicar en Security By Default, el contenido de la presentación que hice en el congreso de seguridad Rooted CON 2012 que titulé: "Welcome to your secure /home, $user".

Uno de las secciones de seguridad que se quería motivar este año en RootedCON era el "hardware hacking", así como la interacción con diversos elementos que pueden llegar a estar en casas modernas.

Así que he conjugado el hobby/vicio que tengo con hacerme la vida más cómoda, con saciar la paranoia de poder implementar mecanismos de seguridad para mi casa.

En la parte domótica, integraba varios sistemas: una aspiradora Roomba, una alarma gestionable vía IP, un sistema de aire acondicionado en diferentes habitaciones, una estación meteorológica, monitorización con cámaras y una centralita VoIP, entre otras cosas… formando mi pequeño Skynet.

Presenté además un sistema low cost de detección de movimiento, así como reconocimiento facial y tratamiento personalizado de habitantes de una casa. Incluí también un PoC en el que simulaba una "lista negra" de personas clasificadas como "peligrosas", en la que, mediante una centralita VoIP, efectuaba una llamada a un número pre-configurado, indicando quién ha sido el "fichado" que se ha detectado en mi casa.

Todo este entramado, se gestiona mediante un bot Gtalk, que también desarrollé.

Bajo estas líneas os dejo la presentación colgada en Slideshare por la organización RootedCON


Como prometí en twitter después del evento, y ya que los videos embebidos en la presentación de Slideshare no se ve, he querido publicar en SbD el montaje que hice con la canción "El Internet" de Los Alguiens en el que aparecía mi aspiradora Roomba marcándose unos bailes por el salón de casa.

Imprescindible que encendáis los altavoces o que os pongáis unos auriculares. ¡Que os aproveche!





Leer más...

23 abril 2012


En el post Seguridad en componentes cliente de aplicaciones web basadas en DNIe: Parte 1/3 hicimos un repaso a los tipos más importantes de componentes para el navegador, ActiveX y Applets Java, así como diferentes herramientas que podríamos utilizar para su análisis exhaustivo. Pero, ¿qué tipo de vulnerabilidades nos podríamos encontrar en estas piezas de software que se ejecutan sobre el navegador del usuario?



Vulnerabilidades en componentes

A lo largo de los años, se han visto diferentes vulnerabilidades que pueden afectar a componentes ActiveX. Los tipos de vulnerabilidades son los que podrían afectar a cualquier otro tipo de software:
  • Ejecución de comandos y código
  • Desbordamientos de búfer, desbordamientos de pila, de heap...
  • Lectura, escritura, sobrescritura y eliminación de ficheros
  • Denegación de servicio
  • Evasión de restricciones
  • Acceso a información sensible
  • ...
Tomando como fuente la lista de la Common Vulnerabilities and Exposed (identificadores CVE) de la entidad Mitre, en la que se recopilan la amplia mayoría de las vulnerabilidades existentes, realizamos la búsqueda de vulnerabilidades que afectan a componentes ActiveX:

Búsqueda de vulnerabilidades de ActiveX con código CVE asignado
Se obtienen unas 854 entradas CVE, casi un 2% del total de vulnerabilidades registradas desde 1999. Cogemos el total, y vamos a clasificarlas según la vulnerabilidad que suponen, obteniendo los siguientes datos:

  • Buffer Overflows - 46.02%
  • Gestión de ficheros - 17.45%
  • Ejecución de código - 15.22%
  • Denegación de servicio - 9.84%
  • Ejecución de comandos - 5.74%
  • Descarga remota - 2.34%
  • Acceso a información sensible - 0.94%
  • Evasión de restricciones - 0.94%
  • Acceso a registro - 0.70%
  • Instalación arbitraria - 0.23%
  • Vulnerabilidad desconocida - 1.17%




Tras estas estadísticas, vamos a centrarnos en las vulnerabilidades del segundo puesto del ranking: las referentes a gestión de ficheros. Dentro de este grupo nos encontramos vulnerabilidades en componentes ActiveX las cuales al ser explotadas, permiten la lectura, sobrescritura, creación y eliminación de ficheros. 

Para el caso de la lectura, escritura y eliminación, como es obvio, es necesario conocer la ruta exacta del fichero en el equipo local del usuario en cuyo navegador se ejecuta el componente, pero como todos sabemos, existen multitud de ficheros en Windows de los que conocemos su ruta completa. Además, recordemos que estos componentes suelen requerir privilegios elevados para ser ejecutados, por lo que si no se establecen unos limites acotados, podremos acceder y modificar cualquier fichero del sistema:

  • %WINDIR%\System32\drivers\etc\hosts -> Fichero hosts de Windows
  • %USERPROFILE%\ntuser.dat -> Con información del usuario
  • %WINDIR%\system32\config\AppEvent.Evt -> registro de eventos de Aplicación
  • %WINDIR%\system32\config\SecEvent.Evt -> registro de eventos de Seguridad
  • %WINDIR%\repair\sam -> Almacena hashes de contraseñas de usuarios
  • %SYSTEMDRIVE%\boot.ini -> información del proceso de inicio de Windows
  • ...

Veamos algunos ejemplos de vulnerabilidades en componentes, que permitan aprovechar alguna funcionalidad para la gestión posterior de ficheros en un equipo víctima dónde se esté ejecutando:

ADOBE CVE-2005-0035


Vulnerabilidad del componente web de Adobe Acrobat que permitía determinar la existencia de ficheros en el sistema aprovechando una de las funciones, únicamente conociendo su ruta exacta.

ORACLE CVE-2010-3595




Vulnerabilidad del componente Oracle Document Capture de Oracle que permitía leer ficheros sabiendo su ruta completa.

IBM CVE-2004-2663




Vulnerabilidad del control ActiveX Access Support eGatherer de IBM con la que era posible la creación de ficheros con contenido arbitrario.

ChillKat CVE-2008-5002



Método inseguro en el control ChillKatCrypt2 del ActiveX Chillkat Crypt que permite la creación y sobrescritura de ficheros.

SonicWall CVE-2007-5815


En el componente WebCacheCleaner de la VPN-SSL de SonicWall existía una función que permitía la eliminación de ficheros conociendo su ruta completa.

En la siguiente y última parte de este post, entraremos de lleno en el análisis de los componentes utilizados por aplicaciones web basadas en DNIe y certificados digitales, una vez ya tenemos las herramientas suficientes para su revisión y conocemos otros tipos de vulnerabilidades que pueden darse en controles ActiveX, además de echar un vistazo a problemas similares pero para Applets Java.

Leer más...

22 abril 2012

Enlaces de la SECmana - 120





Leer más...

21 abril 2012

Security Blogger Summit 2012 #SBS12


 El jueves pasado, 19 de Abril, se celebró una nueva edición del evento Security Blogger Summit, organizado por Panda Security. Este año me invitaron, como editor de Security By Default, a participar en la mesa, por lo que quiero primeramente dar las gracias, en mi nombre y en el de nuestro blog, a la gente de Panda, en especial a Carlos Arias y Javier Merchán, viejos amigos de Panda, así como a Paula Quirós, Responsable de Comunicación y Márketing, por haber contado conmigo para esta edición.

El panel de compañeros con los que iba a compartir mesa era excepcional: Sergio de los Santos de Hispasec, César Lorenzana de Guardia Civil, Eduardo Casas de la BIT de Policía Nacional, Pablo Pérez San José como gerente de INTECO, José Manuel Tourné, Director de la Federación para la Protección de Propiedad Intelectual, Pablo Fernández Burgueño de ABANLEX y Fernando Tellado, responsable nacional de redes sociales de UPyD.

La temática de las mesas redondas eran la Seguridad y la Privacidad en la Red, así como las nuevas leyes para la garantía de la propiedad intelectual y su impacto en la privacidad de los usuarios. Para avivar más el fuego, el invitado estelar era David Bravo, conocido abogado, experto en propiedad Intelectual.

Tal como me había comentado mi compañero Yago, como ponente en la segunda edición del SBS, el inicio del evento para los participantes de la mesa redonda consistió en una opípara y amena comida en un conocido restaurante asador de Madrid. Esto sirvió para conocernos más entre nosotros, nuestras posturas sobre diversos aspectos de la seguridad, risas y sobre todo generar complicidad y colegueo.
  
Varios cafés después, nos desplazamos al Círculo de Bellas Artes de Madrid, donde tuvo lugar el evento. Moderadas por Luis Corrons, ambos debates, con la privacidad como denominador común, generaron interesantes conclusiones, y puntos de vista enfrentados entre los participantes. Las conclusiones principales ante si estamos seguros o no en la red, fue unánime: "Los peligros acechan por todas partes y evolucionan más rápido de lo que nuestra conciencia es capaz de ser educada…

El segundo de los debates, con tintes claramente legales, me dio la sensación de estar más asistiendo a un juicio, que a un evento de seguridad. El tan manido tema sobre la propiedad intelectual y las absurdas leyes "hechas a medida" para cerrar de la noche a la mañana páginas web con enlaces, fue un partido de tenis entre David Bravo y Jose Manuel Tourné, con algunos momentos para Pablo Fernandez Burgueño. Mi opinión, que en el momento de la mesa no pude dar, coincide en gran medida con lo que dijo Sergio de los Santos: No se le pueden poner puertas al campo, y está claro que en la elaboración de las leyes, se cuenta con los mejores abogados y… con ningún técnico que pueda poner coherencia ante el ambicioso objetivo (sobre todo para las sociedades de autores) de los legisladores. Es más fácil prohibir antes que dar una alternativa viable que sea un aliciente para pagar por ver una película. Señores legisladores, ustedes pongan leyes, que ya se encargará alguien de buscar la forma de saltársela.

Aprovecho, además, para agradecer también a los asistentes como público físico al evento, así como al gran seguimiento que se hizo desde Internet a través del streaming y Twitter, llegando a ser trending topic en dicha red social, el hashtag elegido #sbs12. 
Leer más...

20 abril 2012

En esta oportunidad quería compartir con ustedes distintas situaciones que se presentan con mucha frecuencia en proyectos de seguridad de la información y que sin ser el objetivo principal, desnudan la madurez en cuanto a los temas de seguridad de la información que tiene la Organización en la cual se está ejecutando el proyecto.

A lo largo de los 5 errores más frecuentes podremos encontrar problemas de base, que producto del avance de las distintas etapas se hacen cada vez más evidentes e incluso muchas veces son determinantes para el éxito o fracaso del proyecto en cuestión.

El orden de los errores es completamente arbitrario, no representa su importancia o impacto en la Organización.

Equivocar el interlocutor

En muchos casos el líder de proyecto corresponde a un área técnica y debe llevar adelante cuestiones que lo exceden en su posición y responsabilidad. Los requerimientos se traban, la información requerida se demora y ante la falta de apoyo finalmente alguien decide sobre los temas desconociendo la problemática.
Los recursos humanos no se asignan y si se hace, el proyecto se demora dado que hay que "poner en tema" al recurso asignado, que tampoco tiene la jerarquía necesaria para tomar decisiones.
Es un problema muy difícil de resolver si nuestro interlocutor no está en condiciones de obtener la información requerida, convocar a los referentes necesarios y/o tomar alguna decisión relevante en relación al proyecto. Pero si se presentara una situación similar podríamos estar ante una Organización no muy comprometida con los temas de seguridad de la información.

Creer que únicamente con productos se resuelven los problemas

Hay proyectos que se generan para desplegar un determinado producto, pero llegado el momento de la implementación comienzan a aparecer los problemas. O el producto no hace todo lo que queríamos, o requiere información que aún no hemos podido recolectar, o depende de procesos que la Organización aún no tiene implementados o con el nivel de madurez necesario.
Es muy frecuente escuchar acerca de proyectos de Data Loss Prevention (DLP) en Organizaciones que aún no tienen un inventario unificado de activos ni han clasificado su información. Finalmente para "justificar" el proyecto, la herramienta se implementa con funcionalidades mínimas para luego volver a generar algún proyecto que regularice la situación (que muchas veces no lo hace).
En organizaciones en las cuales se presente esta situación seguramente TI es la encargada de la mayoría de los temas referentes a seguridad de la información y las demás áreas no tienen ningún involucramiento al respecto. Si algo sucede en materia de seguridad "es culpa de TI".


Hacer las cosas para cumplir

Lamentablemente en reiteradas ocasiones se escucha que un determinado proyecto "se hace por PCI" o "porque me lo pide auditoria", cuando en realidad quizás no es necesario o surgió de una reunión entre gente que desconoce los problemas y el auditor confundiendo su rol hace consultoría. El resultado es conocido, surge un proyecto de remediación de un problema que quizás no existe.
Más allá de que sería ideal que los proyectos surjan de necesidades reales de la Organización, que correspondan con un objetivo claro y medible, es poco frecuente encontrarse con tal escenario. A veces se hacen para cumplir o para que los responsables de un determinado problema no asuman la responsabilidad de la falta de gestión.
En organizaciones donde se presenta el escenario comentado, es muy común encontrarse con líderes de proyecto que pretenden que el consultor tome decisiones que le corresponden a otros miembros de la Organización, que clasifique, analice, y termine decidiendo sobre temas que claramente lo exceden. Los tiempos se exceden, el proyecto cambia de alcance, queda empantanado en busca del verdadero problema o de alguien capaz de sacarlo adelante.

No acompañar al negocio

Si bien parece muy claro que TI debe brindar un servicio al negocio y acompañarlo para lograr el cumplimiento de los objetivos, es frecuente encontrarse con proyectos que no tienen ninguna relación con el rumbo que tiene el negocio. Negocios que están pensando en ir hacia la nube, en donde TI ejecuta proyectos de centralización de aplicaciones cliente/servidor o restricciones para el trabajo remoto, ambas cuestiones que muestran un camino completamente distinto entre el negocio y TI. Negocios que se despliegan sobre plataformas sociales y canales de comunicación 1 a 1 con el cliente, frente a proyectos que buscan restringir el uso de redes sociales. El resultado es conocido, siempre (o casi siempre) gana el negocio y aquello que se implementó para restringir pasa a "escuchar" sin ningún otro objetivo más que nutrir a una consola de un montón de información que nadie analizará.
No deja de ser un signo de problemas aún mayores dado que generalmente en ese tipo de organizaciones TI se considera dueña de los servidores y es frecuente que sea el usuario quien notifica los problemas dado que la "independencia" de gestión es absoluta.

Creer que los consultores conocen más la Organización que uno mismo

Si el consultor toma decisiones que debe tomar la Organización el proyecto presenta síntomas de fracaso. El valor agregado del consultor viene relacionado con la experiencia en otros proyectos, su formación, el hecho de mantenerse actualizado y de la dedicación a los temas relacionados con seguridad de la información. Ahora bien, eso no lo convierte en la persona adecuada para tomar decisiones que le corresponden a los miembros de la Organización, dado que ellos conocen el valor de la información involucrada, los objetivos de negocio de corto y mediano plazo, la historia asociada al proyecto, las idas y vueltas políticas, los intereses internos y todo aquello que es tan importante al momento de tomar decisiones.
En organizaciones en las cuales se lo espera al consultor como el gran salvador generalmente presentan más de uno de los errores que comentamos en este post y es muy probable que el resultado final de los proyectos sea un producto que nadie utilice o un proceso que luego de unos meses nadie recuerde.

Superman hay uno solo


En muchas oportunidades hemos comentado la importancia del involucramiento de los máximos referentes de la Organización en temas relacionados con seguridad de la información. Es una responsabilidad de la Dirección el estado de seguridad de su negocio, definir el nivel de protección adecuado para sus activos y asignar los recursos necesarios para lograrlo. Si esto no se presenta, es muy probable que alguien asuma una responsabilidad que lo excede y por consiguiente el propio desconocimiento del negocio haga que la estrategia de seguridad sea errónea.
El desafío para quienes deben gestionar la seguridad de la información es lograr el interés e involucramiento de los líderes, es allí en donde se debe invertir el mayor esfuerzo, para luego no dedicarle tanto tiempo y esfuerzo a reparar los errores producto de decisiones equivocadas, mal uso de los recursos y medidas desacertadas.


Los invito a realizar el ejercicio mental de pensar si estamos tomando las decisiones que están bajo nuestra responsabilidad o estamos asumiendo compromisos que realmente nos exceden.


¿Seguiremos tratando de convencer al DBA o al Desarrollador en vez de lograr el interés de la Dirección?

--------------------------------------------------------

Contribución por Maríano M. del Río
Leer más...

19 abril 2012

Mitigaciones de seguridad en EMETv2.1 (III de III)

Mitigaciones de seguridad en EMETv2.1 (I de III)
Mitigaciones de seguridad en EMETv2.1 (II de III)

Heap Spray

Es una técnica que consiste en copiar una shellcode muchas veces en memoria. Persigue como objetivo aumentar la probabilidad de éxito en la ejecución de la shellcode, debido a la dificultad que existe en conocer de antemano la posición exacta de la misma. Normalmente se hace uso de JavaScript o Flash para este fin.

EMET mitiga esta técnica preasignando las páginas de memoria virtual más utilizadas, lo cual evita que se pueda escribir la shellcode.



NULL page allocation

Mitigación que persigue como objetivo evitar problemas de seguridad con las referencias a NULL. Para conseguir este fin EMET preasigna la dirección 0x00000000.


EAF

Para comprender esta mitigación es necesario saber que Export Address Table (EAT) es un vector de punteros que contiene las direcciones de las funciones exportadas.

Existen shellcodes estáticas y dinámicas. Las primeras utilizan direcciones de memoria hardcodeadas, pero el problema es que éstas suelen cambiar con diferentes versiones de núcleos, idiomas, etc; amen de la dificultad de explotación si se usa ASLR. El hardcoding disminuye el nivel de éxito de ejecución de una shellcode. En cambio las shellcode dinámicas llaman a APIs de Windows, pero previamente deben obtener su dirección y para esto recorren la EAT de los módulos cargados. El comportamiento por defecto de la mayoría de las shellcodes es obtener la dirección base de kernel32.dll y después la del API GetProcAddress (y también LoadLibrary). Mediante ésta se obtiene la dirección de otras funciones.

Mediante EAF se filtra el acceso a la EAT de los módulos ntdll.dll y kernel32.dll permitiéndolo o denegándolo basándose en el código que intenta acceder. Para esto se usan puntos de ruptura hardware para interceptar operaciones de lectura, y Vectored Exception Handler para comprobar si la dirección origen del código que intenta acceder pertenece a un módulo. Cuando el punto de ruptura salta debido al acceso a EAT, EAF determina si el código que está accediendo es legítimo del proceso o malicioso que ha sido inyectado en el proceso mediante un exploit. Si detecta que es malicioso, entonces termina el proceso.

Para que la mitigación EAF funcione, EMET crea un nuevo hilo en el proceso. Por lo tanto no se aplica inmediatamenteal iniciarse, tarda unos milisegundos. Es importante recalcar que es una mitigación útil para prevenir la ejecución de la mayoría de las shellcodes, pero es relativamente fácil de evitar.

Existen varias formas de bypassear EAF:

  • EAF comprueba la localización de la instrucción que accede a EAT permitiendo su acceso si está dentro del segmento de código; sino termina el proceso. Por lo tanto se podría hacer que la shellcode usara instrucciones del segmento de código de un módulo cargado para leer memoria, de forma que se invoque desde la shellcode para leer EAT. En este caso el acceso pasaría como legítimo, aún habiendo sido invocado por la shellcode. Esto está explicado con mayor detalle en este enlace.

  • Como aquí se comenta, una forma de desactivar la protección EAF es poner a cero los registros debug del procesador mediante SEH, inhibiendo así los puntos de ruptura hardware. Esto sólo funciona si no tenemos activo /SAFESEH. Un ejemplo de código para inhibir EAF borrando el contenido de los registros debug sería éste. En vez de utilizar SEH para esto, hace uso de llamadas al sistema. Al utilizar syscalls no hace falta averiguar la dirección de memoria de una función accediendo a EAT, lo cual denegaría EAF. Tiene como inconveniente que no es portable, ya que el número de llamada al sistema puede cambiar con el Service Pack, etc. De hecho se advierte en el texto.


BottomUpRand

Utiliza 8 bits de entropía para aleatorizar la dirección base de diferentes secciones como stack, heap y otros. Esto permite incrementar la entropía de la dirección base de las DLLs, pasando de 15 a más de 200.

Mandatory ASLR preasigna la dirección base preferida de una DLL para forzar que se cargue en otra dirección. Si la dirección base está asignada, a esto se le llama DLL collided, y ahí es donde entra en juego Bottom Up Randomization.

Esta mitigación funciona reservando un número entre 0 y 256 de bloques de 64K mediante VirtualAlloc. Esto consume una porción de la parte más baja del espacio de direcciones. Windows asigna la dirección base de DLLs que colisionan buscando una región libre en en la parte más baja del espacio de direcciones, por lo tanto Bottom Up asegura que la dirección asignada sea aleatoria. Si no se hace uso de esta técnica de mitigación la parte más baja permanece prácticamente estática.


Artículo cortesía de David Montero 
Leer más...

17 abril 2012

Applied Cryptography FAILs [RootedCON 2012]

En la pasada RootedCon, tuve el placer de impartir la charla 'Applied Cryptography FAILs' en la que estuve hablando sobre ataques a criptografía aplicada.

Frente a las típicas charlas sobre crypto que, tal vez, suelen ser demasiado 'crudas', basadas en la parte mas teórica, con algoritmos y fórmulas matemáticas, mi aproximación fue mucho mas práctica.

La frase que podría resumir la charla es de Adi Shamir (la S de RSA): 'Cryptography is typically bypassed, not penetrated'

La charla versaba sobre:

  • Ataques a comunicaciones seguras (explicando el caso de WhatsApp y su proceso de registro bajo SSL)
  • Entidades de certificación (donde presenté SSLCop)
  • Certificados digitales (Y los mitos asociados)
  • Certificados digitales basados en software (Ataque a los certs de la FNMT)
  • SmartCards (donde presenté un prototipo de troyano para el DNI-E)
Os dejo con la presentación:


Leer más...
El proceso de infección de un binario empieza, como no podría ser de otro modo, con la inyección de un código que, uhm... digamos que "amplía el abanico sus potenciales características" (seguro que si lo escribo así puedo venderle un binario infectado a alguien a precio de versión profesional).

Esta es la fase más crítica de la infección, ya que si no la hacemos bien podemos corromper el binario a atacar, quedando nuestras acciones al descubierto. Para este fin, he enumerado una serie de técnicas a las que podemos recurrir, con sus pros y sus contras. Intentaré hacer una implementación de todas ellas, las cuales se compilarán de la misma forma que compilamos nuestro primer código PIC en la entrega anterior

A lo largo de esta entrega sólo me centraré en cómo inyectar, independientemente de las dificultades que tengamos en cada caso para lanzar u ocultar lo que hemos inoculado. De hecho, las pruebas de concepto que enlazaré inyectan código que no se puede ejecutar debido a llamadas de tipo DEBUG que dependen de cadenas ubicadas en el segmento de datos. Cómo disparar el código inyectado y qué ajustes deben hacerse en la práctica es algo que veremos en la siguiente entrega.

Inyectando al final del fichero: sobreescribiendo una cabecera poco útil

Esta es la forma más sencilla que se me ocurre, a la par que la menos portable y la que más efectos colaterales puede tener. Consiste en encontrar una cabecera de tipo PT_NOTE, transformarla en una cabecera de tipo PT_LOAD apuntando a nuestro código y a volar. Esto hoy por hoy no es tan peligroso como podría serlo antaño, pero el riesgo está ahí. Y esto se debe a que PT_NOTE informa sobre el tipo de sistema para el que el binario ha sido compilado. Varios sabores de Unix como Solaris o BSD utilizan esta información para ejecutar binarios de otros sistemas (como Linux) e infectar un binario "extranjero" utilizando esta técnica lo dejaría totalmente inútil. No es una característica de la que pueda dar un ejemplo práctico, pero las especificaciones están ahí.

Bueno, ¿y en qué dirección virtual lo cargamos? Pues podríamos cargarlo justo antes del segmento de texto (la dirección más baja, vaya), ya que por lo general el segmento de código suele cargarse en direcciones muy altas del espacio de direcciones. Ojo: esto podría no ser así en x86-64, donde los programas se cargan en direcciones muy bajas y podríamos estar muy cerca si no ya en el límite.

No podríamos cargarla, por ejemplo, justo después del segmento de datos ya que por ahí se encuentra el program break, que marca el final del heap. Debemos dejar espacio por arriba para que el programa crezca a medida que malloc (o similares, además de brk y sbrk) lo pida.

El plan de acción es el siguiente:

  1. Nos inyectamos al final del archivo en un desplazamiento alineado al tamaño de página. En x86 esto supone hasta 4096 bytes (Linux, por ejemplo, me exige que los segmentos tengan el mismo alineamiento en el archivo que en memoria. Esto es consecuencia directa del modo de carga de binarios el Linux: el archivo se mapea -no se lee- por lo que los desplazamientos relativos se mantienen)
  2. Buscamos la cabecera PT_NOTE, y si la hay, la chafamos con nuestra información de carga.

La prueba de concepto la tenemos aquí, en la cual me he abstenido de implementar la llamada a exit ya que en la práctica nunca tendríamos que llamarla:




Este código busca un binario llamado "victim" en el directorio actual y le inocula una copia suya al final del archivo para que se cargue antes del segmento de texto. Lo llamativo en este caso es que modificamos la cabecera PT_NOTE antes de hacer la inyección. Esto se hizo así debido a que así comprobábamos de paso si había una cabecera PT_NOTE que infectar. Si lo hiciésemos al revés, podríamos infectar varias veces el mismo archivo. Así, ante la ausencia de una PT_NOTE, falla.

La forma "correcta" sería buscar la PT_NOTE, salir si no se encuentra, inyectar y modificar la PT_NOTE. Pero esto no es más que añadir código redundante y aunque podría incluir la inyección directamente en replace_note he decidido moverme un poco más a lo conceptual y separar ambos procedimientos.

Se puede comprobar con varios ejecutables -y por favor, si falla, hacédmelo saber- que la inyección funciona (basta con lanzar un pmap / gdb y depurar la memoria del binario infectado) y lo mejor de todo: que es asintomático.

Inyectando al final del archivo: desplazando la tabla de cabeceras de programa
Es una mejora respecto a la anterior. Consiste en copiar toda la tabla de cabeceras de programa al "espacio sin referenciar" ampliando el segmento de texto y dando espacio así para una cabecera más de tipo PT_LOAD y así no suprimimos tal información. Pros: muy poco impacto en la tabla de cabeceras, no tenemos que borrar información, sólo añadir. Contras: de ese espacio sin referenciar, sólo podemos utilizar el relleno del segmento de texto (es decir, antes de que los bits del desplazamiento del fichero se hagan 0 y el alineamiento marque el final de la última página de código), y la cota inferior de este relleno es 0, o sea que a veces podremos explotarlo, a veces no. Es muy dependiente de la implementación de cargador (en Linux, por ejemplo, si movemos la tabla de cabeceras al final del fichero no funciona: la tabla de cabeceras DEBE estar dentro del segmento de texto). Perdemos espacio sin referenciar que podríamos utilizar para inocular nuestro código. Y tenemos que encontrar una forma de saber si el binario ha sido infectado dos veces, lo cual ya implica la existencia de una forma de detectar binarios infectados.

Hay una pega más, y es que el segmento de datos puede empezar antes del final teórico del segmento de texto (es decir, antes de que el desplazamiento se haga múltiplo de 4096). O sea que debemos comprobar que el espacio que vamos a utilizar no sea utilizado por otro segmento.

El plan de acción sería el siguiente:

  1. Buscar el relleno del segmento de texto, y calcular si "cabe" la tabla extendida (primero comprobamos el alineamiento y después si no se nos monta encima de otro segmento).
  2. Si cabe, copiamos la vieja añadiendo la nueva entrada PT_LOAD con la información que nos plazca.
  3. Modificamos el desplazamiento de la tabla (tanto en la cabecera del binario como en la cabecera PT_PHDR), y ampliamos el segmento de texto de forma que ahora contenga esos bytes extra.
  4. Copiamos el código al final del fichero, alineado debidamente a la página.

Si hacemos esto, ya podemos olvidarnos de utilizar ese agujero para inocular nuestro código. Ese espacio es precioso como ya veremos después, y es una pena desperdiciarlo de esta forma (aunque podríamos recuperarlo un poco utilizando la técnica de troceado de código que utilizaba CIH, por ejemplo). Aún así, incluyo una pequeña implementación de esta técnica:



Si probamos este código, veremos que fallará más veces (o mejor dicho, nos dirá que la infección no se pudo llevar a cabo porque no se pudieron mover las cabeceras). Esto es debido a que esa brecha entre el código y los datos no siempre estará presente. En mi sistema ha funcionado con los binarios de cat, nm, rm y octave, pero falló con los de bash, ls, gcc y dir. Esto está bien si nos importa más la calidad que la cantidad. Tendremos menos binarios infectados, pero los infectados al menos conservan el PT_NOTE.

Inyectando al final del archivo: estirando el segmento de datos

Esta es quizá la más extrema y menos viable de todas. Pegamos al final del fichero, y extendemos el último segmento hasta cubrir todo hasta el final. Pros: no tenemos que chafar una cabecera de programa existente ni añadir una nueva cabecera. Contras: hacer que esto funcione implica modificar el segmento de datos del binario a infectar para estirarlo y marcarlo como ejecutable, lo cual implica un segmento con todos los permisos encendidos y vaya, que es un canteo. Además, estirar el segmento de datos tiene como consecuencia algo desagradable: toda la basura sin referenciar que aparece detrás y que no debería cargarse se trae a memoria. Esa zona de la RAM debería estar llena de ceros debido a que pertenece a la región de variables globales sin inicializar (el .bss), por lo tanto tendríamos que arreglarlo nosotros, dando espacio suficiente para cuadrar nuestro código por un lado y anulándolo después. Otro problema, es que esta información debemos incluirla en cada inyección. Y por último, que no hay cotas superiores razonables de tamaño para el .bss, o sea que esto puede suponer un brutal (y sospechoso) incremento del tamaño del binario.

Algo que parecía sencillo se ha complicado muchísimo por una tontería. Estamos forzados a limpiar el .bss, y me niego a implementar esta monstruosidad. Pero el plan de ataque sería el siguiente:
  1. Tenemos que añadir espacio para dos números de 32 bits al inicio (o al final, por ejemplo) de nuestro código, incluyendo de dónde a donde va la zona que debemos anular. Siempre tiene que estar ahí, y necesitamos que sea fácil de ubicar.
  2. Abrimos el fichero a infectar, examinamos sus cabeceras de programa y rellenamos con 0 al final hasta cubrir todo el .bss
  3. Inyectamos nuestro código, modificando apropiadamente ese par de enteros que contienen los límites del .bss que luego deberán ser recuperados.
  4. Modificamos la tabla de cabeceras de programa para que el código inoculado sea visible en memoria. Escojo el segmento de datos y no otro porque en los ejecutables este suele ser el último segmento PT_LOAD que hay (el que se carga en zonas más altas, tanto en memoria como en el archivo).
Este truco no funciona, por ejemplo, si los segmentos están desordenados. Es decir, lo que es el último segmento en memoria no aparece como el último segmento en el archivo. Esta situación es harto rara (yo no conozco ningún ejecutable que lo haga), pero tampoco es imposible.

Inyección en el relleno del segmento de texto
Esta es, a mi ver, la forma más bonita de infectar un binario. Buscamos su segmento de texto, comprobamos si hay espacio de la misma forma que hicimos antes para ubicar una nueva tabla de cabeceras de programa, la estiramos y metemos en esos bytes de relleno (a partir de ahora, "la brecha código / datos", o simplemente "la brecha" o "the gap") nuestro código. Pros: la única forma de detectar que el binario ha cambiado sería comparando byte a byte con el original. El binario no crece en absoluto, no aparecen nuevos segmentos PT_LOAD (estiramos uno existente), no cambiamos más que su tamaño y por lo que resta es totalmente asintomático. Contras: los años ochenta han quedado atrás y hablar en código máquina ya no está de moda, la única forma de que esta técnica fuese viable sería reducir nuestro código a la mínima expresión -y para eso necesitaríamos escribirlo enteramente en ensamblador, con los consiguientes problemas de mantenimiento y depuración que ello implica-, y aún así las situaciones en las que encontrásemos una brecha lo suficientemente grande no serían especialmente numerosas.

Este método de infección queda reservado para los paranoicos de la optimización y gente a la que su religión le impide utilizar más de una instrucción para intercambiar el valor de dos variables. Si alguien es lo suficientemente hábil como para explotar esta técnica y hacer uso útil de ella, a saber de qué otras cosas será capaz. Temblad.

En vez de hacer una prueba de concepto de esto esperaré hasta la siguiente técnica, que la completa y la contiene, haciendo este tipo de infección un poco más viable.

Inyección segmentada: rellenando agujeros del segmento de código

La mejor forma de introducir esta técnica es hablando de la instrucción NOP. La instrucción NOP significa "No OPeration", cuando la CPU la lee pierde un ciclo y lee la siguiente instrucción. Esta instrucción tiene varios usos de cara a la optimización, a veces perder un ciclo haciendo nada evita la sobrecarga del procesador en ciertos bucles, a nivel de kernel también se suele utilizar para esperar un número concreto de ciclos hasta que un dispositivo termine de cambiar su estado, e incluso en algunas arquitecturas sirve para introducir burbujas artificiales y evitar los denominados "riesgos" del pipeline de la CPU.

Pero lo importante aquí es cuando se usa para rellenar. GCC (y muchísimos compiladores y enlazadores) intenta alinear funciones de vez en cuando, y los agujeros (que nunca se alcanzan por el flujo del programa) acaban convertidos en NOPs. Esto se hace sobre todo para que las zonas de código no ocupadas sean coherentes con el tipo de segmento en el que se encuentran, y la mejor forma de decir que esos bytes no sirven para nada (no hacen nada), es estableciéndolas a NOP.

La instrucción NOP en x86 mide un byte, que es 0x90. En algunos ejecutables existe una cantidad ingente de NOPs seguidos que podrían ser utilizados para incrustar en ellos una versión troceada de nuestro código (y acompañada de los debidos metadatos). Y si no me creéis, adjunto una herramienta que contabiliza estas regiones. Allá donde encuentre más de 5 o más NOPs seguidos, asume que es un relleno y los suma a cierto contador. Así cuenta cuántos bytes útiles podríamos utilizar en un binario para ubicar nuestro código.

Esto es muy similar a lo que hacía CIH, con la salvedad de que no se aprovecha de espacios entre secciones en sí, si no que usa espacios dentro del propio código.

Pros: en binarios grandes, por ejemplo, esto es una fiesta. La libc6 tiene más de 9 kilobytes en NOPs. Y una vez infectado, encontrar los pedazos que conforman el código puede ser infernal a menos que se conozca con exactitud dónde se encuentran. El binario no crece y tampoco aparecen cabeceras extras, sólo crece un pelín el segmento de código, no mucho más. Contras: la cota inferior de NOPs por binario es 0. En los casos más comunes encontraremos 200 o 300 NOPs usables, y encontrar más de 500 ya es complicado. El único sentido que se le puede dar a esto es como complemento a la técnica de inyección en la brecha. Tampoco tenemos garantía de que esas tiras de 5 nops seguidos no se usen para algo. Normalmente nunca se suelen ejecutar, pero tampoco es algo seguro. Además, hay que incluir una rutina de reensamblado, lo más pequeña posible y escrita en ensamblador que no se trocee.

Para la prueba de concepto, vamos a ponernos en un caso realista: queremos aprovechar conjuntamente la brecha y los NOPs.

Primero pensemos en cómo trocear nuestro código. Para reducir al máximo los metadatos que debemos usar para controlar los trozos (donde empiezan y cuánto miden), yo describiría toda esa información en 4 bytes por trozo: en 3 bytes metería el desplazamiento del trozo (eso nos da 24 generosos bits para direccionar, no vamos a encontrar muchos binarios con 16 MiB de código por ahí) y en el byte restante introduciría el tamaño del tozo (y me parece hasta demasiado, las tiras de NOPs no suelen superar los 16 bytes, ya ni digamos 255).

Esto quiere decir que por cada trozo, tenemos que guardar 4 bytes adicionales. ¿Dónde metemos esa información? Pues a mí se me ocurren dos sitios. El primero, al principio de cada trozo. Como forzamos a que cada uno tenga 5 bytes, así aseguro al menos un byte libre. El segundo, en la brecha.

Cada cual tiene sus más y sus menos, aunque ambos gastan exactamente la misma cantidad de memoria. Sin embargo, la brecha es un lugar muy especial: cuando existe normalmente es pequeña, por lo que meter todos los metadatos ahí va a ser una pérdida dolorosa, y necesitamos esos bytes lo más libres posibles para que al menos la rutina de reensamblado quepa entera (la cual tiene que hacer mmap, entre otras cosas). La otra técnica implica más código contiguo en la brecha (lo cual es bueno) a costa de complicar el código de reensamblado.

Es mejor estudiar esto con binarios reales, o sea que me tomé la molestia de escribir una pequeña aplicación -en el formato de código inyectable que estoy utilizando como ejemplo- que contabiliza el espacio usable en un binario víctima y evalúa su viabilidad. En mi caso, tengo unas estadísticas de viabilidad similares a las que tenía con la técnica del desplazamiento de cabeceras (aunque, claro esta, dicha viabilidad comenzará a caer a medida que el código crezca). No está tan mal.

Lo principal ahora es comprobar que no haya efectos colaterales. Y para ello recurriremos a la implementación difícil, añadiendo un criterio de "mínima contigüidad": si no caben 64 bytes contiguos de nuestro código en el relleno del segmento de texto, entonces la rutina de desensamblado no cabe y no puede hacerse. Puse 64 por poner algo, esto habría que afinarlo después. He modificado el programa anterior hasta llegar a este código que prueba la viabilidad de este ataque en concreto, lo que nos da un código ligeramente más pequeño. Si repetimos el experimento con varios binarios de nuestro sistema, las estadísticas se ajustan un poquito más a la realidad.

Pero bueno, basta de hacer estimaciones teóricas, y vayamos a la práctica. ¿Puede hacerse realmente?

Para la prueba de concepto reservaré espacio en .code_bottom para un par de enteros más, destinados a ubicar el tamaño de la zona contigua y el desplazamiento del siguiente trozo (si lo hay). Es una cantidad que debo leer en el reensamblado para saber si el código se ha cortado o no. Si está a 0, es que todo está en la brecha y fin de la historia. Si está a distinto de 0, entonces es el tamaño de la zona contigua me viene dado por ese valor, y el desplazamiento relativo me viene en el siguiente entero. Eso implica que tengo que llamar a mmap, reservar una página (o más) y ensamblar nuestro código ahí.

En este caso es importante que ahora compilemos con -fno-align-functions, para evitar que GCC nos rellene el código con NOPs y pudiendo estropear así el algoritmo de búsqueda.

Esta implementación la tuve que reducir bastante, y aquí abandoné los open / reads por mmaps. Mucho más sencillo de usar, menos llamadas a funciones y menor tamaño en general.



A pesar de todo, este código es grande, muy grande, y hace cosas redundantes. Así me pongo en un caso muy malo: en la mayor parte de los intentos de infección, o no cabe, o cabe todo en la brecha. Sólo he encontrada dos casos en los que la inyección segmentada es la solución: en los binarios de mplayer y busybox, y sólo en el de mplayer la infección es asintomática (en busybox algo extraño pasa, que parece leer cosas del segmento de código y los comandos fallan).

Mientras escribo estas líneas escucho música desde el mplayer infectado y aún ayer lo utilicé para ver relajadamente un par de películas de fansub patatero. De aquí os podéis descargar el binario original, y de aquí el infectado. Haciendo un objdump -sdx (o un simple cmp -l) podréis encontrar las diferencias. Y como prueba de que la información se puede recuperar, he escrito un pequeño programa que detecta un binario infectado y extrae el código inyectado.

Y en el próximo episodio...
Ya hemos visto las diversas técnicas que tenemos a nuestra disposición a la hora de inyectar en ELF. Probablemente haya más, pero con casi toda seguridad se podrán describir en términos de combinación de ideas de las anteriores.

Sin embargo, si la inyección era la parte más delicada (ya que si no la hacemos bien podemos destrozar lo que estamos infectando) ahora queda la parte más importante, a partir de la cual podemos empezar a tratar con binarios infectados que realmente ejecutan código extra. En la próxima entrega veremos a qué punteros podremos engancharnos, cómo detectar nuestro punto de entrada y la tan ansiada rutina de reensamblado requerida por la técnica de infección segmentada.
Leer más...