Cybersecurity Shot_Fuga de información del Partido Demócrata de EEUU

miércoles, 31 de agosto de 2016


¡Esta semana os traemos un nuevo caso real sobre fuga de información! Cybersecurity Shotes un tipo de informe de investigación elaborado por nuestro equipo de expertos analistas, sobre casos de actualidad relacionados con bases de datos filtradas en la red, así como algunas recomendaciones que podrían haberlo evitado.

Aquí os dejamos un breve resumen del último caso analizado:

Caso Comité de Campaña Demócrata del Congreso de EEUU
Investigación "Fuga de información del Comité de Campaña Demócrata del Congreso de EEUU"

El pasado 12 de agosto el Comité de Campaña Demócrata del Congreso de los EEUU sufrió un incidente de seguridad al hacerse público 7 documentos de diferente naturaleza. Entre la información filtrada fueron publicados datos de carácter corporativo y personal de 193 miembros de la cámara de los Representantes, así como, otra serie de documentos donde aparece información interna del partido y credenciales de acceso a plataformas usadas por diferentes miembros y altos cargos del Partido Demócrata de EEUU. El supuesto autor de la filtración Guccifer 2.0 divulgó el contenido en un blog de wordpress.com, el cual fue retirado al día siguiente.

La información expuesta parece ser verídica, ya que se tiene constancia de un incidente de seguridad que habría afectado a la privacidad de la líder de la minoría demócrata de la cámara de Representantes, según confirma la CNBS.

Debido a la naturaleza de los perfiles expuestos, el equipo de analistas de ElevenPaths recomienda realizar un diagnóstico de la actividad en la totalidad de las cuentas divulgadas, ya que las cuentas de carácter personal, podrían ser utilizadas para geolocalizar a los usuarios de las mismas mediante los servicios de tracking con las implicaciones de seguridad que ello conlleva, dado el alto perfil de muchos de los afectados.

Descubre más detalles de este fuga de datos en el Informe elaborado por nuestros analistas de inteligencia.

» Descárgate el caso Fuga de información del Comité de Campaña Demócrata del Congreso de EEUU

No te puedes perder el próximo:
» Caso Delta-Stresser.xyz

¿Quieres saber más sobre Ciberseguridad? Sé el primero en enterarte de todo lo que está pasando en la industria. ¡Suscríbete a nuestra Newsletter CyberSecurity Pulse!

Además, nuestro equipo de analistas te esperan en la Comunidad Técnica de ElevenPaths para resolver dudas, comentar la actualidad y compartir experiencia y curiosidades.

Más información en
Elevenpaths.com

ElevenPaths Talks: ¿Hacia dónde evolucionan los APT?

martes, 30 de agosto de 2016






El próximo jueves 1 de Septiembre un invitado especial de Eleven Paths impartirá una charla en la que se hablará sobre la evolución de los APT, Advanced Persistent Threat, y las precauciones que debemos tener. En esta charla se podrán conocer las principales técnicas de las amenazas persistentes avanzadas, lo cual no dejará indiferente a nadie. 

La duración de la charla será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.
Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 1 de Septiembre a las 15.30h (Madrid)Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.

Más información en:
talks.elevenpaths.com

La increíble historia de Firefox y el certificado raíz de la FNMT

lunes, 29 de agosto de 2016

Firefox 49 incluirá el certificado raíz de la FNMT tras ocho años esperando… o al menos eso parece. Muchas páginas oficiales de organizaciones gubernamentales españolas utilizan un certificado expedido por la Fábrica Nacional de Moneda y Timbre. Internet Explorer y Chrome utilizan el mismo repositorio de certificados raíz (el del sistema operativo) mientras que Mozilla tiene su propio criterio más restrictivo para incluir certificados en los que confía. Desde 2008 se intentaba que el certificado raíz de la FNMT cumpliera los requisitos para navegar sin alertas. ¿Qué ha pasado durante todo este tiempo? ¿Por qué no se incluía? Este mes la discusión ha llegado a un acuerdo y parece que se incluirá en la versión 49 (que ya está en beta)… pero no es seguro todavía.

Esto es lo que ven los usuarios cuando se conectan a muchas páginas de organismos oficiales en España


Para muchos usuarios de Firefox, utilizar cualquier certificado emitido por la FNMT ha supuesto un incordio durante muchos años. Esto en el mejor de los casos (que conocieran qué estaba pasando en realidad) puesto que se solucionaba instalando el certificado raíz en el navegador o añadiendo la excepción. Para los que no fueran conscientes de esto, simplemente obtendrían un mensaje que probablemente les hiciera pensar en algún tipo de espionaje o malware alojado en su equipo. El problema se conoce de siempre, y ya en 2008 se pidió en Bugzilla que se resolviera. Pero el certificado raíz de la FNMT no cumplía con la política de inclusión de Firefox. ¿Qué ha pasado en este tiempo?

Desde 2008

Mensaje inicial de petición para incluir el certificado

En mayo de 2008 se inicia la petición oficial. Por aquel entonces Firefox 3 estaba a punto de salir, y se valoraba (ingenuamente) la posibilidad de incluir ya el certificado en él. En octubre, se quejan del problema varios usuarios explicando que es muy necesario para decenas de gestiones online en España. Kathleen Wilson de la fundación Mozilla se encarga desde entonces de las gestiones para conseguir que el certificado pase las pruebas… y comienza el calvario.

Durante 2009

