31/10/2014

Policía brasileña desarticula una red de intercambio de pornografía infantil


La red utilizaba una aplicación para distribuir el material ilícito entre sus miembros, informaron fuentes policiales.

Los datos estaban codificados y, según la Policía, los miembros de esta red tenían "libertad total" para distribuir estos archivos, porque el administrador de la aplicación no podía bloquear los contenidos ni denunciarlos a las autoridades, según determina la legislación.

La Policía pudo rastrear a los miembros de esta red gracias a la detención de uno de sus integrantes en la Operación Infancia Segura I, primera parte de la investigación actual, desarrollada el pasado mes de junio.

Para la segunda fase de la operación, el juez encargado del caso ordenó 40 órdenes de búsqueda y captura en 35 ciudades brasileñas de 14 estados diferentes.La Operación Infancia Segura II fue dirigida por la comisaría de Policía Federal de la ciudad de Uberlandia, en el estado de Minas Gerais, con el apoyo de la Unidad de Represión a los Crímenes de Discriminación y Pornografía Infantil de Brasil (URCOP, por sus siglas en portugués).

Fuente: Caracol

FBI descubre al "segundo Snowden" en la NSA

El FBI habría descubierto un nuevo filtrador de documentos secretos de los servicios de inteligencia estadounidense. Un “segundo Snowden” del que hace tiempo se rumoreaba su existencia y cuya identidad no se ha hecho pública.

Las sospechas de este nuevo filtrador llegaron tras la publicación de varias informaciones que revelaron informaciones confidenciales y en especial una denominada como ‘Barack Obama’s Secret Terrorist-Tracking System, by the Numbers’ acerca de la existencia de una base de datos del Gobierno con nombres de sospechosos clasificados como ‘terroristas’.

El documento tenía fecha de agosto de 2013, algunos meses después que Snowden huyera de los EE.UU y el periodista de The Guardian que las reveló, Glenn Greenwald, prometió nuevas revelaciones que se suponen filtraciones de este segundo Snowden.

Los analistas de seguridad no lo descartan y adelantan otro periodo de revelaciones a pesar del aumento de seguridad que se supone se implementó tras salir a la luz los programas de ciberespionaje de NSA:
"Sólo porque un documento tiene una marca de secreto no significa que sea seguro. La protección de los documentos en esencia comienza con la gente, a las que se concede acceso y el cometido de protegerlos. Mientras que un despacho secreto puede sonar impresionante, en general no es demasiado complicado el acceso para un individuo con permisos".
Fuente: Muy Seguridad

El fundador de The Pirate Bay ha sido encontrado culpable

Es bastante conocido en el mundo el hecho de que The Pirate Bay, la plataforma más popular en el mundo para compartir cualquier tipo de contenido a través del protocolo P2P (peer to peer), es sinónimo de piratería para las grandes firmas discográficas, cinematográficas y en general para toda la industria del entretenimiento y la electrónica de consumo.

Sus fundadores han sido víctimas de una cacería de brujas en todo el mundo, y Gottfrid Svartholm, no es la excepción. El conocido padre de The Pirate Bay incluso tuvo que huir de su país natal, Suecia, para escapar de cargos de los que se les acusaba y para muchos son injustos e inválidos, pero para la "ley" (apoyada por la industria del entretenimiento), son motivo suficiente para ponerlo tras las rejas.

Lamentablemente, este ha sido el caso durante los últimos años. Gottfrid Svartholm fue aprendido en Camboya y llevado a Dinamarca, en una operación internacional como si se tratase del peor terrorista o asesino del mundo, bajo los cargos de "haber hackeado los servidores de una conocida firma de tecnología, y robado información confidencial durante meses". Hoy, el juicio ha concluido y el juez ha dado un veredicto: culpable.

Gottfrid Svartholm ha sido encontrado culpable de los cargos de hackear y obtener acceso de forma ilegal a información confidencial en los servidores de CSC en el año 2012, en los que se mantuvieron por cuatro meses.

