30 junio 2012

Interfaz gráfica para SQLMap

SQLMap es una de las herramientas más completa y funcional para realizar ataques de tipo 'SQL Injection' que hay disponibles actualmente.

Además es una herramienta OpenSource que se actualiza con muchísima frecuencia y evoluciona a un ritmo de vértigo. 

El único y muy pequeño 'pero' que se le podía poner era la falta de una interfaz gráfica para la gente que prefiere no usar complejos comandos.

Parece que ya eso ha dejado de ser un handicap, dado que se ha publicado, por fin, una interfaz gráfica con una pinta estupenda.

El proyecto, llamado gui-for-sqlmap provee de la parte gráfica a SQLMap. 









Disponible tanto para Windows como para Linux

Leer más...

29 junio 2012

Últimamente la palabra 'ciberguerra' ha saltado a la palestra con más fuerza si cabe a raíz de Flame y su enorme repercusión mediática.

También han ayudado las supuestas revelaciones que vinculan Stuxnet, Duqu y Flame con Obama, EEUU e Israel.

Hasta ahora la mayoría de opiniones van en la línea de que esto es 'solo el principio' y que se espera un auge en este tipo de acontecimientos.

Personalmente opino lo contrario, si que creo que durante los próximos años (2-3 a lo sumo) se podrán ver mas cosas similares, en realidad vestigios de proyectos lanzados anteriormente, pero creo que, pasada esa época, el concepto ciberguerra, tal y como lo estamos definiendo actualmente (troyanos sofisticados, exploits ad-hoc para windows ...) perderá su vigencia.

Y esta opinión la fundamento en que ahora estamos viviendo la novedad, el 'anda ! ¿pero esto se podía hacer ?''. Y claro ese efecto sorpresa, como decía Confucio, ha sido la clave de todo.

Pongamos como ejemplo el desgraciado incidente con las torres gemelas, nadie podía pensar ni concebir un atentado de ese tipo, por lo salvaje y por la ejecución. A raíz de ese incidente, se aprendieron unas valiosas lecciones que llevaron a cubrir todos los vectores que hicieron posible ese ataque.

Creo que el asunto de la ciberguerra va a ir en la misma línea. Probablemente Irán (aparentemente la víctima favorita) desarrollará su propio sistema operativo, probablemente basado en Linux o algún *BSD, que estará fuertemente 'hardenizado' y casi seguro con una serie de modificaciones a nivel kernel que no serán públicas.

Ignoro que puede llevar a un país como Irán a usar Windows en sistemas tan críticos como instalaciones nucleares, pero tengo bastante claro que de ese incidente habrán aprendido la lección y se acabó el usar plataformas tan -relativamente- fácilmente vulnerables como las que estaban usando. O al menos, tan 'famosas' y con tanto grado de exposición a posibles exploits.

Podéis opinar al respecto en la siguiente encuesta:

¿Crees que estamos al inicio de 'la ciberguerra' y veremos mas Stuxnets / Duqus / Flames?

Leer más...

27 junio 2012

Reversing malware tales: Safe debugging

Antes de empezar con el post, decir que si estás leyendo esto vía feeds RSS o por correo electrónico, el anterior post de esta saga: Reversing malware tales: Dropper Dropped ! por motivos largos de explicar, no salió por RSS o mail, así que os animo a que lo veáis ahora si os lo perdisteis.

Dicho lo cual, seguimos con la saga, esta vez hablaremos de tips útiles mientras estamos analizando malware.

Analizar malware no es como analizar un programa normal, lo que se tiene entre manos suele tener un fin bastante determinado: hacer el mal.

En el caso de los droppers, dentro de lo que cabe son 'inocuos' solo van a descargar un fichero y ejecutarlo, pero en la mayoría de casos el payload del 'bicho' suele contener instrucciones para ocultar procesos, capturar pulsaciones de teclado, modificar el registro / ficheros ...

Por lo tanto, hay que tener un escenario lo más controlado posible para analizar un fichero malicioso. 

Los análisis estáticos suelen tener poco peligro, pero en el momento en el que vía debugger ejecutas el proceso, por muchos breakpoints que hayas puesto o pienses que tienes controlado 'al bicho', en realidad hay muchas posibilidades de que algo se te escape, al menos a primera vista.

Evidentemente el entorno para analizar malware ha de ser una máquina virtual y hacer uso intensivo de los 'snapshots' para volver a posiciones controladas tras una ejecución. Aun así, andar con snapshots para todo, es bastante tedioso por el tiempo que cuesta en realizarse la operación.

Una alternativa para evitar muchos de esos tediosos 'rollback' es usar el debugger dentro de un entorno 'sandboxed' para que la ejecución del proceso debuggeado quede auto-contenida dentro de el y los posibles daños sean minimizados.

Para ello vamos a usar 'Sandboxie', del que hablamos tiempo atrás.

Una vez instalado, lanzar una instancia de Olly vía Sandboxie es muy fácil



Seleccionamos el 'sandbox' que deseamos emplear para la ejecución



Le decimos a Sandboxie que queremos ejecutar Ollydbg



Como se puede observar, el caption de olly ha sido modificado y aparece entre símbolos de # lo que significa que se encuentra virtualizado por Sandboxie.

Y a partir de aquí, todos los programas que carguemos para debuggear se ejecutarán dentro del sandbox y no podrán dañar el sistema.



Otro punto interesante es que, en la ruta C:\Sandbox\Administrador\DefaultBox\drive podemos ver los 'restos' que haya podido dejar el malware que estemos analizando en las diferentes unidades de disco, lo que puede resultar interesante para descubrir mas ficheros relacionados.

Usar Sandboxie + ollydbg no es la panacea, y evidentemente sigue siendo necesario hacer uso de snapshots, pero con este método nos podemos ahorrar un buen número de interminables momentos de espera mientras la máquina virtual vuelve a un snapshot anterior