El primer análisis del certificado ya en 2009 encuentra muchos problemas. Su clave es de 1024 bits. Debe contar con un CRL público para revocaciones, se debe asegurar de que no se emiten CAs subordinadas con él, se debe comprobar que cada dominio para el que se emite corresponde a su dueño, y pasar una serie de auditorías realizadas por empresas independientes… entre otras condiciones. Algunos puntos se aclaran con una simple respuesta en Bugzilla, otros comienzan a dar problemas en los que Firefox no cede. Entre respuesta y respuesta, pueden pasar semanas o meses. La tensión se palpa y la comunidad española de Mozilla calcula el tiempo entre respuestas para recriminar quién tarda más en contestar o tomarse en serio el asunto (si Mozilla o la FNMT).

"Even if 131 days is proof that Mozilla needs reviewing his process to get CAs accepted, the 240 days delay by FNMT, 180 days without a single commment, is completely unacceptable.". 

Mozilla pide que un representante de la FNMT, no la comunidad, realice a partir de entonces ciertas gestiones. Estamos ya en junio de 2009. El representante aparece en octubre y se hace cargo hasta hoy.

Primeras quejas en 2009

2010

"Please move this. We all Spaniards need these certificates", se puede leer entre la discusión. Kathleen llega a 2010 con problemas menores y continúa con preguntas y necesidades no cubiertas para entrar en el club de certificados raíz de Mozilla. En este punto, es la propia FNMT la que retrasa el proceso por no cumplir ciertas especificaciones técnicas.

"To all Spanish users: please, don't add noise to this bug. Most of the delay in this process is due to FNMT (see comment #18), so distracting Mozilla staff from other tasks doesn't help at all. Instead, ping FNMT staff (in an educated manner, please!!) through their web contact form"

En febrero de 2010, la FMNT pide desbloquear la situación, porque cree ya haber aportado todo lo necesario. Mozilla se queja de textos en español, y que no puede copiarlos y pegarlos por ser PDFs protegidos. La comunidad los traduce por ellos, pero hay otros problemas con OCSP e incomprensibles laberintos burocráticos y de responsabilidades añadidos a problemas técnicos.

De 2011 a 2014

Llega 2011 y comienza el proceso de auditoría. Una empresa técnica debe emitir un informe, que es validado por ASIMELEC (Asociación Multisectorial de Empresas de Tecnologías de la Información, Comunicaciones y Electrónica). Una vez completada buena parte de la burocracia y resueltos muchos problemas, el proceso pasa a "discusión pública" en Mozilla, una maniobra que debe esperar una cola que va por orden, y en la que hay que esperar literalmente semanas para escalar cada puesto. Llega a discusión pública en febrero 2012. Pero ahora es necesario volver a validar los documentos anteriores y corregir nuevos bugs. Falta la versión actualizada del CPS (Certificate Practice Statement). Las conversaciones se dilatan. Pasan meses entre respuestas. Los usuarios se cansan de protestar. Estamos en 2014 y Kathleen todavía espera a algunos representantes a que respondan ciertas dudas y preguntas.

Cada parte tarda en responder ante cada duda o documento solicitado
Ya en 2015

Comienza una discusión sobre qué bits se quieren activar en el certificado (Websites, Email, Code Signing) y la necesidad de obtener nuevas auditorías externas y demostrar que se han seguido ciertos criterios de estándares. La FMNT cree que muchos requerimientos se solapan entre ellas y que no todos son necesarias. Siguen problemas técnicos con OCSP. Una ver recopilados los documentos y resueltas ciertas dudas, el proceso pasa a "discusión pública" de nuevo en Mozilla en octubre de 2015. 

En este 2016

Se solucionan problemas menores de nomenclatura. Existen conflictos entre la ley española y la exigencias del cabforum.org (CA/Browser forum, entidad que fija los estándares de interacción entre estas entidades). Hasta que finalmente en un mensaje de Kathleen el 11 de agosto de 2016

Mensaje que recomienda cerrar el fallo y aprobarlo

... se recomienda el cierre de la discusión y la aprobación "del fallo", lo que implica que posiblemente en sucesivas versiones se incluya el certificado, si todo va bien.

¿Conclusiones?

Muchas. Es posible que la nueva versión 49 incluya el certificado, aunque la versión beta, firmada el 22 de agosto, no lo hace.

La versión beta, fechada el 22 de agosto, no contiene el certificado todavía
 Con respecto a los problemas burocráticos, una buena parte se resume en esta entrada de Bugzilla.

Resumen de la situación
 
Pero por otro lado: 
  • El proceso de inclusión de certificados en Firefox es engorroso de por sí. Unido a que lo emita una organización gubernamental (ya engorrosa en la gestión de todos sus procedimientos de por sí) probablemente ha influido bastante en que este proceso haya durado 8 años. 
  • La organización de Mozilla tampoco es especialmente ágil. Manejan sus propios tiempos y prioridades.
Pero la reflexión puede ir un poco más allá. ¿Están justificadas las reticencias de Mozilla? Han seguido estrictamente un protocolo de seguridad y calidad que garantiza un mínimo más que aceptable y esto es muy positivo, pero en la práctica, ¿de qué ha servido? Los usuarios no han podido utilizar su navegador para innumerables gestiones durante años y, si el fin era proteger, realmente durante este periodo han protegido de poco al usuario, puesto el certificado ya está incluido en Windows al menos para Chrome e Internet Explorer. El sistema ya confía en él.