El fundador de The Pirate Bay, mejor conocido simplemente con el seudónimo de "Anakata", ya lleva 11 meses en prisión, pero ahora falta conocer cuál será la condena que le imponga este juez, la cual será anunciada hoy, 31 de octubre.

Fuente: Alt1040

30/10/2014

ODILA: cómo denunciar delitos informáticos en Latinoamérica

Esta nota ha sido publicada por We Live Security en mención del Proyecto ODILA presentado hace instantes en ekoparty, del cual Segu-Info orgullasamente es uno de los creadores junto a AsegurarTE.

De seguro recuerdan el concepto de Deep Web: aquella parte de Internet que está oculta, escondida, y no vemos a simple vista -pero está ahí, detrás de la Internet que usamos cotidianamente. Con una idea similar, ha surgido el concepto de "cifra negra" de los delitos informáticos: aquella que desconocemos y escapa de las estadísticas habitualmente, ya sea porque las víctimas no denuncian ataques o no saben cómo o dónde hacerlo. De esa forma, la ocurrencia de delitos no sale a la luz.

Con el espíritu de terminar con esa falta de números y esa falta de conocimiento acerca de cómo proceder ante un ataque informático, nace el Observatorio de Delitos Informáticos de Latinoamérica (ODILA). Como parte de nuestra cobertura especial de la conferencia de seguridad ekoparty, asistimos a la presentación del proyecto y hablamos con sus responsables para conocer mejor el contexto de su creación.

Por empezar, hay una tendencia de los usuarios a creer que en Internet “se puede hacer todo”, que no hay regulaciones ni existen cosas ilegales. Lo cierto es que cada país de Latinoamérica tiene, en mayor o menor medida, una legislación en lo que refiere a delitos informáticos, aunque no haya una unificación ni un denominador común. Sí hay un conjunto de características que hacen a un delito: son pluriofensivos, no distinguen víctimas, no tienen fronteras, y son de difícil investigación.

Durante la presentación, Cristian Borghello, Maximiliano Macedo y Marcelo Temperini compartieron casos de personas que acudieron a ellos con pedidos un tanto descabellados. Por ejemplo, "meter algún virus o algo así en el sistema de Whatsapp" para que se borre una imagen.

ODILA viene a decir que, en verdad, en Internet no se vale todo y que hay que denunciar los casos. Mediante un formulario de denuncia anónimo, el sitio permitirá informar sobre cualquier caso de ataque, sin importar que el usuario no haya sido la víctima directa. Según su país de residencia y el tipo de incidente, se le brinda información sobre dónde denunciar y cómo proceder, dada la falta de instrucciones claras en ese sentido. A esos fines, ODILA ha elaborado un mapa de delitos informáticos, que muestra qué leyes hay en cada país de Latinoamérica.

Sucede que un problema frecuente es que las personas no saben a quién acudir o dónde presentar una denuncia si han sido víctimas de un delito informático. Sumado a eso, generalmente quieren confidencialidad, y que su nombre no salga a la luz para resguardar su identidad.

El proyecto persigue el objetivo final de demostrar que hay delitos que suceden y no son denunciados, los que constituyen la "cifra negra", y comenzar a canalizar las denuncias de estos casos para elaborar estadísticas que den un panorama en toda Latinoamérica. Con la información recopilada, se dará asesoramiento a las personas en lo que respecta a la realización de denuncias.

Queda clara entonces la necesidad de que la ocurrencia de delitos informáticos sea reportada, para que se pueda combatir la "cifra negra". Los invitamos a visitar el sitio de ODILA para obtener más información y colaborar con la elaboración de estadísticas sobre ataques en América Latina.

Fuente: We Live Security

"Find my Mobile" de Samsung permite a un atacante bloquear el móvil