Leer más...

26 junio 2012

España en el puesto 38 de los países más peligrosos de Internet

Al contrario de lo que muchas veces habíamos visto en otros reportes, España no está entre los países más peligrosos de Internet, y así lo muestra la  página web de CyberDefcon, Global Security Map, que tiene en consideración distintos tipos de ataques y el país que los origina, pintando y clasificándolos dinámicamente usando como referencia la base de datos de HostExploit.

Entre las categorías distingue entre Spam, Malware, Badware, Botnet, Phishing, Cybercrime hubs y eventos actuales, como son XSS, RCE, RFI, LFI, clickjacking, etc.

Lituania, Azerbaiyá y Letonia, se muestran en la lista como territorios comanche y en la cabeza de las zonas más seguras se encuentran Puerto Rico, Chipre y Finlandia como ganadora.

Es bastante divertido e incluso se puede aprender algo de geografía si vais probando a seleccionar los distintos ataques y viendo como cambian los colores. Aunque ya existen otros mapas de infecciones y nivel de riesgo, como el de Sophos, Panda,  ISC, McAfee, SymantecSecurelist o Atlas de Arbor y al final cada uno tiene unas métricas.



[+] Global Security Map: http://globalsecuritymap.com/#info
Leer más...

25 junio 2012

Videos de SbD@Rooted2012 #Rooted2012




Ya han sido publicados los videos de dos de las charlas que el equipo de Security By Default dimos en la última edición de RootedCon.

Las transparencias de ambas presentaciones fueron colgadas en Slideshare y ya las pusimos a vuestra disposición aquí, aquí y aquí.

Sin más preámbulos, os dejamos con los videos completos de dos de las charlas ya montadas. En concreto, son las que dimos Yago y yo, quedando aún por publicarse la que dio nuestro querido compañero José Antonio junto al gran profesional de Taddong, Raúl Siles.


Applied Cryptography Fails! por Yago Jesús



Welcome to your secure /home, $user! por Lorenzo Martínez


Si queréis disfrutar del resto de los videos de las charlas de RootedCon, podéis hacerlo en el siguiente enlace
Leer más...

24 junio 2012

Enlaces de la SECmana - 129


Leer más...

23 junio 2012

Los Numerati: Lo saben todo sobre tí - Stephen Baker


La verdad es que cuando mi buen amigo Álvaro Andrade y su encantadora pareja me regalaron este libro me imaginé que llevaría dentro una historia relacionada con una secta con extrañas habilidades. Lo que me encontré realmente en él, son varios casos en los que el autor describe a los Numerati, auténticos gurús de la estadística y que, en base a muy inteligentes algoritmos y recursos hardware con brutales capacidades de cómputo, son capaces de clasificar los hábitos de las personas, invadiendo, de forma velada, la privacidad de las mismas.

Fundamentalmente, se basa en la transformación de datos de diversa índole en números, de manera que sean aprovechables para otros fines. Ya lo decía Simeón, mi profesor de estadística en la Universidad, que lo importante de la informática es mecanizar la estadística así que "menos mariconeo de pantalla" que sólo es "trabajo de secretaria".

El libro ofrece casos como el diseño de un supermercado y cómo se puede "forzar" o "encaminar" a un usuario a comprar lo que ellos quieran. ¿Cómo? Muy fácil, mediante la identificación y clasificación de los individuos.

- Pero, si yo no les doy mis datos a los del supermercado.
- Claro que se los das. ¿Te acuerdas de la tarjeta de fidelidad que pasas cada vez que compras?

Cada vez que presentamos la tarjeta de fidelidad vendemos nuestros hábitos de compra a cambio de un descuento de 1 euro o de unos vales para yogures en la siguiente compra. A los centros comerciales les viene de perlas saber cuántas personas varones de entre 25 y 30 años compran, por ejemplo cervezas, refrescos, pizzas, salchichas, hamburguesas… Podrá correlar con la información de cuando rellenó la tarjeta, que el individuo es soltero y que es amante de la comida basura. Si sólo se observan verduras y frutas en su dieta o alimentos sin gluten, se podría intuir que se trata de un vegetariano o de un celíaco. En este caso parece obvio, pero partiendo de datos más complejos y una buena metodología de análisis, habrá ejemplos mucho más elaborados, que seguro que ayudarán a enviar campañas de publicidad dirigidas (como si de un ataque APT se tratara) para hacernos creer que nos llevamos un chollazo de oferta, cuando realmente se aprovecha una vulnerabilidad del instinto humano: el consumismo.

Y tú ¿aún compras lo que necesitas o lo que subliminalmente te venden?

En el mundo online, se lleva viendo esto durante años. Adsense de Google, anuncios en Facebook, etc, etc,… basados en tus búsquedas anteriores, cookies, datos de navegación, incluso se ha dado el caso de líneas aéreas que suben el precio de los billetes precisamente en base a estos datos de su navegación previa en busca de tickets.

Estaba leyéndome este libro cuando llegó a mí un enlace, no sé si a través de Twitter o vía RSS en el que se dice que precisamente Twitter compra la empresa de análisis estadísticos hotspots.io. ¿La finalidad? Pues supongo que es la misma que teníamos Yago y yo, hace años, cuando pensamos en desarrollar un análisis de marcas a través de Internet, de manera que se pudiese obtener métricas para conocer el éxito o fracaso de campañas electorales o de publicidad, por ejemplo, mediante las APIs de Google y Yahoo (por aquellos entonces la ballena de Twitter era aún una sardina).