¿Y si durante este tiempo el certificado hubiera sido comprometido o se hubiera utilizado ilegítimamente? Esto es uno de los objetivos del duro proceso establecido por Mozilla: evitar que ocurra o mitigar el problema si finalmente pasa… ¿Habría llevado razón Mozilla al no haber confiado en él? Es posible, pero realmente no hubiera marcado la diferencia, puesto que los usuarios ya saben que no se puede utilizar Mozilla para ciertas gestiones y hubieran acudido a otro navegador que no les hubiera protegido de un mal uso de ese certificado.

Los certificados ya se encuentran en el repositorio de confianza de Windows

¿Significa esto que Mozilla debe relajar sus condiciones e incorporar los mismos certificados del sistema en su propio repositorio? No, porque efectivamente, en el sistema existen varias CA que el usuario probablemente no utilizará jamás (organizaciones gubernamentales de países totalmente ajenos, por ejemplo… puedes comprobarlo con SSLCop) y que es un problema conocido desde hace tiempo… No, Mozilla no tiene por qué replicar tal cual o usar el repositorio del sistema operativo (como hace Chrome) pero al menos quizás sería sensato haber llegado en este caso a un acuerdo de compromiso.

Es loable seguir unas normas que elevan el listón, pero también buscar alternativas si tardan 8 años en aplicarse. Sobre todo si durante el proceso se gana poco o nada en seguridad a efectos prácticos. ¿Dónde está el límite en el que se debe insistir en resolver los estrictos procedimientos pero mientras se resuelven, los usuarios se mantienen descontentos y alejados de la propia protección que se les quiere proporcionar?

Por último, esto no deja de ser otra demostración de que el modelo TLS tradicional de CAs necesita cambios urgentes que lo simplifiquen, agilicen y lo hagan más robusto. Las diferentes iniciativas de Certificate pinning son una consecuencia de estos cambios. Por cierto, que la FNMT no utiliza ni HSTS ni HPKP.


Sergio de los Santos
ssantos@11paths.com

[Nuevo informe] "Ciberamenazas Sector Financiero Q2 2016" elaborado por Kaspersky Labs y Telefónica

jueves, 25 de agosto de 2016




Ya está disponible el nuevo informe sobre Ciberamenazas en el sector Financiero correspondiente al segundo trimestre de 2016 elaborado conjuntamente por Kaspersky Labs y nuestro equipo de expertos analistas.

Este informe analiza las tendencias actuales relacionadas con el phishing financiero y el malware bancario, incluyendo ataques contra dispositivos móviles, sistemas de Puntos de Venta (POS) y cajeros automáticos (ATMs). El informe se basa fundamentalmente en estadísticas y datos de KSN (Kaspersky Security Network) en el que también se han utilizado datos e información fiable de otras fuentes. Los datos para la elaboración de este análisis fueron obtenidos entre el 1 de abril de 2016 y el 1 de julio de 2016.


» Descárgate el informe completo “Ciberamenazas Sector Financiero Q2 2016″.

*También te puede interesar:
Más información en:
elevenpaths.com

Cybersecurity Shot_Fuga de Información de MUPOL

miércoles, 24 de agosto de 2016


Como cada semana os presentamos Cybersecurity Shot, un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red, así como algunas recomendaciones que podrían haberlo evitado. Cada entrega con un caso real. ¡No te lo puedes perder!

Aquí os dejamos un breve resumen de este caso:

Caso MUPOL

Investigación "Fuga de información de MUPOL"

El pasado 31 de mayo bajo el alias @FkPoliceAnonOps, se publicó un tweet donde se indicaba que se había visto comprometida la seguridad de la Mutualidad de Previsión Social de la Policía, entidad dedicada a la creación de planes de ahorro para personal adscrito a la Dirección General de la Policía Nacional.

Descubre con nuestros analistas de inteligencia cuál ha sido la técnica empleada por el presunto delincuente para la difusión de la información robada.

» Descárgate el caso fugas de información de MUPOL

No te puedes perder el próximo:
» Caso Partido Demócrata de EE.UU

Más información en
Elevenpaths.com

ElevenPaths Talks: Metodologías de desarrollo seguro (Secure SDLC)

martes, 23 de agosto de 2016






El próximo jueves 25 de agosto nuestro compañero Diego Samuel Espitía impartirá una charla en la que se hablará sobre Metodologías de desarrollo seguro (Secure SDLC). En esta charla se podrán conocer las técnicas que se integran con el ciclo de vida de desarrollo de software que durante años han utilizado las empresas para fortificar y securizar el proceso. Hoy en día es vital para la calidad y seguridad del software integrar este tipo de metodologías, ya que cuanto antes se detecten las vulnerabilidades menor coste asociado en el desarrollo del producto.

La duración de la charla de Diego Samuel será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.
Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 25 de agosto a las 15.30h (Madrid)Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.

Más información en:
talks.elevenpaths.com

Nuevo plugin inteligente para FaasT: HPKP y HSTS

lunes, 22 de agosto de 2016



Desde nuestro laboratorio se ha creado un nuevo plugin para FaasT que comprueba de forma inteligente la tecnología HSTS y HPKP no solo evaluando la presencia de estas cabeceras, sino su correcta implementación, aportando además sugerencias sobre cómo mejorarlas. Este nuevo plugin viene a reforzar a FaasT como el escáner de pentesting persistente más avanzado e innovador.