Se ha anunciado una vulnerabilidad en el servicio "Find my mobile" de Samsung que podría permitir a un atacante remoto activar sus funcionalidades, de forma que podría hacer que suene o bloquearlo (con un código arbitrario). Se ha asociado el CVE-2014-8346 a esta vulnerabilidad.
La función "Find my Mobile" implementada por Samsung en sus dispositivos es un servicio web que proporciona a los usuarios de dispositivos Samsung características para localizar un dispositivo perdido o robado.

Esta utilidad incluida también por otros fabricantes (como Apple o Microsoft), permite hacer sonar el dispositivo remoto, borrar su contenido o bloquearlo de forma remota para que nadie más pueda conseguir acceso al dispositivo perdido.

El problema, descubierto por Mohamed A. Baset (@SymbianSyMoh), reside en una vulnerabilidad de Cross-Site Request Forgery (CSRF), que podría permitir a un atacante bloquear el dispositivo con un código de su elección. Básicamente, el atacante utilizará el ataque CSRF para engañar al usuario para acceder a un enlace o url que contiene peticiones maliciosas o no autorizadas. El atacante podrá llegar a bloquear el móvil del usuario con un código de su elección, lo que forzaría al usuario a realizar una recuperación del código de bloqueo a través de su cuenta Google.

El enlace malicioso tiene los mismos privilegios que el usuario autorizado para llevar a cabo una tarea no deseada en el nombre de la víctima. Las vulnerabilidades de Cross-site Request Forgery (CSRF) permiten a un atacante ejecutar funcionalidades de una web determinada a través de la sesión activa en esa web de otro usuario.

El investigador ha proporcionado pruebas de concepto en forma de vídeos que detallan como llevar a cabo el ataque y los efectos que puede tener.
Fuente: Hispasec

Cómo funcionan las MongoDB Injection

Las inyecciones SQL han sido tradicionalmente uno de los vectores de ataque más utilizados por los atacantes. De hecho, es una de las técnicas más eficaces para el robo y la alteración de información sensible. Sin embargo, no existe (aún) una marcada tendencia hacia la explotación de las llamadas bases de datos NoSQL, o sea, bases de datos no relacionales pensadas para el almacenamiento de grandes cantidades de información. De entre todas estas bases de datos NoSQL, quizá el representante más ilustre sea MongoDB. ¿Es inmune a las inyecciones?

¿Qué es MongoDB?

El nombre MongoDB, viene del inglés "humongous" (inmenso). Es un sistema de base de datos no relacional de código abierto y orientado a documentos. MongoDB se basa en colecciones de documentos Json, lo que le otorga una gran flexibilidad en cuanto a la naturaleza de la información que almacena, puesto que puede haber documentos con diferente esquema dentro de una misma colección.

De MongoDB destaca su gran velocidad y escalabilidad, porque puede manejar sin apenas esfuerzo volúmenes de datos del orden de gigabytes. En los últimos tiempos, su nómina de clientes ha crecido considerablemente; Foursquare, MTV, The New York Times, etc. ya lo utilizan.

¿Es MongoDB vulnerable a inyecciones?

Al no tratarse de una base de datos SQL, podría parecer que MongoDB no es vulnerable a inyecciones maliciosas. Sin embargo, veremos que no es así. Se pueden realizar muchos tipos de inyecciones en MongoDB, aunque la viabilidad del ataque depende en gran medida del driver de Mongo utilizado.

Por ejemplo, en PHP es posible realizar una inyección muy similar a la clásica inyección SQL, alterando la consulta de manera que devuelva todo el contenido de una colección. Imaginemos la típica consulta de credenciales que hay tras un login. En SQL, sería algo como lo que sigue:

SELECT * FROM tUsers WHERE username = ‘username’ AND password = ‘password’
La consulta equivalente en MongoDB sería:
$collection -> find(array(
  "username" => $_GET[‘username’],
  "password" => $_GET[‘password’] ));
