viernes, 23 de noviembre de 2012

Los iPads de sus señorías

Hace unas semanas saltaba en la prensa una noticia que no me pudo pasar desapercibida [1] [2] [3] [4]. La noticia decía que unos 20 diputados españoles habían perdido el iPad que a principios de la legislatura, hace menos de un año, les habían dado para el desempeño de sus funciones. Dejando a un lado la controversia suscitada acerca de la necesidad o no de esta herramienta para todos los diputados y la responsabilidad que tienen estos diputados respecto a los dispositivo corporativos, vayamos a lo que nos preocupa en este blog: la seguridad.
Como es evidente, en estos dispositivos se pueden guardar documentos, correos electrónicos, teléfonos, en general información que podemos considerar sensible para una organización y en este caso para el conjunto del Estado. Me gustaría pensar que para usar estos dispositivos habrán tomado todas las medidas de seguridad necesarias, como puede ser cifrado, bloqueo e incluso borrado de la información ante varios intentos de acceso fallidos, acceso mediante contraseña, etc., además de tomar las medidas adecuadas para que ante una posible pérdida estos puedan ser bloqueados remotamente e incluso ser borrado su contenido.

Pues al parecer, esto va a quedarse en un mero deseo pues ya ha salido en algunos medios información indicando que estos dispositivos ni siquiera tenían activada la herramienta “Find my iPad” que se puede instalar en los dispositivos con iOS y que en caso de pérdida permite localizarlo, enviar un mensaje al dispositivo, incluso borrar el contenido del mismo. Después de conocer esto yo pregunto: ¿qué información contenían esos dispositivos? ¿Podían contener información confidencial? ¿Podían contener información con datos de carácter personal?
Como toda organización el Congreso de los Diputados debería tener y aplicar, cosas que desconozco, una política de uso de los dispositivos que ponen a disposición de los parlamentarios para el desempeño de sus funciones y estos firmar una aceptación de la misma. Además el servicio, área o departamento competente para los asuntos tecnológicos debería tomar las medidas oportunas para evitar que ante una pérdida del dispositivo cualquier persona pudiera acceder a la información confidencial y sensible, aun cuando este tipo de medidas chocasen con las reticencias de los diputados. Me parece que nunca vamos a saber la información que contenían esos dispositivos, ni siquiera las medidas de seguridad aplicadas, pero quiero seguir pensando que la información no era importante o confidencial y que se habían tenido en cuenta medidas como las que desde S2 Grupo hacíamos algún tiempo para la seguridad del iPad.
(Puedes seguirnos en Twitter: @SecurityArtWork)

DVWA training para nuevos ninjas Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con Facebook


Yo siempre dije que para realmente entender algo y sumar conocimiento siempre hay que practicarlo, resulta que si no puede vivir esa experiencia me cuesta mucho comprender  las cosas, lo mismo me pasa con el hacking, solo que dar práctica a algunas técnicas y explotación de vulnerabilidades puede ser tomado con un acto ilícito y nos podríamos estar metiendo en grandes problemas.

Si la idea es practicar y vivir la experiencia de utilizar herramientas y avanzar en los conocimientos hacking, yo le recomiendo que instalen el entorno controlado llamado DVWA Damn Vulnerable Web App, basta con tener un entorno LAMP, un navegador web para accederlo y ganas de aprender a explotar fallos de seguridad.

Entre los training que encontramos podemos explotar vulnerabilidades de Ejecución de Comandos, XSS, RFI, LFI, SQL Injection, File Uploads, CSRF y Fuerza bruta entre los más conocidos, además para mejorar las habilidades podemos escoger diferentes niveles de dificultades para los novatos y los más experimentados.

Como les comentaba al principio del post, este entorno es fantástico si la intención es aprender  y sumar conocimiento, en las técnicas hacking más utilizadas y ranqueadas en la OWASP

Saludos!

Fuente: caceriadespammers

Dionaea, proyecto para el estudio de ataques y malware

