4 de mar. de 2015

Supuesta vulnerabilidad en Telegram, permite el acceso a los mensajes secretos

Se ha encontrado una vulnerabilidad en la popular aplicación de mensajería Telegram, que permite el compromiso de los chas secreto, los cuales se suponen que proporcionan cifrado de extremo a extremo.

En realidad, el ataque se origina a través de una aplicación que gana permisos adicionales mediante la ejecución de un exploit y la empresa Zimperium fue capaz de hacer legibles el texto de los chats secretos en la memoria y desde el archivo Cache4.db.
Zuk Avraham, fundador, presidente y CTO de Zimperium escribió que "Una vulnerabilidad crítica en Telegram expone a sus más de 50 millones de usuarios".

Tal y como mencionan en Hispasec, el supuesto "hackeo" a Telegram, no es un ataque basado en una debilidad en el protocolo de cifrado o una implementación defectuosa en el cliente que permita a un servidor controlado por el atacante explotarla. La técnica usada para acceder a los mensajes es general, de libro, se resume en un solo párrafo.

Envías a un objetivo un enlace que explota una vulnerabilidad en el navegador, estableces un canal, elevas privilegios y ya eres root. Listo, ya puedes acceder a cualquier rincón del sistema, memoria, disco, tarjeta, etc. con el añadido extra de que si se trata de un terminal móvil inteligente casi te aseguras una conexión persistente. O más fácil todavía, empaquetas todo eso en una aplicación maliciosa y se la regalas a tu objetivo, listo, ya tienes lo que necesitas.

Avraham dijo que notificó la empresa varias veces de la falla, y después de 30 días sin recibir ninguna respuesta, la ha hecho pública con la prueba de concepto para el "hack".

Es fácil caer en ese fallo de concepto. No se trata de un ataque a una aplicación concreta, se trata de un compromiso total del sistema, una vez eres root se acabó el juego, no hay nada más después.

Fuente: Infosecurity Magazine

INCIBE publica un informe de situación del malware para Android

INCIBE, el Instituto Nacional de Ciberseguridad, en colaboración con Hispasec, ha publicado un estudio sobre la situación del malware en la plataforma Android.

El informe desgrana completamente el estado actual de la mayor amenaza que afecta al popular sistema operativo móvil. Los factores principales que justifican la proliferación del malware en Android y los perniciosos efectos que provoca el impacto de una infección en los terminales de los usuarios.

Para efectuar el estudio se ha recolectado y analizado 76.000 muestras de malware activo en los últimos seis meses. Para cada muestra individualizada se ha tenido en cuenta el dictamen de cinco motores antivirus, con el objeto de identificar y discriminar falsos positivos que afectasen al rigor de los resultados.

El informe también nos muestra la capacidad de defensa del sistema, las distintas capas de seguridad y mecanismos de mitigación de ataques. Una completa radiografía que pone en evidencia los esfuerzos que el fabricante está haciendo, encuadrada en la evolución del sistema y su mercado de aplicaciones principal: Google Play, para intentar paliar la problemática objeto de estudio.

El grueso del documento nos mete de lleno en la anatomía del malware. No se trata por tanto de un estudio que simplemente se limite a traernos un sesgo estadístico del análisis automatizado de las muestras, sino que nos permite adentrarnos en el complejo funcionamiento del malware actual y el entramado que sostiene la monetización de la industria criminal.

El informe está publicado tanto en español en:
https://www.incibe.es/extfrontinteco/img/File/intecocert/EstudiosInformes/situacion_del_malware_para_android.pdf
Como en inglés en:
https://www.incibe.es/extfrontinteco/img/File/intecocert/EstudiosInformes/android_malware_situation.pdf

Os invitamos a su lectura, a contemplar la fotografía más reciente que tiene el rostro del crimen en uno de los sistemas móviles más populares.

Fuente: Hispasec

FREAK attack, el nuevo agujero en TLS/SSL