El problema es que PHP permite pasarle objetos al driver de MongoDB, sin que tengan que ser necesariamente strings. Explotando esta vulnerabilidad, podemos pasar un objeto que fuerce una condición "true" y provoque el volcado de la colección. Por ejemplo, enviando una petición como esta:
login.php?username=administrador&password[$ne]=1
Obtendríamos una consulta interna de esta forma:
$collection -> find(array( 
  "username" => "administrador"
  "password" => array("$ne" => 1) ));
Esta consulta devuelve las credenciales de todos los usuarios cuyo nombre de usuario y contraseña sea distinto ("not equal", $ne) de 1, condición que probablemente cumpla cualquier contraseña.

La solución pasa por "tipar" los objetos que se le pasan al driver. El hecho de que muchos drivers de MongoDB admitan objetos no tipados supone una vulnerabilidad.

¿Cómo comprobar si se es vulnerable?

Como no podía ser de otra manera, Faast incorpora entre su batería de plugins, uno capaz de detectar vulnerabilidades de este tipo. Sin embargo, como ya se ha mencionado, la presencia de esta vulnerabilidad depende enormemente del driver utilizado en el dominio bajo análisis.

Existen multitud de drivers para MongoDB. El plugin de Faast está orientado a detectar inyecciones en MongoDB, aprovechando la capacidad del motor Mongo para ejecutar Javascript. Utiliza la técnica de time-based detection para determinar si la URL que recibe como parámetro es vulnerable, aprovechando a su vez el comando "sleep" de MongoDB, que bloquea todas las operaciones de la base de datos durante un determinado período de tiempo.

Por ejemplo, tras recibir la URL, el plugin de Faast realiza dos peticiones independientes, concatenando las siguientes cadenas a la URL original. En la primera se ejecuta un sleep durante 10 segundos, en la segunda, no.
;if(tojson(this)[0] =="{")) {sleep("10000")};
;if(tojson(this)[0] =="{")) {sleep("0")}
Para determinar si es posible inyectar, se compara el tiempo de respuesta de ambas peticiones. Si la diferencia de tiempos es superior a un determinado umbral, se considera positivo y por tanto la URL es vulnerable. Para minimizar la influencia de tiempos de propagación, etc… y evitar falsos positivos, la prueba se repite un número determinado de veces. Será necesario que el resultado de los N intentos sea positivo para considerar la URL como vulnerable.

El auge que están viviendo los motores de bases de datos no relacionales, hace que se conviertan en un objetivo prioritario para los atacantes. Aunque las inyecciones SQL siguen siendo frecuentes, ya no representan una novedad en el mundo del cibercrimen, y las recetas y buenas prácticas para evitarlas están muy estudiadas. Sin embargo, las bases de datos NoSQL suponen un territorio nuevo que explorar. Por eso Faast pretende adelantarse a los atacantes y facilitar que se tomen las medidas adecuadas para salvaguardar la integridad de los datos de los clientes.

Fuente: ElevenPath

Cómo evadir antivirus de Yahoo!, varios IDS y otros antivirus

MIME describe el formato de transferencia de cualquier correo electrónico que contenga archivos adjuntos, imágenes incrustadas, etc. Este formato se remonta a los inicios de Internet y dado que los protocolos utilizados (UUCP y el actual SMTP) se basaban en texto ASCII, cualquier binario o mensaje no ASCII tenía que ser codificado previamente para el transporte.
Para especificar el tipo de codificación se utiliza la cabecera Content-Transfer-Encoding.

Dado que para el transporte sólo es necesaria una única codificación la especificación permite el uso de un único encabezado. Pero ¿qué ocurre si se utilizan de todas formas varios encabezados?

Resulta que la mayoría de clientes de correo y los interfaces web usarán el primer encabezado, mientras que los IDS como Bro y Snort y un montón de productos antivirus sólo usarán la última cabecera. Los resultados que se detallan a continuación se basan en pruebas realizadas a 9 de octubre:

Comportamiento observado: clientes de correo, Web mail, MTA, IDS

La primera cabecera Content-Transfer-Encoding es usada por:
  • google MTA (bloquea virus directamente en la conversación SMTP)
  • gmail Web interface
  • GMX Web interface (bloqueará el correo si contiene virus, ver abajo)
  • AOL Web interface
  • Thunderbird
  • Apple Mail
  • Opera Mail
  • Perl MIME::Tools, que es usado por amavisd
  • KDE kmail
  • horde Web interface
La última cabecera Content-Transfer-Encoding es usada por:
  • mutt
  • Outlook.de Web interface (Windows Live Mail)
  • basado en el análisis del código fuente: snort 2.9.6.2. Interesante que solo acepta "Encoding" en lugar de "Content-Transfer-Encoding".
  • basado en el análisis del código fuente: bro 2.3.1
Otros comportamientos:
  • Al correo en Android parece que no le gusta el conflicto con varias cabeceras y no mostrará el archivo adjunto.
  • GMX encuentra el virus sin importar el orden de los encabezados que utilizamos y reemplaza el correo afectado por un correo informativo acerca de la infección por el virus
  • AOL MTA encuentra el virus también en ambos casos y bloquea el correo inmediatamente en el diálogo SMTP. Bien hecho!

Comportamiento observado: productos Antivirus

Los productos de antivirus muestran una gran variedad de comportamiento. Se han probado mediante virustotal.com con archivos en formato mbox o RFC822. Cualquier motor que no encontrara el virus Eicar en cualquiera de estas pruebas fue ignorado, ya que parece no entender estos formatos. resultados:
  • El escáner de virus Rising sólo encontrará el virus si se da una sola cabecera.
  • 7 productos antivirus sólo comprueban el primer encabezado y por lo tanto están en línea con la mayoría de los clientes de correo: Jiangmin, Kaspersky, Panda, Symantec, TrendMicro, TrendMicro-HouseCall, Zoner.
  • 12 productos antivirus sólo comprueban la última cabecera y se comportan de este modo contrario a la mayoría de clientes de correo, lo que hace posible el fraude: Agnitum, Avast, Avira, Comodo, Cyren, DrWeb, ESET NOD32-, Fortinet, F-Prot, NANO-Antivirus, Tencent, VBA32.
  • 11 productos detectan el virus independiente del orden de las cabeceras y por lo tanto no pueden ser evadidos de esta manera, no importa qde correo utilizado: BitDefender, ClamAV, a-squared, F-Secure, GData, Ícaro, McAfee, McAfee-GW-Edición , Microsoft, MicroWorld-eScan, Sophos.

El comportamiento más divertido: Correo Web de Yahoo!

El MTA de Yahoo parece no tener incorporado el análisis de virus, pero la interfaz de correo Web utiliza Norton de Symantec para escanear los archivos adjuntos antes de la descarga. El problema es que la interacción entre el antivirus y la descarga es totalmente independiente lo que permite la evasión inmediata del escáner antivirus:
  • El antivirus analiza la última cabecera Content-Transfer-Encoding y por lo tanto no va a encontrar el virus en nuestro correo de ejemplo.
  • La descarga de los datos adjuntos mirará la primera cabecera Content-Transfer-Encoding y por lo tanto el contenido (el virus) será descargado correctamente.
  • La vista previa del correo usará de nuevo la última cabecera.
El problema se comunicó a Yahoo a través de hackerone en 09/10/2014, pero lo cerraron como "no se corregirá", porque dijeron "Ya estamos al tanto de esta funcionalidad en nuestro sitio y estamos trabajando en una solución.". No se recibió respuesta cuando le preguntaron si era buena idea publicar el fallo. La última vez que se comprobó (28/10/2014) el bug seguía allí.