El estudio de los ataques automatizados es muy interesante para poder ver, como los “malos” consiguen acceso a servidores desde los cuales luego hacen formar parte de su botnet, por ejemplo.
Uno de los proyectos MAS interesantes que he visto hasta ahora se trata de Dionaea, este proyecto suple al ya conocido Nephentes. Que seguro que mas de uno conoce.
Después de solo UN dia de tener Dionaea en funcionamiento ya me ha dado resultados bastante interesantes.
Para hacer la instalación lo tienen muy bien documentado, lo podremos encontrar aquí:
Dionaea
Recomiendo hacer la instalación en Ubuntu, mucho mas sencillo jeje :P
No volveré a poner la parte de instalación, mirad la web oficial, está explicadito, eso si, seguid todos los pasos.
Cuando hayamos arrancado Dionaena, pondrá a la escucha una serie de servicios:
root@marc:/home/marc# lsof -nPi
dionaea 31345 root 10u IPv4 833300 0t0 TCP 127.0.0.1:80 (LISTEN)
dionaea 31345 root 11u IPv4 834271 0t0 TCP 127.0.0.1:443 (LISTEN)
dionaea 31345 root 13u IPv4 834272 0t0 UDP 127.0.0.1:69
dionaea 31345 root 15u IPv4 834273 0t0 TCP 127.0.0.1:21 (LISTEN)
dionaea 31345 root 16u IPv4 834274 0t0 TCP 127.0.0.1:42 (LISTEN)
dionaea 31345 root 17u IPv4 834275 0t0 TCP 127.0.0.1:445 (LISTEN)
dionaea 31345 root 18u IPv4 834276 0t0 TCP 127.0.0.1:135 (LISTEN)
dionaea 31345 root 19u IPv4 834277 0t0 TCP 127.0.0.1:5061 (LISTEN)
dionaea 31345 root 20u IPv4 833301 0t0 UDP 127.0.0.1:5060
dionaea 31345 root 21u IPv4 833302 0t0 TCP 127.0.0.1:5060 (LISTEN)
dionaea 31345 root 22u IPv4 833303 0t0 TCP 127.0.0.1:1433 (LISTEN)
dionaea 31345 root 23u IPv4 833304 0t0 TCP 127.0.0.1:3306 (LISTEN)
dionaea 31345 root 24u IPv4 833305 0t0 TCP.153:80 (LISTEN)
dionaea 31345 root 25u IPv4 833306 0t0 TCP .153:443 (LISTEN)
dionaea 31345 root 26u IPv4 833307 0t0 UDP153:69
dionaea 31345 root 27u IPv4 833308 0t0 TCP 153:21 (LISTEN)
dionaea 31345 root 28u IPv4 833309 0t0 TCP 153:42 (LISTEN)
dionaea 31345 root 29u IPv4 833310 0t0 TCP .153:445 (LISTEN)
dionaea 31345 root 30u IPv4 833311 0t0 TCP .153:135 (LISTEN)
dionaea 31345 root 31u IPv4 833312 0t0 TCP 46.4.94.153:5061 (LISTEN)
dionaea 31345 root 32u IPv4 833313 0t0 UDP .153:5060
dionaea 31345 root 33u IPv4 833314 0t0 TC 94.153:5060 (LISTEN)
dionaea 31345 root 34u IPv4 833315 0t0 TCP 53:1433 (LISTEN)
dionaea 31345 root 35u IPv4 833316 0t0 TCP 53:3306 (LISTEN)
dionaea 31345 root 36u IPv6 833319 0t0 TCP [:fe00:26db]:80 (LISTEN)
dionaea 31345 root 37u IPv6 833324 0t0 TCP [:fe00:26db]:443 (LISTEN)
dionaea 31345 root 38u IPv6 833329 0t0 UDP [:fe00:26db]:69
dionaea 31345 root 39u IPv6 833334 0t0 TCP [:fe00:26db]:21 (LISTEN)
dionaea 31345 root 40u IPv6 833339 0t0 TCP [:fe00:26db]:42 (LISTEN)
dionaea 31345 root 41u IPv6 833344 0t0 TCP [fe00:26db]:445 (LISTEN)
dionaea 31345 root 42u IPv6 833349 0t0 TCP [fe00:26db]:135 (LISTEN)
dionaea 31345 root 43u IPv6 833354 0t0 TCP [fe00:26db]:5061 (LISTEN)
dionaea 31345 root 44u IPv6 833359 0t0 UDP [fe00:26db]:5060
dionaea 31345 root 45u IPv6 833364 0t0 TCP [f:fe00:26db]:5060 (LISTEN)
dionaea 31345 root 46u IPv6 833369 0t0 TCP [:fe00:26db]:1433 (LISTEN)
dionaea 31345 root 47u IPv6 833374 0t0 TCP [:fe00:26db]:3306 (LISTEN)
dionaea 31345 root 54u IPv4 846555 0t0 TCP .153:41598->.45:80 (CLOSE_WAIT)
He modificado las IP’s por razones evidentes :P juju
Dionaea expone servicios a la red como SMB, SIP, SMB, MYSQL y todos los resultados los guarda en una base de datos SQLite.
Además es capaz de capturar binarios que se utilicen en los ataques :D Simplemente, brillante.
De los servicios que emula y que guarda en base de datos, he mirado la base de datos de SQLite para que me diera los resultados, a continuación, algunos de ellos:
Hay muchísima cantidad de intentos de acceso por MYSQL, además también he sido capaz de registrar los usuarios y los passwords que se han usado en los intentos de acceso.
La cantidad de accesos simultáneos es impresionante….
También ha sido capaz de capturar 5 binarios :D
:D Ya miraré los binarios mas adelante jeje
Además veo que se utiliza de manera automatizada herramientas como SIPvicius para auditarlos.
Os recomiendo usar Dionaea, se pueden aprender muchas cositas jeje.
Aunque no es indetectable, nmap puede detectar si un servidor tiene corriendo Dionaea
443/tcp open ssl/https?
| ssl-cert: Subject: commonName=Nepenthes Development Team/organizationName=dionaea.carnivore.it/countryName=DE
| Not valid before: 2012-09-10 17:54:34
|_Not valid after: 2013-09-10 17:54:34
|_http-title: Directory listing for /
445/tcp open microsoft-ds Dionaea honeypot smbd
1433/tcp open ms-sql-s Dionaea honeypot MS-SQL server
Mas adelante mostraré mas resultados de este pedazo de softwar
;)  Fuente: flu-project