Tres años después, FaasT sigue evolucionando con más y mejores Plugins, cada vez más inteligentes y completos. Ahora FaasT evalúa de forma inteligente no solo la presencia de cabeceras HSTS y HPKP en las páginas analizadas, sino que además realiza comprobaciones que permiten conocer hasta qué punto su configuración es la adecuada y están cumpliendo su misión.

HSTS

El protocolo HTTP Strict Transport Security (HSTS) permite transformar las peticiones HTTP en HTTPS desde el propio navegador. Si un servidor decide enviar cabeceras HSTS a un navegador, cualquier visita posterior de ese navegador al dominio, será convertida automáticamente y de forma transparente a HTTPS desde el propio navegador, evitando así peticiones inseguras desde el mismo punto de partida de la conexión. La aplicación del protocolo HSTS es transparente al usuario, es decir, los navegadores son los encargados de recordar los dominios que le han indicado por HSTS durante cuánto tiempo deben ser visitados por HTTPS y gestionan el cambio sin que el usuario deba preocuparse de nada. En el caso de Firefox, es posible utilizar nuestro addon PinPatrol para comprobar tanto la información HSTS como HPKP. El dominio transmite la información de HSTS al navegador a través de la cabecera Strict-Transport-Security. En esta cabecera se facilitan tres campos más: max-age, includeSubdomains y preload (opcional).

Un ejemplo de cómo se muestra información sobre HSTS en el panel de FaasT


Pero no solo la presencia o ausencia de esta cabecera es determinante. La correcta configuración y combinación de sus diferentes campos, además de bajo qué circunstancias y dominios se emiten, determinan la seguridad total del conjunto. El plugin de FaasT tiene en cuenta recomendaciones presentes en el RFC definido, además de otras propias basadas en descubrimientos de nuestro propio laboratorio, y que constituyen errores típicos que merman la seguridad proporcionada teóricamente por la cabecera.

HPKP

La idea detrás del certificate pinning reside en poder detectar cuándo una cadena de confianza ha sido modificada. Para ello se busca asociar (habitualmente, en el navegador) inequívocamente un certificado digital a un dominio concreto (se recuerda certificados presentes en una cadena de certificación y se avisa ante cualquier alteración). El pinning se puede realizar desde el lado del cliente o servidor o con la colaboración de ambos, como es el caso de la solución HPKP. Este protocolo HTTP Public Key Pinning (HPKP) define una nueva cabecera HTTP (Public-Key-Pins) en la que el dominio envía información al navegador sobre sus certificados y política de pinning.

Un ejemplo de esta cabecera podría ser:

Public-Key-Pins:
pin-sha256="d+Nzzj/kBbW36XgzHd3iQz7lzmMFM7UedINRmVf+ie4=";
pin-sha256="U7ZybtJ2wCBeg7QSvWZppKSa06gOYkSCIZkaR2ft3DM=";
pin-sha256="JNFyeZHEFDpGO41RvpVRuQY1Oi19xtLFeF99j0EYduE=";
max-age=15768000; includeSubDomains

En esta cabecera se facilitan distintas directivas: pin-sha256, max-age., includeSubdomains y report-uri (opcional).

Igualmente, el correcto uso de estas cabeceras determinará la seguridad de la implementación: Los pines proporcionados deben ser los correctos representando la cadena de certificación la entidad adecuada con la criptografía más robusta. Además, el pin de respaldo debe estar presente y a ser posible no encontrarse firmado … estas son algunas de las recomendaciones evaluadas por el plugin de FaasT.

Un ejemplo de cómo se muestra información sobre HPKP en el panel de FaasT


Conclusiones

No solo la evaluación debe ser persistente sino también inteligente. La mera presencia de cabeceras web, por ejemplo, no garantiza la seguridad. Es necesario evaluarlas y comprobar que cumplen su misión. El plugin de HSTS y HPKP para FaasT (en constante evolución) no solo recordará a los administradores que es necesaria su implementaición, sino que recomendará la mejor manera de hacerlo.

Cybersecurity Shot_Fuga de Información de Comelec

viernes, 19 de agosto de 2016


Cybersecurity Shot es un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red así con algunas recomendaciones que podrían haberlo evitado.

Cada entrega trae un caso real. ¡No dejes que te lo cuenten!

A continuación puedes leer un breve resumen de esta investigación:

Caso COMELEC
Investigación "Fuga de información de Comelec"

El 27 de marzo de 2016, la página gubernamental encargada del censo electoral de la República de Filipinas fue hackeada durante unas horas. En la web únicamente aparecía un mensaje reconociendo la autoría por parte del grupo Anonymous Philippines.

Los atacantes manifestaban la necesidad de implementar una mayor seguridad en los sistemas Precinct Count Optical Scan, encargados del conteo y validación de los votos para evitar un posible fraude electoral en las próximas elecciones generales del país.

Descubre con nuestros analistas de inteligencia cuál fue el proceso que se llevó a cabo para identificar la filtración en la red, así como el nivel de sensibilidad de la información que afectó a 55 millones de electores filipinos.

» Descárgate el caso fuga de información de Comelec


No te puedes perder el próximo:
» Caso MUPOL

Más información en
Elevenpaths.com

[Nuevo informe] "Tendencias en vulnerabilidades del primer semestre de 2016"

jueves, 18 de agosto de 2016




