07 julio 2011

Auto DNI-E

Una de las críticas mas habituales sobre el DNI electrónico es el, para algunos, excesivo número de veces que aparece la ventana que pide el PIN para realizar cualquier operación con el DNI.

En parte esto está motivado por las restricciones que se le han aplicado para acceder a la información que contiene. Normalmente una SmartCard suele requerir el PIN para realizar operaciones en las que interviene la clave privada, pero en el caso del DNI también para acceder al certificado (la parte pública)

Para hacer mas llevadero lidiar con el hecho de introducir el PIN en tantas ocasiones, hemos desarrollado 'Auto DNI-E', con esta herramienta solo tendrás que escribir en una ocasión el PIN, y ella rellenará por ti la ventana del PIN asociada al DNI-E.

El funcionamiento es bastante sencillo:

Desde un cmd.exe lanzamos Auto DNI-E de la siguiente forma:

>autodni.exe -p 12345678

El flag -p indica el PIN de nuestro DNI, adicionalmente podemos añadir el flag -a 1 si además de rellenar la ventana, queremos que también la acepte, es decir, que no tengamos que hacer nada cuando aparezca la ventana del PIN.

>autodni.exe -p 12345678 -a 1

(y mágicamente la ventana se rellenará y aceptara solita)

Una vez en funcionamiento, Auto DNI-E 'busca' la ventana asociada al PIN y cuando la encuentra, le envía el pin empleando la función SendKeys()

Puede suceder que la fisonomía de la ventana asociada al PIN difiera de una implementación a otra (e incluso depende del lenguaje en el que esté configurado Windows), por eso, junto con la herramienta hay un fichero llamado 'captions.txt' donde se pueden añadir mas tipos de ventanas.

Si Auto DNI-E no funciona en tu equipo, simplemente identifica el caption de la ventana empleando, por ejemplo, Winspy++


Una vez tengas identificado el caption, lo añades al fichero captions.txt y debería funcionar. Adicionalmente estaría bien que también nos lo hicieras llegar para futuras actualizaciones

La herramienta se puede descargar desde aquí
Leer más...

06 julio 2011

Android y el uso de la SD Card

No llevo mucho tiempo manejando Android pero la verdad es que la facilidad con la que una aplicación puede hacer más de lo que dice me está sorprendiendo... No es nada raro descargarse aplicaciones que no provienen de fuentes "de confianza", y viendo el nulo control que hay en el Market por parte de Google (ver 'La cruda realidad del Market de Android'), puedes llevarte una sorpresa.

Dejando de lado las posibles técnicas para saltarse los permisos que el usuario otorga (más bien acepta) a la aplicación, me gustaría hacer hincapié en algo mucho más simple, lo que todos pueden ver pero que no debería ser público, el típico 'read4all'.

Cuando instalamos una aplicación se nos muestran unos permisos que tenemos que aceptar. En el blog El Android Libre tenéis un artículo en el que se explica cada uno de ellos. Estos permisos delimitan bastante las capacidades de las aplicaciones pero, ¿son suficientes?.

Voy a poner un par de ejemplos en los que los permisos igual no son lo suficientemente restrictivos:

1. Tu información personal – Leer datos de contacto
Cuando estaba realizando la aplicación QuoteIt me sorprendió que el permiso fuera tan genérico, pudiendo acceder a todos los datos de cualquier contacto. Si la aplicación solo necesita el email de los contactos, ¿por qué debería tener acceso también a su dirección, teléfono, etc? Creo que se debería mantener el permiso global pero crear subpermisos para que podamos controlar algo más a qué datos accede la aplicación.

2. Almacenamiento – modificar/borrar archivos en SD
Al igual que hay un permiso para poder escribir en 'sdcard', ¿por qué no lo hay para la lectura?. Como veremos más tarde, hay demasiada información delicada almacenada en 'sdcard' como para que no haya un control de qué aplicaciones pueden acceder a ella.

3. Comunicación de red – acceso íntegro a Internet
Al igual que en el primer ejemplo, programando QuoteIt Slim me sorprendió que la ejecución de comandos no necesitara declaración de permisos de seguridad. Es cierto que los comandos disponibles permiten hacer muy pocas cosas pero sigue siendo un problema. En la RootedCON 2011, Francisco Jesús Gómez y Carlos Juan Diaz ('Cloud Malware Distribution: DNS will be your friend') comentaron como era posible almacenar y distribuir malware a través de la infraestructura de servidores DNS Caché públicos de Internet. Relacionado con este tema, puesto que una aplicación no necesita ningún permiso para realizar un ping por consola, podría aprovecharse de este método para controlar la aplicación u obtener información del dispositivo de forma transparente.

Vistos estos tres ejemplos, ahora toca profundizar un poco más con el tema del 'read4all' y la 'sdcard'.