Por enésima vez en los últimos años, expertos advierten sobre una nueva vulnerabilidad en algunos clientes SSL populares. FREAK (Factoring Attack on RSA-EXPORT Keys) es un fallo permite que un atacante forzar a los clientes a realizar un downgrade a cifrados débiles y violar comunicaciones supuestamente cifradas a través de un ataque Man-in-the-Middle. FREAK es similar a POODLE porque permite realizar un downgrade a versiones débiles de cifrado.

FREAK fue originalmente descubierto por Karthikeyan Bhargavan y por el el equipo de mitLS y fue bautizado como Smack TLS en INRIA en París. Otra revelación fue coordinada por Matthew Green y fue descubierto por un numeroso grupo de investigadores de Microsoft Research y el French National Institute for Research in Computer Science and Control.

Esta vulnerabilidad afecta a una gran variedad de clientes, destacando el navegador Safari de Apple y el navegador nativo de Android. Los investigadores descubrieron que algunos clientes TLS/SSL, incluyendo OpenSSL (CVE-2015-0204), aceptan claves RSA débiles -conocidas como claves de exportación-. Estas claves RSA son de 512 bits, las cuales hace décadas han sido abandonadas por la mayoría de los servidores y clientes por ser demasiados débiles.
Las export-grade RSA son los restos de un esfuerzo de los años 80 para debilitar la criptografía y que la misma pueda ser supervisada por las agencias de inteligencia. "Mientras que estas políticas fueron finalmente desechadas, todavía nos están haciendo daño" escribió el criptógrafo Matthew Green de la Universidad Johns Hopkins. "En teoría esto fue diseñado para asegurar que la NSA tendría la capacidad de 'acceso' a todas las comunicaciones cifradas. Es como una 'golden master key'".

Encontraron que dado un servidor que admite cifras de exportación y un cliente que acepta esas llaves débiles, un atacante en una posición de Man-in-the-Middle podría obligar a un cliente a hacer un downgrade a las claves débiles. Entonces se podría tomar dicha clave y factorizarla, cosa que los investigadores fueron capaces de hacer en siete horas y media usando Amazon EC2 y puede hacerse por un costo que ronda los U$S100.

Cómo funciona FREAK

  • En el cliente, el mensaje de HELLO solicita un cifrado estándar 'RSA'.
  • El atacante MitM cambia este mensaje para pedir un 'exportar RSA'.
  • Si la tiene, el servidor responde con una clave RSA de 512 bits, firmada con su clave a largo plazo.
  • El cliente acepta esta clave débil debido al bug.
  • El atacante factorea el módulo RSA para recuperar la clave RSA de descifrado correspondiente.
  • Cuando el cliente de cifra el 'pre-master secret' en el servidor, el atacante puede descifrarlo para recuperar los 'master secret'.
  • De aquí en adelante, el atacante ve texto plano y puede inyectar todo lo que quiera.
Los investigadores de la Universidad de Michigan encontraron que el 36,7 por ciento de los sitios "seguros" son vulnerable a este ataque, pero los expertos dicen que, en la práctica, el ataque no es de peligro inminente. Además, la Universidad ha publicado un test automático para conocer si el cliente es vulnerable y una lista de sitios que admiten claves export-grade.

Cristian de la Redacción de Segu-Info

3 de mar. de 2015

Acuerdo de Confidencialidad: ¿necesito uno para contratar a un freelance?

Uno de los factores clave a la hora de contratar a un freelance es la confianza. Las empresas buscan trabajadores serios que les inspiren tranquilidad y profesionalidad. En muchas ocasiones, estas compañías ya han pasado por la experiencia de la contratación online y puede que los resultados no fueran los esperados.

En determinados casos, la preocupación del contratador no está ligada a las capacidades del freelance para llevar a cabo el trabajo encomendado, sino que está relacionada con la información sensible que éste tendrá que manejar.

Cuando nos referimos a proyectos de desarrollo de software o incluso diseño gráfico, si la idea a llevar a cabo es innovadora siempre existe el miedo a que nos la roben. También es normal desconfiar de un freelance que haya trabajado en una empresa de la competencia por si, como en las pelis de espías, resulta ser un “topo”.

¿Cómo podemos protegernos de estos infortunios? Muy simple, redactando un acuerdo de confidencialidad:

¿Cuándo necesito un Acuerdo de Confidencialidad?

Los empleados internos de nuestra compañía deben respetar la información sensible de nuestra empresa sin necesidad de firmar un acuerdo de confidencialidad. En el caso de la contratación freelance, la firma de este tipo de acuerdos puede evitarnos muchos quebraderos de cabeza. El objetivo principal es evitar que los profesionales compartan ninguna clase de información sobre el proyecto en el que están trabajando, especialmente con un competidor.

De este modo, solamente necesitaríamos un acuerdo de confidencialidad cuando el freelance esté obligado a trabajar con información importante para nuestra compañía. Cuando hablamos de información sensible, debemos entender que no nos referimos sólo a planes de negocio o ideas innovadoras, no nos podemos olvidar de uno de los recursos más valiosos de la empresa: su base de datos de clientes.

Por lo tanto, dependiendo del carácter del proyecto debemos decidir si la firma de un acuerdo de confidencialidad es necesaria o no. Si tu respuesta es sí, a continuación encontrarás algunos consejos para ponerte manos a la obra.

¿Cómo redactar un Acuerdo de Confidencialidad?

Piensa qué es lo peor que puede pasar y protégete ante ello. Realizar este ejercicio te servirá para poner los pies en el suelo y ser consciente de los peligros que puede correr tu empresa. Además debes asegurarte de definir correctamente qué se considera información confidencial y cuándo vence la obligación de mantener esta información en secreto.

Lo mejor en estos casos es acudir a un abogado ya que nos proporcionará el asesoramiento legal que necesitamos. De todos modos, si tu empresa está empezando y no tienes recursos para destinar a estos fines, siempre puedes encontrar completas plantillas online que te ayudarán a redactar tu propio acuerdo de confidencialidad. Nosotros te proponemos este modelo, para descargarlo haz click aquí.

Contenido completo en fuente original Nubelo

SO y aplicaciones más vulnerables en 2014

Como hemos reportado a lo largo de todo el año pasado, y según pueden revisar en nuestro resumen de amenazas de 2014, los reportes de vulnerabilidades en sistemas y aplicaciones fueron moneda corriente y pusieron en riesgo la información de muchas empresas y usuarios.

De hecho, se reportó un promedio de 19 vulnerabilidades por día en 2014, según datos de National Vulnerability Database (NVD). Y en base a eso la compañía GFI analizó los principales puntos en común, para evaluar cuáles fueron los sistemas operativos más vulnerables, y concluyó (entre otras cosas) que se trató de Mac OS X.
En total, 7.038 nuevas vulnerabilidades se agregaron a la base de datos de NVD en ese período, lo que constituye un aumento del 65% respecto al número de 2010 (4.258 ). El crecimiento en el número de fallas reportadas creció año a año, y todo indica que seguirá haciéndolo.En cuanto a la severidad, en el 24% de los casos fue alta; y si bien esto constituye un crecimiento en su porcentaje respecto a 2013, el número real ha crecido.

Para entender mejor el tema de la severidad, recordemos que para determinarla se utiliza el sistema CVSS. Para determinar el impacto que representa una vulnerabilidad se utiliza una escala que va del 0 al 10. La severidad se considera baja si el puntaje obtenido luego de aplicar la fórmula CVSS resulta entre 0.0 y 3.9. El impacto es medio si el resultado se ubica entre 4.0 y 6.9. Se considera alto cuando el puntaje cae dentro del rango 7.0 y 10.0.

Y ¿qué hay de las fuentes? En el 80% de los casos se originaron en aplicaciones de terceros, siendo solo en el 13% responsabilidad de sistemas operativos y dispositivos de hardware solo en el 4%.

Pero quizás lo más impactante sea lo relativo a sistemas operativos, como mencionamos más arriba. En resumen, Mac OS X de Apple fue el que más vulnerabilidades registró (un total de 147 en todo 2014) y también el que tuvo el mayor número de vulnerabilidades de severidad alta (64). De esta forma, se posicionó por encima de su "primo mobile" iOS, que registró 127 fallas en todo el año, y superó a distintas versiones de Windows.