El equipo de analistas de ElevenPaths te actualiza sobre las tendencias en vulnerabilidades. Descárgate esta nueva edición del informe donde te traemos el análisis correspondiente al primer semestre de 2016, elaborada por el equipo del Servicio de Vamps (Persistent Vulnerability Assessment & Management) de ElevenPaths. En este informe se analizaron los datos de más de 100 compañías representativas de los principales sectores de actividad y con un alcance global.

Éstas son algunas conclusiones obtenidas de la investigación:
  • Existe una falta de cuidado en la gestión de información que es accesible desde Internet.
  • El origen de la mayoría de errores se debe a malas prácticas por parte de los administradores de los sistemas.
  • La inyección de comandos y XSS continúan siendo un grave problema que afecta al desarrollo de software de las propias compañías y de terceros.


Las empresas han sufrido una clara orientación al mundo digital e internet, lo que también incluye la aparición de nuevas amenazas contra sus sistemas para acceder a unos de sus activos más valiosos: la información. Ser competitivo hoy en día requiere utilizar multitud de tecnologías heterogéneas, cambiantes y complejas de gestionar.

El objetivo de este informe es mostrar, desde diferentes puntos de vista, las vulnerabilidades actuales presentes en activos reales. Mediante la comparación con informes de tendencias previos, se pretende mostrar las últimas tendencias en vulnerabilidades e indicar a las compañías dónde deben poner foco en la corrección para mantener un adecuado nivel de seguridad.



*También te puede interesar:

Más información en:

Metashield for Exchange – El Control Absoluto

miércoles, 17 de agosto de 2016


Si hace poco comentábamos las ventajas de usar el innovador Metashield for Outlook 365 ahora vamos a hacer lo propio con otra de las novedades más importantes en el tratamiento y gestión de metadatos en el otro gran escenario de correo dominado por Microsoft®, Exchange Server.

Ya veníamos desde hace tiempo dándole vueltas a una solución que fuera capaz de ofrecer la máxima cobertura y de manera silenciosa, para no interferir en los quehaceres diarios y fruto de ello surgió Metashield for Exchange, una potente solución para el entorno de correo sobre servidores Exchange, con una característica que lo diferencia significativamente de otras soluciones y es su transparencia de uso.
Hace unos meses dejamos entrever algunos detalles de su diseño y procesos internos, pero esto ya se ha convertido en realidad.

Responsabilidad
El mayor problema al que se enfrentan las organizaciones cuando quieren aplicar políticas de seguridad preventiva es que estas puedan incorporarse de forma inmediata, sin interrupciones y con un impacto mínimo en el desarrollo habitual de sus actividades. 
Cumplir con estos objetivos se vuelve complejo cuando muchas de las soluciones requieren de la participación de los usuarios en el proceso. En algún momento este eslabón puede fallar poniendo en riesgo la integridad de la organización.

¿Cómo evitamos que el usuario cargue con esta responsabilidad?
Simplemente prescindiendo de él, metafóricamente hablando, no es necesario cargarse a nadie. Evitando su intervención eliminamos los riesgos derivados. Metashield for Exchange se instala On-premises administrándose desde el mismo servidor o apoyándose en la Consola de Gestión Metashield, protegiendo los buzones de Exchange Server, así de simple.

Listas blancas
Una de las características que más llama la atención, es la posibilidad de generar listas blancas con dominios, cuentas de correo o cadenas de texto, con el fin de no procesar los metadatos sobre los correos que contengan esta información. Esto es elemental porque evitamos tratar archivos internamente facilitando su indexación y solamente procesarlos cuando circule y no se ajuste a nuestras directrices de seguridad y logicamente cuando su destino esta fuera del control de la organización. 




Buzones a la carta
Otro detalle a destacar es la distribución de su uso. Si bien una empresa puede tener n buzones, es muy probable que no esté interesada en cubrir todos. Como ocurre la mayoría de las veces el número de cuentas es mayor al número de usuarios reales. Solo se marcarán aquellas cuentas aptas para su registro y podrán redistribuirse a medida que surjan cambios según las necesidades de la organización.


Todo automatizado y transparente
A partir de aquí todo son beneficios, la organización controla la información que sale de su control y elimina la amenaza persistente por su canal de correo, protegiendo su información, reputación y cumpliendo perfectamente con la legislación relativa a la protección de datos personales.
A nivel usuario la experiencia es la misma, los usuarios no percibirán cambios en la usabilidad de sus buzones de correo, pero en el nivel de seguridad se produce un salto exponencial, erradicando totalmente la fuga de información por este medio. Si a esto le añadimos la oportunidad de poderlo gestionar con la Metashield Management Console nos aportará aparte de las prestaciones que esta conlleva, un reporte grafico-estadístico de los procesos, en definitiva, un control absoluto.

Desde cualquier ubicación, desde cualquier dispositivo, si nuestro correo pasa por un servidor Exchange con Metashield ya nos podemos olvidar de los riesgos de fugas de datos sensibles y sus desafortunadas consecuencias.


Antonio Bordón Villar
antonio.bordon@11paths.com

Eleven Paths Talks: Los 10 principales controles de seguridad que no pueden faltar en la empresa

martes, 16 de agosto de 2016



El próximo jueves 18 de agosto nuestro compañero Leandro Bennaton impartirá una charla en la que se hablará de los estándares y estudios más importantes, sobre los controles de seguridad, todo esto desde la visión de un CISO (Chief Information Security Officer) experimentado en este campo.