Por otro lado, el libro habla también de ejemplos en los que el convertir los datos de las personas en números, en tendencias, en modelos estadísticos de comportamiento, sirven (o pueden servir) para buenos fines, como la prevención de determinadas enfermedades como el parkinson, monitorización de constantes vitales de ancianos o personas enfermas en sus casas, un mayor número de datos para ayudar a un médico a evaluar un diagnóstico, etc… no siempre siendo necesario introducir nano-robots dentro del torrente sanguíneo de los ancianos o enfermos. Sin embargo, en este punto, surge la palabra: seguridad. ¿Qué medidas habrá que tomar para evitar alteraciones o compromisos de los datos recopilados por diferentes elementos? ¿Cómo se puede garantizar la privacidad de los datos médicos (que, en España, la LOPD clasifica como de nivel alto) de los pacientes?

Otros buenos ejemplos que aparecen en el libro podría ser la anticipación de cuerpos y fuerzas de seguridad del estado para bloquear un ataque terrorista inminente, medios que permitan monitorizar el paradero de según qué individuos clasificados como "de alto peligro" según pasan por diferentes lugares, identificados mediante reconocimiento facial, muy al estilo de la serie "Person Of Interest" que ya comentamos en SbD tiempo atrás.

En resumen, el libro es entretenido y te hace pensar. Si esperáis una narración en formato novela, con personajes que tienen un principio, una historia y un final,... no es lo que encontraréis en esta obra.
Leer más...

22 junio 2012

Cocoa Packet Analyzer 1.11

Cocoa Packet Analyzer es un sniffer nativo para Mac OS X (>10.5) que desde noviembre de 2011 se encuentra en su versión 1.11.  Entre sus características permite leer y escribir ficheros en PCAP, lo que realmente no es ninguna novedad, y algunos protocolos básicos de TCP/IP.

Adicionalmente es mejorado mediante plugins, de los que hay disponibles tan solo dos: SIP y IAX2

Al arrancarlo permite leer de un fichero un captura o crear una nueva, indicando el interfaz por el que realizar la escucha.


Cuando termina (y no en tiempo real), muestra los resultados en una ventana similar a Wireshark. Aunque como se puede ver en la siguiente captura de pantalla, no permite seguir el flujo de una conexión, ni entiende protocolos de capa 7.


Pese a que visualmente se agradece que esté desarrollado nativamente, las funcionalidades son extremadamente limitadas. Aun está demasiado verde como para plantearse sustituir otros sniffers mucho más avanzados como Wireshark o incluso el propio tcpdump.

Esperemos que continúen ampliandolo y ya veremos dentro de un tiempo si está algo más maduro.

[+] http://www.tastycocoabytes.com/cpa/
Leer más...

21 junio 2012

MD5, Certificados y viceversa

Poco a poco se van conociendo más detalles sobre el ataque criptográfico que está tras el certificado 'rogue' que emplea Flame.

Sergio de los Santos, lo ha bordado en sus explicaciones sobre el affaire aquí y aquí. Poco más hay que añadir a sus explicaciones.

No obstante, si que merece la pena repasar un poco la teoría de este tipo de ataques, los diferentes tipos y sus vectores.

Desde el famoso ataque del 2008 a MD5 hasta hoy, el término 'colisiones' se ha empleado concienzudamente para definir un tipo de ataque. Erróneamente mucha gente asocia este ataque como el único del que puede adolecer un algoritmo de 'hashing', e incluso confunde este ataque con otros.

De entrada, vamos a poner en liza los actores de esta película:

Dato1 --> HashDato1

Dato2 --> HashDato2

Donde 'Dato' puede ser cualquier cosa que se pueda resumir en un hash, puede ser un fichero o puede ser los campos de un certificado digital.

Ataques a algoritmos de hash

De entrada, hay que comentar que todos los algoritmos de hashing son vulnerables a este tipo de ataques. Evidentemente en su resistencia a este tipo de ataques estriba lo mas o menos aptos. Lo que define su resistencia es lo 'computacionalmente factible' que resulta ejecutarlos.

En el momento que un dato de tamaño arbitrario X ha de ser resumido en un hash de longitud fija, se abre la puerta a que existan diferentes tipos de datos que resulten en una mismo hash.

Ataque de tipo 'Primera preimagen' : Tomando como referencia los actores mencionados anteriormente, un ataque de 'primera preimagen' es aquel en el que, conociendo HashDato1, un atacante es capaz de generar un mensaje (Dato2) capaz de generar el mismo hash.

Ataque de tipo 'Segunda preimagen': En este caso el dato a tener en cuenta es 'Dato1' y el ataque estriba en la capacidad de generar un Dato2 que compute en un hash idéntico al de Dato1

Ataque de tipo Colisiones: En este tipo de ataques, el atacante tiene el control sobre Dato1 y Dato2 y mediante la manipulación de ambos, es capaz de generar un Dato1 y Dato2 diferentes entre si, pero que computen en un mismo resultado ante la función de hash.

Los ataques de tipo 'Preimagen' son los menos frecuentes y mas costosos a nivel computacional, y además los más dañinos. El poder generar un Dato2 con su correspondiente HashDato2 idéntico a HashDato1 a partir de simplemente un Dato1 o HashDato1, sería realmente dañino y motivo para anular cualquier tipo de algoritmo de hashing.

Los ataques de tipo 'colisiones', como se ha podido ver en el affaire Flame y en el incidente del 2008, si son factibles pero requieren que el atacante mantenga el control sobre Dato1 y Dato2. 

Y aquí está la clave de todo el asunto. Tanto en el caso Flame como en el anterior, el atacante tenía el control de ambos datos. ¿Cómo? Muy fácil, a la hora de pedir un certificado digital, la CA de turno no genera un certificado y te lo da, tu tienes que enviar lo que se conoce como CSR (Certificate Signing Request), es decir una petición de certificado con unos datos que controlas tu.

Y aquí está la gracia del asunto, empleando sofisticados ataques, pudieron generar un CSR 'ninja' que, una vez procesado por la CA, generaba un certificado perfectamente válido pero que, oh sorpresa, los campos podían ser modificados por los de otro certificado que generase el mismo hash que los campos entregados a la CA en el CSR