Web alternativa del senado Low-Cost

En tiempos de crisis, el coste de los 500.000 € que había costado la web del Senado, y que encima se comía un HTML Injection hizo pupa en la sociedad. En esta ocasión, además, llovía sobre mojado porque ya en el año 2007 pasó algo similar con la web del Congreso y volvió a pasar en el año 2010 con la famosa web de la Presidencia Europea de España y el HTML Injection de Mr. Bean.
Figura 1: HTML Injection en la web de la presidencia europea de España
Tanto fue así, que en la radio le dedicamos un buen rato a hablar de este tema, porque a la gente le tenía muy molesto por Twitter. Uno de los oyentes se ha molestado en dedicar unos días a hacer una copia de la web del Senado utilizando 0 Euros, solo su trabajo, para tener una replica.
Figura 2: Web del Senado hecha con 0 euros
Ha documentado todo el trabajo qué ha realizado en la web, y la ha subido a varios sitios online, para que puedas verla.  Dicen que en el punto medio está la virtud, y no sé si gastarse 500.000 € en una web como la del Senado era lo más apropiado en estos momentos. Vosotros diréis.
Saludos Malignos!
 
Fuente: Chema Alonso

Dile cositas bonitas al oído a los chicos de Apple

Desde hace unas semanas tengo un iPhone 5 que ha pasado a engrosar mi colección de smartphones y tablets que uso para aprender cositas. Una de las primeras cosas que quisimos probar en iPhone 5, además de cómo trabaja Oxigen Forensics con iOS 6, fueron las funciones nuevas que vienen con iOS6 y no están disponibles en los iPhone 4 e iPhone 4S, así que había que jugar mucho con Siri.
Siri es el asistente personal de iOS que te ayuda, entre otras cosas, a que otros usen tu dispositivo aunque lo tengas bloqueado, también ha obligado a Apple a parchear iOS 6 porque permitía acceder a las contraseñas de Passbook aún con el dispositivo bloqueado, o a tener que reprogramar la propia "inteligencia" de Siri porque les salió respondón y cuando preguntaban qué smartphone era el mejor contestaba que un Nokia Lumia con Windows Phone.