Fuente: HackPlayers y Noxxi

29/10/2014

tnFTP vulnerable en OSX 10.10 y NetBSD

En el día de hoy se ha notificado una vulnerabilidad grave en el cliente FTP tnftp basado en BSD, presente por defecto en todas las distribuciones de BSD, OSX y en decenas de distribuciones de Linux. Por ahora la vulnerabilidad se ha confirmado en OSX 10.10 (Yosemite), NetBSD 7.99.1, Debian y RedHat.

La vulnerabilidad identificada como CVE-2014-8517 permite ejecución de código y comandos arbitrarios. Según se reporta en varias listas, por ejemplo si se ejecuta:
ftp http://server/path/file.txt
Sin especificar un nombre de archivo como salida (opción -o), el cliente FTP puede ser "engañado" para ejecutar comandos arbitrarios a través de la redirección de URLs y comandos.

La vulnerabilidad fue encontrada por Jared Mcneill y ya ha sido reportada a los respectivos fabricantes que se encuentran trabajando en la solución.

Cristian de la Redacción de Segu-Info

Hackearon las computadoras de la Casa Blanca y sospechan que fue Rusia


Hackers accedieron a una de las redes de computadores de la presidencia de Estados Unidos en las últimas semanas por lo que varios equipos de la Casa Blanca debieron ser desconectados ayer temporalmente. Según afirma hoy el diario The Washington Post, el gobierno estadounidense señala como responsable del ataque al gobierno ruso.

Según el diario estadounidense, que cita fuentes anónimas, los hackers que accedieron a la red presidencial en las últimas semanas trabajan para el gobierno ruso.

Según el funcionario Casa Blanca que anunció el hecho en condición de anonimato y no precisó la naturaleza de estas actividades, se ha "identificado actividad preocupante en la red EOP que maneja documentos no clasificados", es decir, que no pudieron acceder a información relevante. Además, agregaron que los intrusos no dañaron los sistemas.

"En el curso de la evaluación de las amenazas recientes, hemos identificado la actividad de preocupación en la Oficina Ejecutiva no clasificada de la red del Presidente", dijo un funcionario de la Casa Blanca. "Tomamos medidas inmediatas para evaluar y mitigar la actividad. Por desgracia, algunos de ellos derivaron en la interrupción de los servicios regulares de los usuarios. Pero la gente está con eso y está tratando de solucionarlo".

El FBI, el Servicio Secreto y la Agencia de Seguridad Nacional (NSA, por sus cifras en inglés) están trabajando en la investigación.

Informes recientes de firmas de seguridad identificaron campañas de ciberespionaje de hackers rusos que creen que trabajan para el Kremlin. Los objetivos han incluido la OTAN, el gobierno de Ucrania y los contratistas de defensa estadounidenses.

Rusia es considerada por funcionarios estadounidenses como una de las potencias respecto de las capacidades cibernéticas.

En el caso de la Casa Blanca, la naturaleza de este último objetivo es consistente con una campaña con el auspicio del estado ruso, dijeron las fuentes.

La Casa Blanca recibe alertas diarias de sus expertos en informática respecto a posibles amenazas cibernéticas.

Se cree que el servicio de inteligencia ruso ha estado detrás de un ataque a las redes militares clasificadas de Estados Unidos, descubierto en 2008. La operación para contener la intrusión y limpiar los ordenadores, llamada Buckshot Yankee, llevó meses.

Fuente: La Nación

Webminario sobre Seguridad en Redes Móviles

Hace un tiempo Julian Gonzalez, de Seguridad para Todos, organizó un webminario sobre Seguridad en Redes Móviles.
Debido a que no todo el mundo pudo asistir a la sesión online, ha decidido poner a vuestra disposición la grabación de la misma, de modo que cualquiera pueda acceder "bajo demanda" siempre y cuando youtube lo permita.

Fuente:Seguridad para Todos