Por eso ha sido posible vulnerar ambas CAs y subvertidas para que generen certificados fraudulentos, porque empleaban un algoritmo de hash deficiente y porque los atacantes manipularon de forma realmente ingeniosa las peticiones de certificado para conseguir llevar a cabo un ataque de tipo 'colisiones'
Leer más...

19 junio 2012

Charly y la política de contraseñas de chocolate

Hola a todos! En este post voy a presentar un par de tools, que seguramente no sean las mejores ni más eficientes, pero si que son funcionales y bastante útiles a la hora de enfrentarnos a ciertas situaciones durante una auditoria. Por un lado presentaremos mutator, que como su propio nombre indica realiza permutaciones sobre una lista de palabras y genera otra lista basándose en ciertos patrones sobre los que en más ocasiones de las que nos creemos nos basamos para poner una contraseña, como puede ser transformaciones 1337, añadir guiones bajos, años, etc. En cuanto a la otra herramienta llamada BasicAuthBF se trata de un programa muy simple que hace fuerza bruta en servicios de tipo HTTP Basic Authentication y es multihilo

Cuando estamos realizando algún tipo de auditoría o test de intrusión normalmente los servicios más vulnerables son los que están desactualizados y por donde es más fácil tomar una maquina, por lo que un pensamiento bastante generalizado hace pensar que si estamos actualizados estamos seguros, y esto es bastante incorrecto sobre todo si carecemos de una política seria de contraseñas o nos la pasamos por el arco del triunfo. Por otro lado también es bastante común ahora con la moda de las cámaras de video vigilancia y los smartphones, ipads etc que muchas empresas tengan estos servicios abiertos en una ip pública y podamos ver los logins si miramos en los puertos adecuados.

Con lo contado hasta ahora podemos entrar un poco a describir donde en que tipo de servicios nos encontramos este tipo de autenticación:
  • Routers Cisco: Si conseguimos un login de nivel 15 (poderes de supervaca) nos podemos hacer con el control total de la red con lo que ello supone).
  • Cámaras: Como comentamos más arriba cada vez es más frecuente encontrarse este tipo de servicios en muchas ips en internet, en el mejor de los casos el firmware es seguro y no tiene ningún fallo, cosa poco habitual todo sea dicho de paso, y poseen muchas veces una login del tipo que nos interesa.
  • Logins de webs protegidos por un HTTP Basic Auth. es muy común también sobre todo en compañías que tienen en su sitio web un CMS wordpress o joomla tener protegido el panel de administración con un panel de este tipo.
  • Tomcats: Sin duda mi preferido, es muy común durante una auditoría encontrarse un panel de administración expuesto hacia internet o mucho más normal encontrarselo en una auditoria interna en la que este tipo de servidores tienen dos patas de red, una hacía la parte de usuarios de la red y otra hacia la zona de red protegida, donde se encuentran otro tipo de maquinas más jugosas. En la red interna es donde es más común encontrarse un password inseguras, repetidas, por defecto, etc. Vamos una autentica fiesta.
De técnicas de fuerza bruta se ha hablado mucho y además es una de las especialidades de Alex, uno de los autores de este blog, por lo que es innecesario que entremos en ese campo. Mi resumen rápido es que hacer bruteforce de un servicio y sacar la contraseña después de 5millones de peticiones no tiene gracia ni se puede considerar vulnerabilidad de ningún tipo, la gracia viene cuando aplicamos algún tipo de técnica, ya sea usando diccionarios o como comentaremos aquí usando listas de palabras que se relacionan con nuestro objetivo que permutaremos para sacar una lista de posibles password.



Pasamos a la 'chicha' del post, la parte practica:

Instalamos mutator:
  • git clone https://bitbucket.org/alone/mutator.git
  • make
Instalamos BasicAuthBF:
  • git clone https://bitbucket.org/dan1t0/basicauthbf.git
  • make
Una vez instaladas las tools realizamos un PoC sobre una empresa llamada por ejemplo Banquia y un tomcat con el panel de administración disponible:

- Generamos un diccionario con un par de palabras por ejemplo (banquia, estafa, bankia) y las permutamos con mutator despues de añadirlas al archivo palabras.txt
- Ejecutamos mutator: ./mutator -o dic.txt palabras.txt (hemos generado 3600 combinaciones). Si quereis ver la lista de palabra generadas aquí os las dejo.

 

- Ahora crearemos una lista de usuarios, como no vamos a complicarnos excesivamente usaremos solo tres, por ejemplo (chorizo, bankiero, rodrigo) a este archivo le llamaremos user.txt

- Posteriormente procedemos a bruteforcear el servicio con BasicAuthBF: ./BasicAuthBF -i 127.0.0.1 -p 8080 -z /manager/html -U user.txt -P dic.txt -t 10


- Como vemos el usuario y la pass han sido localizadas.

Como muchos sabréis existen otras herramientas que hacen estas tareas como hydra y john the ripper; entre muchas otras, pero en el caso de mutator es mucho mas sencillo generar un diccionario que entender el sintaxis klingon que usa john. En el caso de BasicAuthBF es un programa muy sencillo en el que es muy fácil de entender lo que pasa en cada momento y como trabaja contra el servicio a atacar y por supuesto nos dejamos la razón más importante: estas tools las hemos hecho nosotros y siempre es más divertido y didáctico romper algo sabiendo que la herramienta que has usado es tuya aun sabiendo que hay competencia suficiente (feel like a hacker).

- Mutator by @AloneInTheShell
- BasicAuthBF by @dan1t0

---------------------------------------------
Contribución por Dani Martinez
Leer más...

18 junio 2012

Evidencias digitales con WebSellada 1.0


Después de lanzar 'Mail Sellado', nuestra herramienta para certificar el envío de un correo electrónico, el siguiente paso del proyecto debía ser el proporcionar una herramienta que permita obtener evidencias digitales empleando firma digital y sellos de tiempo.