Figura 1: Enviando correos electrónicos con Siri en un iPhone bloqueado
Además de esos "detalles" insignificantes en seguridad, Siri tuvo que ser bloqueado en muchas redes de empresas, porque tiene la peculiaridad de que el reconocimiento de voz no se hace en el terminal sino en los servidores de Apple. Es decir, cuando tu hablas a Siri lo que estás haciendo es generar un fichero de audio que es enviado a los servidores de Apple que devuelven su interpretación en modo texto.
A muchas personas de empresas preocupadas por la seguridad - de esas que son capaces de poner los smartphones en cajas faraday en las reuniones - eso de que Siri se active solo cuando va el terminal en el bolsillo no les gusta nada, y por supuesto, que se almacenen todos los mensajes de voz, a las empresas que venden sistemas de seguridad biométrica basados en voz no les parece nada inteligente que se vayan dejando grabaciones de voz en servidores ajenos.
El caso es que en el teclado de iOS6 también está escondido Siri, y yo pensaba que no era así. Entre las teclas aparece un botón con un micrófono que reconoce tu voz para escribir el mensaje sin teclearlo, y la verdad es que funciona muy bien. El problema es que, aunque no lo creas, es Siri, y todo lo que estés escribiendo en un mensaje de correo está siendo grabado en los servidores de Apple. Para probadlo, activa el modo avión de tu iOS6 y verás como el micrófono desaparece.
Figura 2: Siri escondido en el teclado desconectado porque no hay Internet

Es decir, si Apple ya se llevó los SMS con el iMessage, y tiene asociado tu Apple ID con tu UDID del terminal - ese que se puede utilizar para hacer un ataque dirigido con un troyano para iOS - y vas tú y ahora le lees los correos electrónicos confidenciales que vas a escribir, olvídate de PGP, S/MIME o lo que quieras.
Como se puede ver en las imágenes, el teclado con Siri sale en todas las aplicaciones, como las notas, el despertador, las búsquedas en Internet, e incluso las que hagas en tu teléfono, así que utiliza sólo este sistema para decirle cosas al oído y no para escribir correos confidenciales o para pedir "servicios especiales" en países donde estén prohibidos }:O
Figura 3: Escribiendo una nota con voz para dejar un mensaje bonito en Apple
Para eso, que Apple siga teniendo que reconstruir los mensajes de Carrier IQ, el "troyano" ese que se instala en los smartphones para reconstruir lo que haces en paso a paso en cada equipo y hacer un debugging "como debe hacerse". Por cierto, un amigo me dijo hace poco que si en el anuncio de Apple pone que tu dedo pulgar va de aquí a aquí, porque el teclado en horizontal no aprovecha toda la pantalla en iPhone 5... y tiene toda la razón como podéis ver en la Figura 3.
Saludos Malignos!
 
Fuente: Chema Alonso

Vulnerabilidad en Instagram para iOS

Se ha descubierto una vulnerabilidad en Instagram que podría permitir a un atacante el acceso no autorizado al contenido y descargar o eliminar las fotos sin el consentimiento de la víctima.
Instagram es una aplicación gratuita, disponible para iOS y Android, que permite aplicar una serie de filtros, efectos y marcos a las fotografías tomadas y enviarlas a diferentes redes sociales para compartirlas.
Instagram realiza las comunicaciones a través de conexiones HTTP y HTTPS, siendo el método de autenticación una cookie estándar que se envía sin cifrar al servidor cuando el usuario inicia la aplicación Instagram. Es posible interceptar esta cookie (mediante un ataque Man-in-the-Middle, por ejemplo, por parte de un usuario en la misma red local) para acceder al servidor suplantando al usuario legitimo y poder realizar acciones sobre el contenido, tales como descargarlo o eliminarlo.
Este fallo de seguridad ha sido descubierto por Carlos Reventlov quien, tras ponerse en contacto con el desarrollador el 10 de noviembre  y obtener una respuesta automática, ha publicado la información acerca de la vulnerabilidad junto a una prueba de concepto como demostración, capaz de obtener la cookie y eliminar las fotografías del usuario.
Se ha comprobado que la última versión de Instagram 3.1.2 para iOS es vulnerable, aunque también podrían estar afectadas otras versiones y plataformas. Por el momento no existe solución oficial.
Más información:
Instagram 3.1.2 For iOS, Plaintext Media Information Disclosure Security Issue
Juan José Ruiz

Fuente: Hispasec

Descubierto un nuevo rootkit para servidores Linux

Se ha descubierto un rootkit interesante para servidores Linux, que inyecta código en todas las páginas servidas por el servidor Proxy nginx, muy usado como "puerta" hacia Apache en servidores *nix en sitios de tráfico intenso.
Un usuario envió un correo a la lista de seguridad Full Disclosure afirmando que había descubierto sus sistemas Debian infectados por lo que parecía un "rootkit trabajando junto con nginx". Se trataba de un administrador que se había percatado de que los visitantes de su web estaban siendo redireccionados a sitios infectados. Varios tipos de petición hacia ese servidor web, devolvía un iframe inyectado en la página, que llevaba a un punto donde se intentaba infectar a los usuarios de Windows. El administrador descubrió también procesos ocultos (típico comportamiento de un rootkit) y los módulos del kernel responsables del problema, que adjuntó al correo de alerta para que pudiera ser estudiado.
Parece que el sistema de este administrador ha sido efectivamente comprometido (a nivel de root, al tratarse de un módulo para el kernel) para incluir un rootkit en él, y modificar el comportamiento de su servidor web. Así, todos los visitantes podían ser redirigidos a páginas de malware.
Nos encontramos pues ante una pieza más del puzle. Un nuevo método de distribución que implica una pieza de software interesante que previamente se desconocía. Se ha dado en llamar Rootkit.Linux.Snakso, y por ahora su detección es mínima (6 de 43 motores).
El principal problema para este rootkit es que si bien puede pasar desapercibido en el sistema, es muy fácilmente detectable por su propio funcionamiento: cualquier visitante de la web puede comprobar que se añaden iframes hacia ciertas webs sospechosas.
Cómo funciona
Está diseñado para atacar sistemas Linux de 64 bits y se ha compilado para la versión 2.6.32-5 que utiliza Debian Squeeze. Intercepta las llamadas a ciertas funciones del kernel para poder cumplir su función y, además, acepta instrucciones de un sistema central. Puede que esté en desarrollo aún. El atacante ha sido muy descuidado, porque el binario todavía contiene toda la información de "debug", y no ha sido "strippeado" (eliminada esa información). También se intuye que no es muy profesional. Algo interesante es que llega a muy bajo nivel para inyectar los iframes, sustituyendo la función de sistema tcp_sendmsg, así que el troyano modifica directamente los paquetes TCP que salen del servidor. Para saber qué inyectar, se conecta a su controlador con protocolo propio, protegido por contraseña cifrada.
Las IPs públicas que aparecen en el módulo son:
91.123.100.207
149.20.20.133
149.20.4.69
64.189.125.254
Como curiosidad, en vez de comprobar que la página servida ofrece un 200 para "inyectarse" (un OK en código HTTP) está programado para no mostrarse solo cuando se da un 403, 304 o la cadena "not found on this server" (o sea, un 404). Esta lógica es un poco extraña y seguro ha acelerado el proceso de descubrimiento.
Conclusiones
Los rootkits o el malware en Linux no son nuevos. La novedad consiste en que se ha creado un rootkit nuevo para entornos Linux, cuando lo habitual es nutrirse de código ya hecho. Otro asunto extraño es el aroma a "novato" de este rootkit. No parece un ataque dirigido, sino algo que apuntaba a infectar más sistemas. Sin embargo no cuenta con ningún mecanismo de reproducción. El atacante ha debido o bien tener acceso como root a la máquina infectada o el administrador ha quedado infectado a través de algún método que desconocemos. Hasta aquí, todo misterios.
Eliminando estos aspectos, el encuadre del ataque no es nada nuevo: los atacantes se nutren de servidores en cualquier plataforma (páginas comprometidas habitualmente) para infectar Windows. El "objetivo" de la infección es habitualmente Windows, pero no es extraño que el "medio" sea cualquier otra plataforma para maximizar su difusión.
Es, en realidad, un paso más allá en el sistema de distribución de malware. Si bien hasta ahora habíamos sido testigos de páginas comprometidas donde se añadían enlaces maliciosos, no eran comunes ataques en los que todo el sistema del servidor web se viese comprometido hasta sus entrañas... y mucho menos a través de un rootkit para Linux.
Más información:
linux rootkit in combination with nginx
HTTP iframe Injecting Linux Rootkit

Sergio de los Santos
Twitter: @ssantosv
 
Fuente: Hispasec