La duración de la charla de Leandro será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.

Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 18 de agosto a las 15.30h (Madrid)Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.

Más información en:
talks.elevenpaths.com



Cybersecurity Shot_Fuga de Información de Seven Dollar Click

lunes, 15 de agosto de 2016



Cybersecurity Shot es un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red así con algunas recomendaciones que podrían haberlo evitado.

Aquí te dejamos un breve resumen del caso de esta semana:

Caso Seven Dollar Click
Investigación "Fuga de información de Seven Dollar Click"

La plataforma de pago por visionado de vídeos de publicidad SevenDollarclick.com se vio afectada el 12 de julio por una fuga de información, al hacerse públicas las credenciales de más del 98% de sus usuarios. Junto a ella, se encontraron las filtraciones de las páginas web FourDollarClick.com y ThreeDollarClick.com. 

El nombre del autor que aparece en la filtración es el alias de Sonny, actor que se asocia a la cuenta de Twitter @SonnySpooks, en donde muestra un alto conocimiento en técnicas de pentesting, así como capturas de pantalla de servicios web vulnerados por parte del alias SonnySpooks.

Aunque existen plataformas Pay To Click legítimas que explotan un modelo de negocio basado en la publicidad en internet, actuando como intermediarios entre anunciantes y usuarios finales, también se dan casos de páginas que utilizan esta forma de obtención de dinero rápido como reclamo para otras prácticas de uso delictivo. 


¿Quieres saber la opinión de nuestros expertos? ¡Descárgate la investigación completa!


No te puedes perder el próximo:
» Caso Edaboard.com

Más información en

Cybersecurity Shot_AEDyR information leakage

viernes, 12 de agosto de 2016


Here comes Cybersecurity Shot_, a research report on current cases related to databases leaked online that includes leak prevention recommendations. You can’t miss out on it!

Here is a brief summary of the report:

AEDyR Case
Investigation research “AEDyR information leakage”

On April 7, 2016, a security breach occurred in the Spanish Desalination and Reutilization Association. Due to an SQL injection attack on its web page, information about partners and companies belonging to AEDyR was disclosed.

The list of affected is quite extensive and includes companies from different sectors related to the water treatment and infrastructures. Amongst the leaked information there is a large amount of corporate credentials of people related to these sectors.

Learn from our intelligence analysts what attribution exercise was accomplished, as well as the alleged perpetrator’s former collaboration with other hacktivist groups.

» Download AEDyR information leakage case


Don't miss the next:
» Caso Comelec

More information at
Elevenpaths.com

Cybersecurity Shot_Fuga de Información de AEDyR


Cybersecurity Shot es un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red así con algunas recomendaciones que podrían haberlo evitado.

Cada entrega trae un caso real. ¡No dejes que te lo cuenten!

A continuación puedes leer un breve resumen de esta investigación:

Caso AEDyR
Investigación "Fuga de información de AEDyR"

El 7 de abril de 2016, se produjo una brecha de seguridad en la Asociación Española de Desalación y Reutilización. Debido a un ataque de SQL injection en su página web fue extraída información acerca de socios y empresas pertenecientes a AEDyR.

La lista de afectados es bastante extensa e incluye empresas de diferentes sectores relacionadas con el tratamiento de aguas e infraestructuras. Entre la información filtrada se encuentran multitud de credenciales corporativas de personas relacionadas con estos sectores.

Descubre con nuestros analistas de inteligencia cuál ha sido el ejercicio de atribución realizado, así como la colaboración del presunto autor con otros grupos hacktivistas en el pasado.



No te puedes perder el próximo Cybersecurity Shot:
» Caso Comelec

Más información en

Abuso de alias de Gmail para la exfiltración de información

jueves, 11 de agosto de 2016




¿Sabías que las muestras de malware que utilizan servicios de correo electrónico como canales encubiertos para la exfiltración de información están formando parte de ataques persistentes avanzados? En ElevenPaths hemos descubierto una nueva forma de abuso de los alias del servicio de correo de Gmail que podría ser utilizada por las herramientas de exfiltración de información.

Con esta nueva técnica de abuso a los servicios de correo electrónico de Gmail se descubren nuevas posibilidades para la utilización de este servicio como canal encubierto. A pesar de que no se haya tenido constancia de su utilización, debe tomarse en consideración el establecimiento de medidas de seguridad que permitan proteger la información que tanto particulares como organizaciones o estamentos gubernamentales albergan en sus sistemas.

En el pasado ya se identificaron muestras de malware empleadas por parte de ciertos grupos que utilizan técnicas de covert channels (canales encubiertos, en inglés) con el servicio de correo electrónico de Gmail como mecanismo encubierto para la exfiltración de información o como herramienta para el control del sistema infectado.

Key Threat
Técnicas covert channel mediante los alias de gmail 
Con esta nueva técnica de abuso a los servicios de correo electrónico de Gmail se descubren nuevas posibilidades para la utilización de este servicio como canal encubierto. A pesar de que no se haya tenido constancia de su utilización, debe tomarse en consideración el establecimiento de medidas de seguridad que permitan proteger la información que tanto particulares como organizaciones o estamentos gubernamentales albergan en sus sistemas.