La web, por su naturaleza, es esencialmente un entorno volátil: lo que veas hoy, no necesariamente va a estar mañana y eso, para ciertas cosas, supone un enorme problema.

Supongamos varios casos reales: Alguien, empleando Twitter, te amenaza o se pone a hacer apología del maltrato animal o (ponga usted aquí cualquier cosa punible) y tu, decides emprender algún tipo de acción legal contra esa persona. Es obvio que un Tweet es fácilmente borrable y eso, es 'la prueba de cargo'

Lo que permite WebSellada es solicitar que un tercero ajeno a ti (en este caso, SbD) navegue a la URL que tu digas (en este caso el tweet en cuestión), haga una copia de como está en ese momento la URL, le aplique una firma digital y adicionalmente le añada un sello de tiempo empleando una autoridad de sellado reconocida oficialmente.

Luego, te enviamos un correo electrónico que contiene un PDF con un screenshot de la web, la firma digital a ese PDF y un sello de tiempo sobre la firma digital.

De esa forma, tu puedes tener un elemento verificable de que eso estaba así en un determinado momento temporal (definido en el sello de tiempo).

¿Más aplicaciones? A mi me ha pasado eso de ver una oferta en una web, la típica oferta que dices ¡¡ no puede ser !! y cuando te decides a ir por ella ... resulta que no era exactamente así, que se trataba de 'un error' y claro ya no está en la web.

También sirve para tweets bochornosos

En definitiva, existen muchas aplicaciones para esta herramienta.

¿Cómo se usa WebSellada?

Es muy fácil, simplemente debes enviar un correo electrónico a websellada@securitybydefault.com y en el subject poner la URL de la que quieres obtener la evidencia. Nada más.



Y cuando se procese tu petición, recibirás un correo electrónico con tres ficheros: Uno en formato PDF con un screenshot de la web, otro con extensión .asc con nuestra firma digital de ese pdf, y finalmente otro con extensión .tsr que es el sello de tiempo.


Con esos ficheros puedes, empleando gpg y openssl, verificar tanto la firma digital como el sello de tiempo.

Primero descargamos la clave pública de Web Sellada:

$ wget www.security-projects.com/websellada.key

Luego el certificado de la CA raiz de accv:

$ wget http://www.accv.es/fileadmin/Archivos/certificados/rootca.crt

Importamos la clave pública:

$ gpg --import websellada.key

Verificamos la firma digital sobre el pdf:

$ gpg --verify 2390495814521.39.pdf.asc 2390495814521.39.pdf

Y finalmente verificamos el sello de tiempo:

$ openssl ts -verify -data 2390495814521.39.pdf.asc -in 2390495814521.39.tsr -CAfile rootca.crt

El servicio está en fase 'ultra-beta', probablemente de errores, no procese bien todas las URLs o tenga demoras de tiempo en las respuestas.

Si encontráis fallos, podéis contactar conmigo en yjesus@security-projects.com donde, en la medida de lo posible, intentaré solucionarlos

Leer más...

17 junio 2012

Enlaces de la SECmana - 128

Leer más...

16 junio 2012


Después de haber sido ponente en RootedCon en Madrid (podéis ver aquí el video de la charla) y ACK Security Conference en Colombia, el próximo destino parece que va a ser Ecuador. El evento en concreto, titulado "I Seminario Internacional en Seguridad de la Información e Informática Forense" está organizado y co-patrocinado por la Universidad Católica de Cuenca.

De hecho, cuando recibí un correo en el que se me ofrecía mi participación para dar una charla en Cuenca dije,... "Bueno, esta vez me queda cerca"... hasta que leí "Cuenca - Ecuador".  

El evento tiene bastante buena pinta. Contará con ponentes internacionales, entre los que volveré a ver a mi buen amigo Álvaro Andrade de Bolivia, o Roberto Martínez de México. Además, estoy seguro que conoceré y haré buenas migas con otros excelentes conferencistas de seguridad de habla hispana, del otro lado del charco, con muy buenas referencias, como los argentinos Gustavo Presman o Miguel Sumer (que esperemos que se acuerden de traer un arsenal de tarros de dulce de leche, para quedar igual de bien que sus compatriotas Leo Pigner o Matías Katz  ;D).

Por mi parte, le daré un respiro a Skynet esta vez (al que ya adelanto que le estoy añadiendo nuevas funcionalidades) y daré una charla sobre uno de los temas en los que más especializado estoy: "Buenas prácticas de seguridad en entornos corporativos". Sí, los que estuvisteis en el ACK de Colombia pudisteis comprobar que soy capaz de hablar durante 8 horas (y más si me dejáis) sobre ese mismo tema, así que en este caso intentaré recalcar lo más importante en menos de una hora, y espero, por qué no, sacar a la luz muchos de los errores que cometen las organizaciones a la hora de asegurar todas y cada una de las unidades en las que pueden surgir vulnerabilidades, desde el perímetro de red, hasta los hábitos de los propios usuarios.

Y esto, ¿cuándo pasará? 
El evento está fijado para la última semana de Junio (28 y 29), por lo que estaré encantado de poder conocer y saludar a lectores de Security By Default ecuatorianos que asistan al evento. Según dice el tríptico que pongo bajo estas líneas, la "inversión" para la asistencia no parece muy alta, y hay descuentos especiales para estudiantes



No podría ir a Ecuador sin perder la oportunidad de dar un fuerte abrazo a otro gran profesional que conocí en el ACK Colombia, el nativo ecuatoriano, Roberto Olaya

Lo dicho,... que voy a ir preparando el pasaporte, la maleta y mi cuerpo serrano para un viaje un millón de horas y nosecuantos aviones, porque.... nos vemos muy prontito en Ecuador!!!
Leer más...

14 junio 2012

Vuestros "ETHERNET EXPOSED" - XII


Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En esta ocasión, contamos con 3 nuevas contribuciones que nos han enviado Sergio, Spilock y Kilian.