Como apunta Cristian Florian en su informe, el 2014 fue duro para los usuarios de Linux en lo que refiere a seguridad, si recordamos casos que aquí reportamos como aquella vulnerabilidad de 5 años de antigüedad que afectaba a la mayoría de las distribuciones del sistema operativo. Radicaba en su kernel y permitía, entre otras cosas, la ejecución de código arbitrario y la elevación de privilegios. Y hacia fin de año nos encontramos con GHOST, otra grave vulnerabilidad de 10 años (en la librería glibc de Linux) que permitiría a un atacante tomar remotamente el control de un sistema sin conocer las credenciales de acceso. Por supuesto, las "célebres" Heartbleed y Shellshock también afectaron a usuarios de Linux, en el primer caso porque afectaba a OpenSSL y en el segundo porque afectaba a GNU Bash.
De este análisis se desprende que Internet Explorer es, de lejos, el navegador más vulnerable del mercado. En la parte de los plugins no se salva ninguno y Flash, Java y Adobe Reader revientan en montones de sitios. Ante eso estamos igual de expuestos los usuarios de Mac OS X y Linux, ventajas de que el malware también sea multiplataforma

Contenido completo en fuente original We Live Security y Security by Default

OWASP Latam Tour 2015 y Training sobre Hacking de Aplicaciones Web

El 10 y 11 de Abril próximos se desarrollará OWASP Latam Tour 2015 en la Patagonia Argentina, evento que se desarrollará de manera simultanea en diferentes países de América Latina.

Desde Segu-Info acompañaremos al capítulo Patagonia de OWASP, creado recientemente.

Agenda de charlas para el viernes 10 de Abril

  • Andres Riancho - Análisis de seguridad en aplicaciones WEB
  • Claudio Caracciolo - El mercado del Malware en las Apps de los Store para Android
  • Cristian Borghello - Certificate Pinning: ¿tenemos el c...ertificado roto?
  • Gustavo Sorondo - Mobile Apps and how to Pentest them
  • Marcelo Campetella - Aspectos Legales de la Seguridad informática
  • Mauro Graziosi - CIOs vs CISOs: OWASP al rescate

Training para el sábado 11 de abril

  • Cristian Borghello - Hacking de aplicaciones web basado en OWASP Top 10 - Este evento requiere inscripción previa.

Lugar

Ubicacion.png

Más información en la Web de OWASP Patagonia

SoloE de la Redacción de Segu-Info

2 de mar. de 2015

JetLeak: como revelar las últimas peticiones hechas a servidores Jetty

Según un reciente análisis realizado por el investigador Stephen Komal de Gotham Digital Science, existe una vulnerabilidad en el servidor Jetty que puede permitir extraer información sensible del sistema. Se ven afectadas las versiones 9.2.3 a la 9.2.8 y la rama 9.3.x beta

Jetty es un servidor Web y contenedor de 'servlets' basado en Java. Se distribuye y usa en entornos de desarrollo como Eclipse, o multitud de servidores de aplicaciones como JBoss, Apache Geronimo, Google GWT o App Engine entre otros.

La vulnerabilidad JetLeak (CVE-2015-2080) se debe a una incorrecta implementación de las peticiones realizadas al módulo 'HttpParser' a la hora de gestionar en detalle los eventos de error. Debido a esto, una petición especialmente manipulada conseguiría recabar los últimos 16 bytes del búfer compartido de peticiones, dentro de la respuesta HTTP 400. Lo que llevaría a mostrar por tanto información sensible como Cookies, credenciales, correos y diversa información del sistema.

Si entramos en detalle en la vulnerabilidad, una petición realizada a un servidor ya actualizado y que generara un error al utilizar caracteres incorrectos (no ASCII por ejemplo), debería dar una respuesta HTTP 400 similar a ésta:

HTTP/1.1 400 Illegal character 0x7
Content-Length: 0
Connection: close
Server: Jetty(9.2.9.v20150224)

Mientras que en un servidor vulnerable, ante esa misma petición especialmente manipulada daría como resultado el volcado del buffer en la misma respuesta, de la siguiente manera:
HTTP/1.1 400 Illegal character 0x7 in state=HEADER_IN_NAME in 'GET
/dummy/ HTTP/... localhost\nCoo\x07<<>>e:
application/x-...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Content-Length: 0
Connection: close
Server: Jetty(9.2.8.v20150217)

Como podemos comprobar, se concatena información del buffer de 'debug' y cualquier script modificado para realizar múltiples conexiones al servidor podría ir recabando todo tipo de información sobre las últimas peticiones hechas.

Se ha facilitado un script para comprobar los servidores afectados: https://github.com/GDSSecurity/Jetleak-Testing-Script

Se recomienda actualizar lo antes posible a la versión 9.2.9.

Fuente: Hispasec

MegaNet y otras "Internet descentralizadas"

El famoso empresario Kim Dotcom (Kim Schmitz), creador del desaparecido Megaupload y del nuevo servicio MEGA, quiere comenzar su propia Internet que utiliza el mismo principio de "blockchain" de Bitcoin.

El mes pasado Kim Dotcom lanzó la beta pública de su vídeo y audiochat con cifrado end-to-end llamado "MegaChat", que dice dar mayor protección que Skype y Google Hangouts.

Ahora se refirió a la supuesta "MegaNet" que sería inmune a la vigilancia masiva global llevada a cabo por gobiernos o empresas y no estaría basado en direcciones IP. MegaNet sería una red descentralizada, basada en blockchain usado por Bitcoin.

Este movimiento podría ofrecer a los usuarios un espacio verdaderamente libre, donde pueden comunicarse en privado con otra persona sin censura. Además, esta red podría aprovechar el almacenamiento y ancho de banda ociosa de los teléfonos móviles para convertir esa capacidad ociosa en una nueva red.

MAIDSAFE: otra Internet descentralizada

MaidSafe (Massive Array of Internet Disks) creada por David Irvine en 2008, garantiza acceso a Internet para todos, es un programa de código abierto (alojado en GitHub) y permite una plataforma de Internet descentralizada.
La parte clave de MaidSafe es su red segura, alimentada por las computadoras de sus participantes: en lugar de servidores especializados, los datos son almacenados y distribuidos por una red de computadoras conectadas a Internet.

Cualquiera que ejecute MaidSafe pasará a formar parte de la red segura. El sistema MaidSafe convierte todos los dispositivos conectados en nodos de una red segura que colectivamente almacenan datos para todos los usuarios de MaidSafe.

El almacenamiento de datos es descentralizado, lo que significa que una aplicación web utilizando MaidSafe no almacena datos de sus usuarios en un servidor central, más bien los datos se propagación a través de muchos discos y dispositivos gestionados por los distintos usuarios de MaidSafe. Por lo tanto, no hay nadie, ni una persona natural o jurídica que pueda obtener una copia intacta de los archivo de un usuario.

Proyecto Maelstrom: red P2P para sitios web

Al final del año pasado, BitTorrent anunció que es "el primer paso hacia una web verdaderamente distribuida, que no depende de servidores centralizados".

Según BitTorrent, el navegador distribuido podría ayudar a mantener una Internet más neutral. Si no se puede identificar el ISP donde se origina el tráfico, entonces no se puede suprimir ciertos sitios accedidos desde un navegador como Maelstrom.

ZeroNet: Hosting usando la red de BitTorren

A principios de año nuevo, nació un nuevo proyecto de código abierto conocido como ZeroNet, que pretende ofrecer una plataforma web descentralizada usando la criptografía Bitcoin y la red BitTorrent.
ZeroNet utiliza una combinación de BitTorrent una web, un servidor de archivos personalizado y una interfaz de usuario para proporcionar anonimato al dueño de un sitio web.

Fuente: HackerNews

Publicado Firefox 36 con soporte para HTTP/2

Mozilla ha publicado Firefox 36 que soluciona tres fallas críticas y seis fallos de alta severidad.
De los fallos críticos, los atacantes podrían potencialmente lanzar ataques dirigidos contra el reproductor de video MP4 a través de un desbordamiento de búfer en la biblioteca de libstagefright (MFSA2015-17 - CVE-2015-0829). Otro fallo potencial explotable recide en la manpulación del contenido de IndexedDB (CVE-2015-0831).

La tercera vulnerabilidad corresponde a un grupo de bugs en el manejo de memoria MFSA2015-11 (CVE-2015-0836 y CVE-2015-0835).

Las vulnerabilidades de alta severidad incluyen la habilidad para obtener información desde la función de "autocompletar" almacenados en rutas locales conocidas; una oportunidad de ejecutar malware a través de la actualización y la capacidad para acceder a scripts del navegador mediante la creación de MP3s dudosos.

La nueva versión del navegador también añade soporte HTTP2, recientemente aprobado.

Fuente: Register

Aprobado HTTP/2: el mayor cambio de Internet desde 1999

Siempre estamos hablando de productos revoluciones y servicios que prometen cambiarnos la vida, pero si de verdad hay un gran cambio en ciernes es la llegada del protocolo HTTP/2 (Hypertext Transfer Protocol version 2 - draft-ietf-httpbis-http2-17).
Para decir más, se trata del mayor cambio en Internet desde 1999 y supondrá una mejora considerable a la hora de navegar, haciendo que las páginas web carguen más rápido o no se colapsen ante un aluvión de visitas. Vamos a repasar de donde venimos y hacía donde vamos en relación a este protocolo.

HTTP es el estándar fundamental que nos permite navegar por Internet y no ha recibido cambios desde 1999, es decir, que estamos usando tecnología de hace 16 años a diario. Como no podía ser de otra forma, esto tiene algunos inconvenientes después de tanto tiempo y ya era necesaria la adopción de un nuevo estándar. La versión 1.1, que usamos actualmente, ha realizado un buen servicio pero ya va siendo hora de que la dejemos descansar.

El nuevo estándar, conocido como HTTP/2 ha sido completado con éxito, aprobado por el comité IESG de IETF y ha comenzado su periplo para ser publicado oficialmente en poco tiempo. Realmente, se trata de una mejora sustancial que notaremos cuando naveguemos por Internet, siendo el mayor cambio desde la mencionada versión de 1999. Este estándar aporta mejoras a la Web como la carga más rápida de páginas, conexiones activas durante más tiempo o mejor manejo en casos de muchos accesos simultáneos a una página.

Este estándar aporta mejoras a la Web como la carga más rápida de páginas. HTTP/2 utiliza los mismos parámetros que la versión actual con la que están familiarizados los desarrolladores, pero añade más funciones adicionales que se pueden implementar. Una de las que más se destacan es el hecho de que una página web no se bloquee al recibir muchas conexiones al mismo. Además, el nuevo estándar supone una carga menor para los servidores. La seguridad también es superior en esta nueva versión. En esta web podemos ver las 9 cosas que esperar de este protocolo.

¿Qué es HTTP/2.0?

  • es un protocolo binario, en vez de textual;
  • es completamente multiplexado, en lugar de ordenado y con bloqueos;
  • puede utilizar paralelismo;
  • usa compresión de cabecera para reducir la sobrecarga;
  • permite que los servidores realizar "server push" de las respuestas proactivamente
El protocolo ha sido completado pero aún debe publicarse, por lo que tardemos un poco en tenerlo disponible. Después, los desarrolladores podrán comenzar a implementarlo para que todos podamos disfrutar de sus beneficios. HTTP/2 se puede probar en Mozilla Firefox y Google Chrome utilizando el identificador "h2-14" según nos indican en las FAQ oficiales.

De hecho, Google ha optado por adoptar este protocolo en lugar del suyo propio conocido como SPDY. Como ya os contamos hace algunos días, las próximas versiones añadirán soporte nativo para HTTP/2 coincidiendo con su aprobación como el nuevo estándar para la Red. De esta forma, los usuarios no tendremos que hacer nada para adaptarnos a esta nueva realidad.

Ya hay varios proveedores y sitios que han comenzado su implementación, tales como Akamai, Google y Twitter.

Fuente: ADSLZone y HTTP2