El problema, a parte de lo ya comentado anteriormente, creo que se encuentra en el uso que hacen las aplicaciones de la SD. Entiendo que en él se almacene información que pueda resultarle util al usuario cuando conecta el teléfono al ordenador en modo USB, pero ¿es recomendable sabiendo que cualquiera puede acceder a esos datos?. ¡Las fotos sí pero mis conversaciones de WhatsApp no!

Alguna de la información que se almacena en la SD (p.e de las aplicaciones que tengo instaladas en mi teléfono):

1. La cache de la aplicación de Tuenti.
2. Fotos y videos de la cámara (y capturas de pantalla).
3. Descargas realizadas.
4. Titanium Backup.
5. Backup Dolphin HD
6. Databases (automáticas) de WhatsApp
7. Caché de Dropbox.

Como ya he dicho, hay algunas que entiendo que estén ahí almacenadas pero, ¿la caché de Tuenti?, ¿backups sin proteger?, ¿la caché de Dropbox?, etc. Con respecto a los backups, Titanium debería de protegerlos pues es un peligro que cualquier aplicación pueda acceder a esos archivos, el de Dolphin HD no se genera salvo que el usuario lo haga manualmente por lo que si se hace, hay que retirarlo lo antes posible (puedes tener credenciales almacenadas, etc) aunque todos los backups deberían protegerse. Con respecto a WhatsApp, ahora las bases de datos ya están cifradas (aunque desconozco lo seguro que pueda ser) aunque por ese mismo motivo, como el usuario no puede acceder a su contenido, no veo comprensible que estén ahí. Finalmente, lo que más me sorprendió es la carpeta Dropbox que contiene todos los archivos que hayas visualizado... (desde la aplicación puedes borrar la caché)

Como véis, si las aplicaciones utilizan la SD para almacenar información sensible sin proteger, cualquier aplicación podrá acceder a ella sin problemas. Sobretodo hay que tener cuidado con el tema de backups, como el caso de Titanium.

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

Artículo cortesía de Luis Delgado
Leer más...

05 julio 2011

Pastebin Leaks

Supongo que cuando los creadores del servicio Pastebin lanzaron la iniciativa allá por el 2002 con la idea de fomentar que la gente compartiera código fuente no podían imaginar la notoriedad que iba a adquirir por otros motivos.

A raíz de las ultimas oleadas de 'hacktivismo', Pastebin se ha convertido en el lugar favorito para colgar contraseñas robadas, conversaciones de chat o hackeos con sus correspondientes paso-a-paso.

A día de hoy Pastebin es un repositorio con información de lo mas extraña y diversa.

Jaime Blasco, ponente habitual en eventos relacionados con la seguridad y todo un CRACK -en mayúsculas- ha creado un interesante servicio llamado 'Pastebinleaks' que monitoriza pastebin y alerta vía Twitter sobre los hallazgos que va encontrando.

Valga como ejemplos de los hallazgos que encuentra este log con un buen numero de usuarios / contraseñas de correo electrónico, contraseñas de servicios web o información sobre un ataque SQL Injection  



Seguir la cuenta en twitter es altamente adictivo ya que la información que va encontrando supera con creces lo que uno puede imaginar. 
Leer más...

04 julio 2011

El smile de la muerte: Puerta trasera en vsftpd 2.3.4

Se ha descubierto una puerta trasera nueva, que podríamos añadir al recopilatorio que se realizó en SecurityByDefault con las puertas traseras más escandalosas. En esta ocasión, le toca el turno a un servidor FTP de uso muy extendido: vsftpd. Curiosamente, este software FTP tiene el slogan de "probablemente el servidor FTP más seguro y rápido para sistemas UNIX". 

Quizás el software lo sea, pero su distribución se ha visto comprometida. Chris "ScaryBeast" Evans, su creador, informaba en su blog Scarybeast Security acerca de este incidente, tras ser avisado por un usuario. Se comprobó que el software en el fichero compilado vsftpd-2.3.4.tar.gz hospedado en su sitio principal contenía una puerta trasera, en la que escribiendo como nombre de usuario del servidor FTP el símbolo de la sonrisa o smile ( :) ) se conseguía acceso total y ejecución de comandos en el servidor al devolver una shell del sistema.

Analizando el código diff (comparación con versiones anteriores) del servidor FTP comprometido que fue volcado a un pastebin, apreciamos claramente la puerta trasera así como su acción a desencadenar:


Tras la comprobación en el nombre de usuario de que el primer carácter (almacenado en p_str->p_buf[i]) es el símbolo ":" y que en el segundo carácter (almacenado en p_str->p_buf[i+1]) se encuentra el símbolo ")", se ejecutaría la shell en el puerto 6200 TCP, cuya definición se encuentra en la función vsf_sysutil_extra(), que pasamos a mostrar a continuación:


Fácil, sencillo, sin cifrado, ni ofuscación, todo clarísimo y nada sofisticado. El autor, tras el incidente, ha movido la página del proyecto, así como el software, a una cuenta de Google App Engine, en la que dice que se siente más seguro y cuyo servicio le inspira más confianza.


Leer más...

03 julio 2011

Enlaces de la SECmana - 78

Leer más...

02 julio 2011

NetworkingActivo: Desayuno de Trabajo de Ciberseguridad

Networking Activo es una empresa que organiza desayunos de trabajo y reuniones privadas con profesionales de sectores del Comercio Electrónico, Contenidos Online, Gestión del Talento, Inversión, Marketing Online y Tecnología para tratar las ideas más candentes propuestas por los propios participantes incluso, con la finalidad de generar un informe de inteligencia de libre descarga y lectura posteriormente.

Para los que no conocéis a su fundador, Emilio Márquez, deciros que es un emprendedor y blogger sevillano, apasionado por el networking social, bien conocido en el mundo Internet, habiendo comenzado en redes telemáticas como usuario de BBS en 1992.

En esta ocasión, a primeros de Mayo, Emilio invitaba a varios profesionales de la seguridad informática a un desayuno de trabajo para hablar de CiberSeguridad.

Varios días antes, Emilio nos daba de alta en el foro privado de Networking Activo y nos pedía colaboración en el brainstorming sobre los temas a tratar referentes al estado del arte de los diversos riesgos de seguridad actuales.

La experiencia fue bastante enriquecedora y, particularmente, me permitió desvirtualizar a gente de Hispasec, volver a ver a conocidos del sector de empresas como Panda Security o S21Sec y conocer a grandes profesionales la seguridad procedentes de integradores, auditores y empresas de hosting.

Así pues, acaba de ser publicado el resumen con las conclusiones e ideas de todo aquello que fuimos hablando a lo largo del desayuno.

En definitiva, fue una mañana interesante compartiendo, profundizando y escuchando opiniones de gente experta sobre temas tan de moda como los riesgos del cloud computing, normativas y estándares a cumplir por parte de las empresas, riesgos en dispositivos móviles, seguridad en sistemas críticos (SCADA), Esquema Nacional de Seguridad, virtualización, DLP, redes sociales, concienciación de usuarios, etc,… y como siempre sucede en este tipo de encuentros, un rato agradable y ameno gracias a diferentes experiencias y "batallitas" de los tertulianos (y tertuliana) que daban cuerpo y reforzaban determinadas opiniones.
Leer más...

01 julio 2011

Los abuelos de LulzSec

LulzSec ha revolucionado el panorama de la seguridad con su forma tan sarcástica y burlona de publicar ataques a gran escala a sitios realmente importantes.

Mucha gente asiste atónita al 'fenómeno LulZsec'. A unos les parece bien, otros opinan que no es la manera y tal vez la gran mayoría simplemente comen palomitas mientras leen (o mejor dicho, leían) el timeline de LulzSec

Lo que probablemente no todo el mundo sepa es que, como en el Rock&Roll, en materia de gamberrismo por internet casi todo está ya inventado.

A finales de los años 90 hubo un grupo de hackers que tenían un planteamiento similar: se ocultaban bajo un nombre humorístico y causaban furor en las listas de correo de seguridad (en aquella época no había Twitter ni parecido). El nombre que empleaban: GOBBLES

LulzSec se define como: 'the world's leaders in high-quality entertainment at your expense'

Y GOBBLES: 'the largest active nonprofit security group in existence'

La diferencia con respecto a LulzSec es que ellos eran, bajo mi punto de vista, técnicamente mucho mas brillantes y tenían mas clase. En vez de atacar servidores con burdos ataques DoS o aprovechar vulnerabilidades en servidores mal gestionados, GOBBLES se dedicaba a humillar a expertos de seguridad publicando exploits contra software teóricamente 'difícil de hackear'.

Memorables fueron sus andanadas contra Theo de raadt líder del proyecto OpenBSD y OpenSSH a quien vejaron públicamente en listas de correo y cuando publicaron un aviso de seguridad de OpenSSH.

Tal vez su momento de gloria -técnicamente hablando- fue cuando encontraron una vulnerabilidad en el servidor web Apache y se aseguraron concienzudamente de que fuese compatible con ... OpenBSD (rumores dicen que Theo sufrió una ulcera por culpa de GOBBLES ...)

En total, antes de su cese de actividades dejaron una bonita colección de exploits que abarcaban diferentes tipos de software, desde servicios web como Hotmail, hasta clientes de correo electrónico.

El momento con más repercusión mediática fue a raíz de un comunicado que emitieron explicando como la RIAA (SGAE Americana ...) les había contratado para crear una suerte de virus que se transmitiera a través de ficheros mp3. De primeras suena a fábula, pero resulta que junto con el comunicado liberaron un exploit plenamente funcional para el software de reproducción mp3 'mpg123' y prometieron que liberarían otros exploits para Mplayer o Winamp. La idea era emplear estos exploits para infectar a todos los usuarios y poder monitorizar el uso que hacían de los mp3  

Claramente LulzSec ha conseguido un nivel de trascendencia en medios periodísticos inmensamente superior a GOBBLES, pero desde un punto de vista meramente técnico, GOBBLES eran buenos de verdad.
Leer más...