Comenzamos con el ETHERNET EXPOSED que nos ha enviado Sergio:

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



"Aqui os hago mi pequeña contribución para "Ethernet Exposed". Es de unos cacharros para poner videos publicitarios en centros comerciales, etc. Creo que se llama iwall o algo asi.





Las fotos son de la entrada a un centro comercial de Barcelona pero los he visto en un monton de sitios mas en Barcelona, Madrid, etc


Como veis parece que funciona con Windows y creo que simplemente lo que hace es ir reproduciendo los videos de una "carpeta" :-)"


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


La toma de red se encuentra justo detrás de la pantalla....






El siguiente ETHERNET EXPOSED nos lo envía Spilock:


"En la policía nacional de una ciudad del norte, al lado de la maquina del DNI-E... que cosas ... xD
saludos amigos"


La verdad que para estos ETHERNET EXPOSED, podríamos dedicar una sección completa, no es el primero que recibimos en este tipo de localizaciones. Si bien es un lugar en el que resulta dificil "jugar" con las tomas, no deja de ser curioso.

Por último, Kilian nos cuenta lo siguiente:

"Os envio un ethernet exposed de las salas de espera de hacienda, tambien se ve el antiguo conector BNC"


Que mejor espera, que tener un minipwner y poder sacarlo a pasear cuando sabes que alguna gestión va para largo...

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!
---------------


Leer más...

13 junio 2012

FACUA: Papanatas en acción

Para el que no lo sepa, FACUA es una asociación de consumidores cuyo 'leitmotiv' es la defensa del ciudadano ante abusos y mala praxis de empresas e instituciones.

Muy loable, sin duda. El problema es cuando vas a poner la típica reclamación 'ruidosa' (orientada a salir en TV, prensa, Menéame y cia) y lo haces mal.

Lo haces mal porque pecas de algo que, por desgracia, sucede con demasiada frecuencia: Actúas como un papanatas

En el caso de FACUA, por lo visto, lanzaron una denuncia a la AGPD, contra WhatsApp (sí, nuestro querido WhatsApp) motivada en el hecho de que WhatsApp no implementa cifrado de datos en las comunicaciones. Y claro, eso supone un riesgo para el consumidor.

Hasta aquí todo bien, el problema es que FACUA ha empleado como 'prueba de cargo' la investigación que encontraron en un blog Holandés.

Si vemos el extracto de la resolución de la AGPD:


Vemos que FACUA motiva su reclamación en 'un blog Holandés que publicó un post llamado Whatsapp sends contact info and messages in plain text'. Si tiramos de google, encontramos el post aquí fechado el 17 de Mayo del 2011.

¿Problema? que esa investigación ya se había realizado y publicado en SbD en MARZO.

Y aunque en el momento que se lanzó esa reclamación, aun no se habían publicado la mayoría de los posts más 'calientes' sobre Whatsapp, los problemas de WhatsApp no se limitan solo al tema del cifrado de los datos en tránsito, es que tiene problemas de todo tipo.

Desde graves problemas de privacidad, hasta fallos en la seguridad del mecanismo de registro, más fallos de privacidad e incluso hemos publicado herramientas [1] y [2] para mostrar esos fallos.

Como colofón, decir que a AGPD no ha admitido la reclamación, podéis ver el dictamen aquí

Es muy triste encontrarse con estos casos de 'papanatismo' patrio, yo entiendo que FACUA, antes de hacer esta reclamación, habrá investigado sobre WhatsApp y me niego a creer que, si han sido mínimamente rigurosos, no hayan llegado hasta aquí, pero supongo que entre un enlace 'de fuera' y otro patrio, un buen papanatas estima que tiene mas empaque 'lo otro'

Evidentemente, si alguien de FACUA se hubiese puesto en contacto con nosotros, hubiéramos estado encantados de colaborar desinteresadamente. De hecho, si alguna reclamación contra WhatsApp tuvo realmente sentido, fue a raíz de todo lo que vino posteriormente

Ya puestos, recomiendo a FACUA encarecidamente que investigue -por ejemplo- sobre el market de Android, por lo visto dicen que no es muy seguro y eso si, no usen esta información o esta otra (aunque sea anterior), puede que pierda tirón :)

Prometo que continuaremos con el PEP (Programa Erradicación Papanatas)


Leer más...

12 junio 2012

Vulnerabilidad grave en MySQL/MariaDB - CVE-2012-2122

No es el día de los Santos Inocentes, ni de aquí (28 de Diciembre) ni internacional (April's Fool). El sábado 9 de Junio  Sergei Golubchik, coordinador de seguridad de MariaDB publicaba un post en la lista OSS-SEC sobre una grave vulnerabilidad que afectaba a diferentes versiones de MySQL y MariaDB.

Se evidencia la posibilidad de autenticarse como usuario con máximos privilegios (root) únicamente realizando conexiones simultáneas, con CUALQUIER contraseña introducida como parámetro y contra un servidor vulnerable. Al cabo de un número indeterminado de intentos fallidos, el servidor aceptará la conexión y se realizará la autenticación de forma satisfactoria. Sin más. Sin shellcodes raras, sin casuísticas extrañas: únicamente tenemos que tener delante un servidor vulnerable, que cumpla con las siguientes versiones:

  • Son vulnerables todas las versiones de MariaDB y MySQL hasta la 5.1.61, 5.2.11, 5.3.5 y 5.5.22
  • NO SON vulnerables las versiones de MySQL 5.1.63, 5.5.24 y 5.6.6
  • NO SON vulnerables las versiones de MariaDB 5.1.62, 5.2.12, 5.3.6 y 5.5.23
Con la siguiente línea en shell script, teniendo instalada una base de datos vulnerable en el sistema local, y contando con el cliente 'mysql', se podría realizar una autenticación como usuario root sin conocer la contraseña:

for i in `seq 1 1000`; do mysql -u root --password=blablabla -h 127.0.0.1 2>/dev/null; done

Básicamente, se ejecutará la sentencia de autenticación mediante cliente por consola (comando mysql) como usuario root (-u root) y cualquier contraseña (--password=blablabla) contra el servidor vulnerable  presente en el mismo sistema donde se ejecuta este script (-h 127.0.0.1), sin mostrar ningún mensaje de error por pantalla (2>/dev/null).

Vamos a ver el ejemplo real. Las siguientes pruebas se han realizado sobre una Fedora Core 16, con MySQL versión 5.5.21:


En primer lugar, y para este ejemplo, cambiaremos la contraseña original de MySQL para el usuario root, que antes la teníamos establecida a 'password', para que ahora sea 'SuperPassWordDeLaMuerte':


Seguidamente, salimos de la sesión de root, y nos quedamos como usuario sin privilegios, y ejecutamos la secuencia anterior, que realizará conexiones como usuario root y cualquier contraseña, programando un total de 1000 intentos. A continuación se ejecutará la consola de mysql satisfactoriamente:



Comprobamos el usuario con el que estamos autenticados mediante la sentencia select current_user(), obteniendo como resultado 'root@localhost'


Obviamente, este "ataque" ya se encuentra integrado como exploit de Metasploit Framework, permitiendo además el volcado de hashes de todos los usuarios, todo ello con el módulo mysql_authbypass_hashdump:



Enhorabuena desde SecurityByDefault a los descubridores de este bug, verlo para creerlo...De momento, ¡una de las vulnerabilidades descubiertas favoritas para este año 2012!



Leer más...

11 junio 2012

X-10: Comunicaciones a través de la red eléctrica (2/2)


Como prometí en la primera entrada sobre X-10, quería documentar mi experiencia de haber estado trasteando con  este tipo de dispositivos.

Hay dos formas de "X-10-izar" una casa. Mediante dispositivos (interruptores,  casquillos de bombilla, etc,…) que lleven incorporada la electrónica X-10 necesaria; o, si no queremos cambiar los interruptores, se pueden intercalar módulos o micromódulos X-10, que activen o desactiven lo que queramos (un motor, una bombilla, una sirena,...).

¿Cómo se envían los códigos X-10 necesarios?
Los interfaces que comentamos en la primera entrada CM-11, CM-15 o CM-17, emitiremos las señales necesarias para que funcionen los dispositivos actuadores.

Como dijimos, un dispositivo X-10 se identifica por un código de casa (de la A a la P) y un código de dispositivo (del 1 al 16). En perl (y supongo que en otros lenguajes de alto nivel como Python), hay diferentes módulos como ControlX10::CM11 o ControlX10::CM17. Recordad que CM11 funciona por puerto serie y CM15 y CM17 van por USB. En el caso de CM11, podemos "hablarle" al puerto serie directamente y enviar los comandos necesarios, y en el caso de los que funcionan por USB, será necesario utilizar un driver para poder tener un dispositivo en /dev (en Linux).

Estos módulos Perl permiten abstraerte del mundo del bit para, directamente, decirle al módulo C4 que se encienda o que se apague. Sin embargo, en el caso de CM15 (que es el emisor que compré), no encontré nada útil en CPAN.
Así que dije: bueno, pues do-it-yourself… Lo primero era hacer que el sistema operativo detectara el dispositivo.
Un lsusb lo detecta así:

Bus 002 Device 013: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Descargué el código fuente de un driver CM-15A y, después de un ratito quitando errores de compilación, logré tener un cm15a.ko que cargaba correctamente en mi CentOS y me generaba un device /dev/cm15a0. 

A partir de aquí, lo siguiente es probar a emitir. Los códigos de casa y dispositivo a enviar que se pueden encontrar en ftp://ftp.x10.com/pub/manuals/cm11a_protocol.txt no responden a ningún tipo de lógica ni algorítmica, por lo que (no recuerdo dónde) encontré un script que convertía los códigos que se deseaban a los bits necesarios a enviar al dispositivo USB para enviar un comando a un dispositivo:

A partir de ese script, hice el mío propio para poder enviar por línea de comandos lo que se quiera:



  
Como véis en el código, es tan sencillo como ejecutar el programa pasándole el código de casa, de dispositivo y el comando a ejecutar (en mi caso, on/off y creo que DIM, aunque no lo he probado) Si vía línea de comandos le paso el 0 como código de dispositivo, interpretaré que he de ejecutar el mismo comando en TODOS los dispositivos controlados vía X-10

Las contras de X-10
  • Fiabilidad del protocolo: No todo en el mundo X-10 es de color de rosa, y es que la fiabilidad de la recepción de las señales no es 100%. De hecho, me atrevería a decir que esa ha sido la causa de su bajo éxito en el mundo casero. Inherentemente, el propio protocolo en sí, utiliza la señal de baja tensión de la corriente eléctrica para enviar una serie de impulsos eléctricos que los dispositivos X-10 identifican como bits para saber si tienen o no que encenderse/apagarse o lo que sea. El propio protocolo es tan poco fiable, que de por sí, manda la señal dos veces seguidas. Por las pruebas que yo he hecho, puedo decir que en muchos casos, incluso yo he tenido que mandar el comando hasta 3 veces (en mi user-space) para que los sensores X-10 ejecuten la acción. Al ser, los que yo tengo, dispositivos unidireccionales (que no permiten "leer" el estado de los elementos que controlan) no hay forma de saber si les ha llegado la orden. Por si acaso, la mando tres veces y aumento las probabilidades.

  • La longitud del cable: Aunque parezca que la electricidad funciona estupendamente, no siempre es así. Que toques la Fase y el Neutro de la corriente eléctrica de casa, a nosecuantos metros de cable del cuadro eléctrico, y te electrocutes no quiere decir que por conectar un dispositivo X-10 ahí, éste vaya a interpretar correctamente las órdenes y vaya a funcionar correctamente. Cuantos más metros de cable o cuantos más dispositivos X-10 encadenes entre ellos (en mi caso, tuve que "coser" 6 interruptores X-10) menor fiabilidad existirá. Recomiendo encarecidamente poner el mayor de los cuidados en no hacer "chapuzas eléctricas". Es decir, que cuantos más pelillos de cable entren en los diferentes interruptores, mayor será la calidad de recepción de la señal, por lo que tendremos una mayor tranquilidad que la orden se ejecutó convenientemente. Para ello, recomiendo que no se "cosan" más de tres  dispositivos X-10 entre ellos, de manera que la corriente tenga que atravesarlos todos para llegar. Incluso haciendo conexiones en paralelo, es conveniente sacar toma de corriente de diferentes enchufes o cajas de empalmes, para hacer más sencillo el flujo de los datos a través de la red eléctrica.

  • Las interferencias electromagnéticas: Lógicamente, el ruido electromagnético existente en la red eléctrica (en base a los diferentes electrodomésticos conectados a la misma, así como su actividad) afectan enormemente a la fiabilidad de los comandos X-10. Sin embargo, he de decir que me ha sorprendido el grado en el que el funcionamiento se ve afectado. En mi caso, que enciendo 6 motores vía X-10, el propio ruido eléctrico que generan los tres primeros, hacen que la orden para los otros tres no se interprete correctamente mientras los primeros mecanismos aún se están moviendo. Por poneros un ejemplo aún más curioso, ha coincidido que hace un par de semanas he tenido que preparar un curso de Checkpoint GAiA para dar a un cliente. Para ello, he estado instalando el software de Checkpoint en un PC que tenía en el trastero. Pues simplemente, con tener enchufada la máquina (un Dell Dimension 2400), sin que siquiera estuviese encendido, sólo enchufado en la misma fase donde tengo conectado el CM15A,… ya inhabilita su funcionamiento completamente. No os imagináis el susto que me llevé cuando ví que el X-10 dejaba de funcionar. Para ocasiones en las que no podemos desenchufar un electrodoméstico que genere mucho ruido eléctrico, se puede incorporar un filtro en el enchufe que mitigue esas interferencias.

  • Seguridad de X-10: Se supone que en instalaciones monofásicas (el mayor porcentaje de las casas), las órdenes X-10 llegan hasta los elementos conectados a ese cuadro eléctrico y ya está, quedando acotadas a lo que haya dentro de ese diferencial. En instalaciones trifásicas, en las que necesitamos hablar a dispositivos X-10 que están en las diferentes fases, hay que hacer una "pequeña" modificación en el cuadro eléctrico para permitir el paso de las señales X-10. Se supone que los comandos no salen de nuestra propia red eléctrica, pero por si acaso, he desarrollado un sencillo script que por fuerza bruta, pone a ON todos los dispositivos X-10 del espectro posible. Así que si tenéis la seguridad que la vecina (o los servicios comunes de una comunidad) tienen dispositivos X-10, podéis probar a ejecutar este script desde vuestra casa (o desde un enchufe público de la comunidad), y ver si hay suerte y se pone algo a funcionar:



  • Dónde comprar dipositivos X-10: En tiendas físicas, esto del X-10 y la domótica no existe. Y en tiendas online, desgraciadamente, cada vez quedan menos que distribuyan este tipo de dispositivos. En mi caso, he tenido la suerte de haber hecho buenas migas con Javier Elices, uno de los dueños de la tienda online "Domoticayseguridad", cuya oficina física está cerca de Plaza Castilla en Madrid. Si necesitáis asesoramiento sobre dispositivos domóticos, os puedo asegurar que Javier es uno de los que "lo vive" (qué identificado me he sentido en las largas conversaciones que hemos tenido sobre mis locas ideas...)
Leer más...

10 junio 2012

Enlaces de la SECmana - 127

Leer más...

09 junio 2012

¡Metadatos hasta en la sopa!


Los metadatos están por todos lados dicen las malas lenguas. De los creadores de los ataques XSS (Cross Site Scripting) no son peligrosos llegan, en una nueva entrega, los metadatos no sirven para nada.


La pregunta, sin duda es, ¿les haremos caso? Yo creo que no, que ya se ha demostrado el poder de un ataque XSS bien ejecutado, y los chicos de SecurityByDefault conjuntamente con los de informática64 han demostrado que los metadatos están ahí y sirven para algo. }:))

Se ha puesto de moda subir a twitter/facebook/tuenti todo lo que te pasa desde tu flamante smartphone, lo que quizás muchos no saben es que estos dispositivos guardan metadatos en las imágenes que permiten localizarte (coordenadas GPS) entre otras cosas. Y es que en uno de esos procesos de recopilar información de nuestro objectivo, no podría faltar su ubicación (quizás falseada en sus datos personales).

Yo me centraré solamente en twitter, pero... ¡dónde las dan, las toman!



Usaré exiftool para extraer los metadatos. Cogeré una fotografía que ha subido X persona a twitter.


Luego tendríamos que tirar de Google Earth para localizarlo y saber su ubicación. ¿Como evitar esto?

ExifCleaner es una buena opción. Además os ponen una foto de una rubia que ya anima a descargarlo...


Si tienes iPhone sin JailBreak, no olvides acceder a la sección de configuración referente con la Localización, y desactivar los servicios de localización para los programas de cámaras, redes sociales, etc. Es una recomendación.



Si además posees el iPhone con Jailbreak, en Cydia puedes encontrar el programa Metadaremovr:



No conozco ningún programa para Android, por lo que si sabéis de alguno, ¡no dudéis en usar los comentarios!

¡Ya no hay excusas! Un saludo a todos los lectores y gracias por vuestro tiempo (quizás perdido con mi contribución). }:))

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

Artículo por @p0is0nseginf
Leer más...