Recomendación del analista
Precaución a la hora de considerar los dominios de Gmail como confiables
Dominios de Gmail u otros proveedores de correo electrónico o incluso dominios relacionados con redes sociales podrían estar siendo utilizados para tomar el control de los sistemas de una organización. Es por ello que ElevenPaths recomienda realizar una monitorización en detalle de los mismos o incluso bloquearlos en el caso de sistemas que alberguen información sensible. Por otro lado, con las tecnologías de defensa contra malware avanzado se realiza una monitorización exhaustiva del comportamiento del endpoint, por lo que esta aproximación permitiría analizar el comportamiento del mismo en el caso de que un dominio o servicio, a priori legítimo, estuviese siendo utilizado con fines maliciosos.

» Descárgate la investigación completa desde nuestra web “Abuso de alias de Gmail para la exfiltración de información“.

También te puede interesar:
» Malware que instala certificados raíz en Windows y Firefox automáticamente

Más información en
Elevenpaths.com

Prueba Mobile Connect y Latch en Nevele Bank

miércoles, 10 de agosto de 2016

Figura 1: Mobile Connect

Mobile Connect nos ofrece un servicio de autenticación a servicios online para mejorar la experiencia de usuario y su seguridad en ellos, por ejemplo en un banco como el que tenemos en ElevenPaths denominado Nevele Bank. Ésta web es nuestro banco de demostración, dónde tu puedes probar nuestras tecnologías Mobile Connect y Latch. En este vídeo, nuestro compañero Chema Alonso hizo una demostración de cómo funciona la autenticación con Mobile Connect con PIN, la demostración de cómo funciona la autenticación de Mobile Connect con Biometría y la demostración de cómo funciona la autenticación con Latch en un Apple Watch.



Figura 2: Vídeo de demos de Mobile Connect, Biometría y Latch


Cuando iniciamos sesión en un sitio web al introducir nuestra contraseña somos vulnerables frente a un posible ataque, sin embargo hoy en día tenemos a nuestra disposición herramientas como Latch o Mobile Connect para reducir los riesgos de sufrir robos de cuenta y en caso de sufrirlos poder denegar el acceso a esta.

Mobile Connect también nos permite solucionar el típico problema “he olvidado mi contraseña”, es una alternativa más rápida y sencilla a la autenticación vía e-mail o a las preguntas de seguridad que algunos servicios nos ofrecen para verificar nuestra identidad en caso de no recordar nuestra contraseña.

Probar Mobile Connect & Latch

En este artículo os mostraremos como usar Mobile Connect en Nevele Bank, la web de pruebas que puedes usar para testear nuestras tecnologías. Lo primero de todo recuerda que tienes la opción de probar también Latch en Nevele Bank, tal y como explica este vídeo que hicimos hace tiempo.


Figura 3: Vídeo demostrativo de cómo usar Latch en Nevele Bank

Para probar Mobile Connect, lo primero que haremos será entrar en la página web de Nevele Bank, una vez hecho esto procederemos a crearnos una cuenta o si ya la tenemos simplemente iniciaremos sesión, cuando estemos en el menú principal pulsaremos sobre nuestro nombre de usuario en la esquina superior derecha y se nos mostraran en pantalla las opciones “Latch Service” y “Mobile Connect” junto a la opción de “Cambiar la contraseña”.

Figura 4: Configuración de Latch y Mobile Connect

Dentro del apartado de “Mobile Connect” pulsaremos sobre “Pair account” y seremos redirigidos a una página en la que tendremos que introducir nuestro número de teléfono, tras haber hecho esto aparecerá en la pantalla de nuestro dispositivo móvil un aviso diciendo “Nevele request access”, pulsaremos en “ok” y ya habremos finalizado el proceso de pareado.

Autenticarse con Mobile Connect en Nevele Bank

La autenticación es posible debido a que Mobile Connect envía un identificador anónimo asignado a nuestra cuenta durante el proceso de pareado cada vez que aceptamos una petición de acceso, si el identificador recibido coincide con el de nuestra cuenta podremos entrar en ella, por eso no es necesario que introduzcamos el nombre de usuario ni la contraseña.

Figura 5: Login con Mobile Connect en Nevele Bank
Ahora que nuestra cuenta está vinculada no necesitaremos introducir el nombre de usuario y contraseña cada vez que queramos entrar en ella, solo tendremos que pulsar sobre “Login with Mobile Connect” e introducir nuestro número de teléfono.

                                                                                                           
En cuestión de segundos aparecerá en la pantalla de nuestro dispositivo el mensaje “Nevele requests Access”, si pulsamos sobre “ok” automáticamente entraremos en nuestra cuenta, en cambio pulsando sobre “Cancel” nos redirigirá a la página principal de Nevele.

Una de las grandes ventajas que tiene Mobile Connect es que aunque alguien quiera logarse con nuestra cuenta y se sepa nuestro teléfono móvil no podrá entrar ya que nosotros seremos los que recibamos la petición de acceso en nuestro teléfono móvil y podremos denegarla. Si quieres estar al tanto de las últimas tecnologías en el mundo de la seguridad no dudes en ver nuestros ElevenPaths Talks y pásate por nuestra Community y comparte tu experiencia con nuestros expertos.


Sergio Sancho Azcoitia
ElevenPaths

Eleven Paths Talks: Fraude en POS

martes, 9 de agosto de 2016



El próximo jueves 11 de agosto nuestro compañero Gabriel Bergel impartirá una charla en la que se hablará sobre los tipos de fraude más populares en América Latina (principalmente en el Tampering de POS), la estructura de las bandas criminales, quienes son, las contramedidas implementadas, el CHIP EMV y sus principales vulnerabilidades, y la poca seguridad del protocolo NFC usado por "Contactless".

La duración de la charla de Gabriel será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.

Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 11 de agosto a las 15.30h (Madrid)Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.

Más información en:
talks.elevenpaths.com



Cybersecurity Shot_Fuga de Información de 17 Media

lunes, 8 de agosto de 2016





Cybersecurity Shot es un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red así con algunas recomendaciones que podrían haberlo evitado.

Cada entrega trae un caso real. Te ponemos al día de lo último en Ciberseguridad. ¡Echa un vistazo!

A continuación puedes leer un breve resumen de la última investigación:

Caso 17 Media

Investigación "Fuga de información de 17 Media"

17 Media es una aplicación multiplataforma dedicada al streaming de vídeo y a la compartición de contenido multimedia en tiempo real creada originalmente por el cantante pop taiwanés de origen norteamericano Jeffery Huang en 2015 y liberada originalmente para dispositivos iOS y Android.

La filtración fue puesta originalmente a la venta por el usuario en TheRealDeal, un conocido mercado de compraventa en la deep web afectando a las credenciales de 30 millones de sus usuarios. Según algunas informaciones de medios el ataque fue perpetrado directamente contra los servidores de la aplicación.

¿Quieres conocer más datos? Descubre con nuestros analistas de inteligencia la naturaleza de la información filtrada y las recomendaciones para evitar ese tipo de ciberataques.

» Descárgate el caso “Fuga de información de 17 Media

No te puedes perder el próximo:
» Caso Seven Dollar Click

Más información en
Elevenpaths.com

Instancias en Latch: Ejemplos y Uso

viernes, 5 de agosto de 2016

Hace unos días publicamos en este mismo blog una entrada con nuevas novedades en Latch. Una de ellas eran las instancias. Vamos a hablar de las instancias de una forma más detallada mostrando algún ejemplo para ver su uso. 

¿Qué son las instancias? 

Las instancias son operaciones de Latch, similares a las operaciones que teníamos tradicionalmente en Latch configurables desde el panel de edición de una aplicación:














Configuración de operaciones para una aplicación


La diferencia entre una instancia y una operación es que las instancias son operaciones personalizadas para un usuario concreto pareado con la aplicación. Las instancias pueden crearse para una aplicación o para una operación de la aplicación.


¿Cuántas instancias puedo crear?

Los desarrolladores tipo community pueden crear hasta un máximo de 2 instancias por usuario y operación. 
Para subscripciones de tipo Silver o Gold existe un límite de 10, mientras que los desarrolladores Platinum tienen instancias ilimitadas.


¿Cómo se usan las instancias?

De forma breve, el primer paso es crear una instancia a alguno de nuestros usuarios pareados. Para ello debemos realizar una llamada PUT a alguno de los siguientes extremos de la API, dependiendo de si queremos crear la instancia en la aplicación o en alguna operacion:


Incluyendo como parámetros de esta llamada los nombres de las instancias que se desean crear. 

La respuesta a esta llamada nos incluirá una serie de identificadores de instancia únicos para dicho usuario que se deberán almacenar para futuras llamadas.

{"data":{"instances":{"instanceId_1":"Name_1","instanceId_2":"Name_2","instanceId_N":"Name_N", ...}}}

Posteriormente se puede consultar el estado de una instancia, igual que para una operación simplemente añadiendo el instanceId en la llamada:


Toda la documentación para realizar la gestión de instancias (crear, modificar, eliminar…) así como consultar el estado de una instancia o modificarlo se puede encontrar aquí:


Poco a poco a lo largo de las próximas semanas iremos actualizando nuestros SDKs para que soporten estas nuevas llamadas a la API.


¿Para qué me pueden servir las instancias?

Puedes utilizar instancias allí donde quieras granularizar el servicio de Latch con operaciones pero estas operaciones no sean iguales para todos tus usuarios. 

Por ejemplo: en un entorno de banca online como nuestro banco-demo Nevele Bank (https://nevele.elevenpaths.com)

Si quisiéramos tener una operación para cada una de las tarjetas de crédito de un usuario con las operaciones tradicionales no podríamos puesto que esas operaciones son iguales para todos los usuarios.

De esta forma con las instancias podemos tener usuarios con 1 tarjeta, usuarios con 2, etc… que se correspondan con distintas operaciones de Latch 


Dos usuarios pareados con distintas instancias en una operación


¿Puedo probar el funcionamiento de las instancias?

Si, puedes probar el funcionamiento de las instancias con tu usuario de Nevele Bank. 

Para ello si ya estás registrado y pareado con Latch puedes acudir a la sección “Credit Cards” con tu usuario, para crear tarjetas y probar el funcionamiento de las instancias.
























Puedes utilizar el botón “Test Payment” para simular un pago con dicha tarjeta y comprobar cómo sería valido o invalido en función de como tengas configurado el Latch para esa tarjeta. 

Esperamos que esta nueva funcionalidad abra la puerta a más y mejores integraciones con Latch. Por supuesto, si tenéis cualquier duda sobre el funcionamiento de las instancias o queréis contarnos vuestras experiencias o enseñarnos vuestros casos de uso podéis hacerlo y comentarlo en nuestra comunidad técnica: https://community.elevenpaths.com/




Más información:

*También te puede interesar: