Source: https://blog.elevenpaths.com/2016/03/
Timestamp: 2018-08-15 13:36:47+00:00

Document:
ElevenPaths Blog: marzo 2016
Publicado por Eleven Paths en 17:06:00 2 comentarios: Enlaces a esta entrada
El próximo Jueves 31 de Marzo nuestro compañero Claudio Caracciolo impartirá una charla sobre la seguridad en redes y entornos industriales. Cada día es más importante fortificar y asegurar estos entornos y redes, ya que las consecuencias de una mala gestión de la seguridad puede tener efectos muy negativos.
Claudio ya nos habló sobre la seguridad en redes industriales, tal y como pudimos leer en su artículo Introducción a la Seguridad en Redes Industriales. Claudio nos hablará de por qué es necesaria la seguridad industrial y de la diferencia entre safety y security. No es lo mismo. Os dejamos un listado de artículos de Claudio Caracciolo sobre esta temática:
La duración de la charla de Claudio 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án las 15.30 (GMT+1). La sesión se realizará en castellano. La charla estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangout.
Os esperamos para que nuestro CSA os enseñe todo lo que necesitáis conocer sobre el mundo de la seguridad en redes industriales. Puedes mirar el calendario de talks para ver las que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 31 de Marzo en horario de 15.30 (GMT+1). Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.
Publicado por Eleven Paths en 10:01:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: brechas seguridad, Ciberseguridad, eleven paths, eventos, seguridad, seguridad de la información, seguridad digital, talks
Una disciplina muy importante en seguridad de la información, es la Inteligencia y también existe la Ciberinteligencia, que es la inteligencia aplicada a la informática o al Ciberespacio, la forma de aplicar la Cibeinteligencia se basa en un ciclo (que esta basado en el ciclo de la inteligencia) con fases que explico a continuación.
Esta fase como lo dice su nombre, planificamos, se define quién coordinara la misma e identificaremos las necesidades y la información que demandan los destinatarios del proceso de ciberinteligencia. Debemos en esta fase definir cuál va a ser la estrategia para la recolección de la información, el tipo de información y el contenido definiendo y clasificando la disponibilidad y fiabilidad de las fuentes y los flujos de la comunicación.
Fase 2 - Recolección
El objetivo de esta fase es obtener la información en bruto. Cuanto mayor información obtengamos mejor, pero es importante tener los atributos relacionados con esa información, saber su clasificación de seguridad, conocer la fuente, el contexto, la fiabilidad de la fuente, la integridad de la información, la fecha de la misma, etc. Todos estos atributos serán necesarios para la fase siguiente de análisis. Esta recolección de información es importante realizarla bajo un marco legal, es muy fácil franquear barreras legales y/o normativas que pueden anular la eficacia del resultado de la ciberinteligencia.
En esta fase analizamos la información obtenida, debemos depurarla, tratarla, procesarla, eliminar aquella inservible, decodificarla y analizarla en un contexto global. Se trata de convertirla en inteligencia estratégica, táctica u operativa destinada al propósito inicial establecido en la planificación.
En esta fase debemos también clasificar la información en función a los diversos atributos asociados como la fiabilidad de la fuente, fiabilidad de la información, validez de los datos, oportunidad, pertinencia, relevancia y utilidad.
Un proceso muy importante, es ser capaces de interpretar esa información, de forma que podamos gracias a nuestro intelecto y la información tratada a poder crear en nuestras mentes la realidad y entrar en la mente de nuestros enemigos para saber el porqué de sus acciones y adelantarnos a sus próximos movimientos.
Fase 4 - Retroalimentación
Esta fase es parte de todo ciclo de gestión, en el viejo conocido Ciclo de Demming se refiere a la fase de “Check”, consiste en retroalimentarse para adecuarse si es necesario, durante el análisis fuimos capaces de crear inteligencia, tener nuevos conocimientos que deben servir para corregir e introducir nuevas variantes en todas las fases anteriores, es decir, definir nuevas estrategias y planificación, recolectar desde nuevas fuentes o de las anteriores nueva información, realizar nuevos cruces y procesamiento de análisis de la información para generar nueva inteligencia.
Fase 5 - Difusión
Es la última fase de este ciclo y tiene por objetivo suministrar la inteligencia a quien deba ejecutar las acciones pertinentes con la suficiente diligencia para que la misma no sea tardía para la toma de decisiones. Es habitual en los esquemas que representan el ciclo de la Inteligencia que el mismo sea un círculo que no tiene fin.
Productos y Servicios de Eleven Paths
﻿ En Eleven Paths hemos desarrollado productos y servicios que agregan valor desde la Fase 2 en adelante, ya que para la Fase 1 las herramientas que se recomiendan son las clásicas para administrar proyectos, Cartas Gantt, sistema de gestión de proyectos, planilla Excel, etc.
En la Fase 2 el servicio de facto que tenemos en 11P es Cyberthreats (https://www.elevenpaths.com/es/tecnologia/cyberthreats/index.html) ya que recolecta y clasifica información y hallazgos de distintas fuentes de información haciendo reconocimiento pasivo del objetivo, Sandas (https://www.elevenpaths.com/es/tecnologia/sandas/index.html) también aporta gracias al modulo de Detección colaborativa que Agrega múltiples fuentes internas y externas de datos, adquiriendo información de Internet y el mundo físico.
En la Fase 3 nuestro principal producto es Sinfonier (https://www.elevenpaths.com/es/tecnologia/sinfonier/index.html) ya que genera información de valor con datos recopilados de todas las fuentes de información disponibles. Sinfonier permite integrar, procesar y analizar datos internos y externos de una organización ofreciendo la información de forma visual y en tiempo real. También nos ayuda mucho el servicio de Cyberthreats ya que en el portal de gestión de amenazas la información que entregamos esta depurada, clasificada, contextualizada analizada e interpretada. También Sandas, ya que es una plataforma integral de monitoreo, centralización y gestión de incidentes que permite hacer Análisis, categorización, notificación y respuesta inmediata a los incidentes de seguridad de la información.
En el mundo móvil y para Android tenemos Tacyt (https://www.elevenpaths.com/es/tecnologia/tacyt/index.html) que supervisa, almacena, analiza, correlaciona y clasifica millones de apps móviles mediante su tecnología de big data añadiendo miles de aplicaciones nuevas cada día.
En la Fase 4 también nos ayuda mucho el servicio de Cyberthreats ya que en el portal de gestión de amenazas los analistas están constantemente revisando la información de los hallazgos, eliminando falsos positivos, creando nuevas correlaciones, etc. Y SANDAS ya que detecta mediante algoritmos de inteligencia incidentes de seguridad que pasan desapercibidos para los SIEM.
Para finalizar el ciclo, en la Fase 5 volvemos a citar a Cyberthreats y SANDAS ya que ambos son portales web en tiempo real y cuadros de mando operacionales y configurables para la gestión de incidentes de seguridad, la diferencia es que Cyberthreats es de reconocimiento pasivo y SANDAS de incidentes activos.
Espero haber cumplido el objetivo de explicarles las fases de la Ciberinteligencia y como pueden apoyarse en nuestros productos y servicios para llevarla a cabo, hasta el próximo post.
Publicado por Eleven Paths en 8:39:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: Android, big data, cybercrime, Cybersecurity, cyberthreats, SandaS, Sinfonier, tacyt, tecnologías big data
Publicado por Eleven Paths en 14:44:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: espionage, hacking, malware, mobile, surveillance
Equipos de Respuesta ante Incidencias de Seguridad (II)
Este jueves hablaré de Equipos de Respuesta ante Emergencias Informáticas (CERT) en ElevenPaths Talks, nuestra serie de Webcast sobre los temas de seguridad más actuales. En la primera entrega de Equipos de Respuesta ante Incidencias de Seguridad se hablaba del concepto de CSIRT, qué era un CSIRT, y los beneficios de implementar uno de estos equipos; en esta entrega quisiera iniciar recordando que finalmente “…un CERT o CSIRT recibe, analiza y responde informes de incidentes recibidos desde miembros de su comunidad (constituency), otros CSIRT, o terceras personas, coordinando la respuesta entre las partes…”.
Durante las diferentes capacitaciones, conferencias y también asesorías que he impartido especialmente en las Américas, siempre hago especial mención en esta frase “…no hay que esperar a que nos golpeen para actuar, sino que hay que actuar antes de que nos golpeen...” y con esta frase lo que quiero decir desde un punto de vista muy personal, es que la función de seguridad que cumplen estos equipos, debe ser enfocada principalmente de una manera proactiva y no tanto de una manera reactiva; de esta manera es más probable que salgamos airosos de las embestidas de los atacantes cibernéticos disminuyendo así el impacto generado por los mismos, y es claro, por qué habría que esperar hasta que se genere una afectación negativa en un activo de información para poder implementar medidas y procesos de protección?
Solo pensemos en lo que pasaría si por ejemplo en una infraestructura crítica como podría ser una central energética, su correspondiente CSIRT o CERT responsable, esperará a que un ciberataque ocasionara una interrupción del servicio (afectando hospitales, aeropuertos, etc) para poder actuar. Si ese CSIRT o CERT enfocará sus esfuerzos de una manera proactiva capacitando al personal de su comunidad atendida (en este caso la infraestructura energética), apoyándolos con asesoramiento en procedimientos, gestión de incidentes, aseguramientos de plataformas, concienciación de seguridad, etc., de seguro el impacto del ciberataque sería mucho menor o probablemente nulo. Claro, esta manera de pensar/actuar no garantiza que se eliminen los daños ocasionados por ataques cibernéticos, pero definitivamente y como ya lo mencioné, si reduce el impacto de los mismo y por ende el esfuerzo durante la reacción será mucho menor.
Pero, y ¿cómo ser proactivos?, pues son muchas las actividades que se deben realizar para ello, el adelantar buenas prácticas nos ayudará a estar mejor protegidos (como aperitivo en este tema, recomiendo la lectura de este interesante artículo escrito por mis compañeras Ester Bermejo y Yaiza Rubio de ElevenPaths).
Un modelo holístico de gestión de riesgos centrado en ciberinteligencia ayuda a prevenir, detectar y responder de forma continua ante ciberamenazas que pueden suponer un alto impacto en el modelo de negocio de las organizaciones; y también hay que entender que el mundo de la tecnología avanza vertiginosamente y por ende, de igual manera el mundo de la ciberseguridad, es por esto que por ejemplo:
Las auditorías clásicas de seguridad ya no son suficientes. En consecuencia, una tecnología de pentesting persistente que escanee los sistemas las 24 horas del día los siete días de la semana es una muy buena opción para identificar de manera proactiva posibles vulnerabilidades en la organización y lo que es mejor aún, reduciendo costos operativos.
Tampoco el confiarse solamente en las contraseñas para basar la seguridad de los usuarios (administradores de plataformas, usuarios de gerencia, funcionarios de la organización, etc) no es suficiente, por eso es imprescindible el poder implementar un sistema que permita añadir un nivel adicional a las cuentas de los usuarios cuando estos no las estén utilizando.
En la siguiente entrega veremos otras consideraciones adicionales y qué tipo de software (gratuito y de pago) es considerado para implementar dentro de un CSIRT o CERT para brindar sus servicios.
¿Quieres saber más? Conéctate este jueves a las 15:30 (GMT+1) al hangout que daré personalmente sobre Equipo de Respuesta ante Emergencias Informáticas (CERT, del inglés Computer Emergency Response Team). Si todavía no te has registrado, apúntate aquí.
» Equipos de Respuesta ante Incidencias de Seguridad (I)
@SamuraiBlanco ﻿
Publicado por Eleven Paths en 15:01:00 2 comentarios: Enlaces a esta entrada
Etiquetas: brechas seguridad, Ciberseguridad, eleven paths, Pentesting, Respuesta a incidentes
ACCESS DATA: Twitter. I have created an account in this social media network which delivers real-time stream of semi-structured data (loosely formatted characters inside a field but with little structure within it). The information is delivered in a JSON format which is what I will need to process. For example, word to search in the tweets: Verdun.
Etiquetas: security intelligence, seguridad en tiempo real, Sinfonier, Threat Intelligence
Download the new report shows that Tacyt had dissected a total of 3,365,527 applications from the Google Play Store, of which only 2,438,864 remained available for download on the market.
The study conducted by ElevenPaths’ Analyst Team aims to study the population of developers and applications in the Google Play Store in early February 2016, to determine its size, structure, evolution and general characteristics from a quantitative point of view.
Tacyt has been used as a source of information. Tacyt is an innovative cyberintelligence tool that monitors, stores, analyses, correlates and classifies millions of mobile apps thanks to its big data technology, adding thousands of new applications every day.
Some details of the report:
According to the email address used by the developer in the Google Play Store (developerEmail), Tacyt has information on 678,328 different developers. About 44% of email addresses present in the Google Play Store belong to the "gmail.com” domain.
Google requires developers to sign all their applications prior to being published in the Google Play Store. This certificate is used to identify the author of the application. The total number of different certificates found by Tacyt has been 805,731. Even though the vast majority of certificates found are associated with a single email address, there are exceptions. Even one certificate related to more tan ten thousand different email addresses has been found.
Sharing the same certificate among several developers is not a recommended best practice from a security standpoint, since it could compromise the apps’ update process or the information they handle. Of the 805,731 certificates (certificateFingerprint) known by Tacyt, 761,389 are associated with a single developer email address (developerEmail). The rest is used by two or more different developer email addresses to sign their applications.
Even though the use of digital certificates for the signing of software should identify the individual or entity behind the software in an unambiguous manner, this report shows through the use of numbers that Google Play facilitates the abuse of this concept and this might lead to situations where suchidentification becomes compromised.
» Download now the full report “Demographic Analysis of Google Play″
Publicado por Eleven Paths en 16:38:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: Android, english, google play, tacyt
Aquí tenéis las impresiones de Jesús Milán sobre su asistencia a la RSA Conferece de San Francisco.
Ya hace una semana que finalizó la RSA2016, el principal congreso de seguridad a nivel mundial que se celebra en la ciudad de San Francisco.
Como todos los años el nivel de asistencia fue increíble, estimándose en algo más de 40.000 asistentes. Sin duda el evento de seguridad.
Esta edición ha sido especial y mucho más intensa, ya que Telefónica - ElevenPaths tenía presencia activa en el congreso a través de un stand, no muy grande debido a las estrictas reglas de la organización, pero sí con servicios y productos innovadores y sobre todo con muchas ganas e ilusión. Toda una experiencia.
En términos de novedades, la verdad es que este año no ha habido nada especial que me haya sorprendido como en otros años, más allá de la evolución gráfica de los productos de seguridad (cada día más impresionantes), sólo comparable con la imaginación y marketing de los nombre de empresas y productos allí representados.
Respecto a las soluciones y las tecnologías sin grandes novedades como digo, aunque con un incipiente interés, en comparación con los que será en los próximos meses, de los clientes por la seguridad en loT (Internet de las cosas).
La revolución del IoT va ligado de manera inseparable a las comunicaciones, por ello pensaba que las grandes operadoras, que son las que realmente tienen algo que decir en esto del IoT, íbamos a ir con todo nuestro arsenal. Mi sorpresa fue darme cuenta que en este ámbito, también, somos los primeros en ir abriendo camino. Únicamente Telefónica-ElevenPaths, como ya hizo en el MWC de Barcelona, llevaba una propuesta a este respecto en IoT. Una aproximación aún no integrada de manera nativa en los servicios, lo cual ocurrirá en breve. Un camino donde la seguridad es un atributo “core” de toda propuesta de IoT, sin el cual el futuro del IoT, como ya hemos podido ver noticias de incidentes a este respecto, tendrá un futuro muy incierto. Los fabricantes siguen sin apostar por el concepto “Security by design”. Sin este concepto, la vieja aspiración de que la seguridad pase de un gasto a una inversión seguirá sin cumplirse.
Con respecto a las conferencias poco puedo decir, ya que apenas pude asistir a 3. La que más me gustó, por ser una aproximación fresca y sobre todo pragmática de la seguridad y la responsabilidad de la función dentro de la organización fue realizada por los compañeros del BBVA y I4S. Soy consciente que me une amistad con ellos de largos años de camino juntos, que sin duda me hace verles con “buenos ojos”, si bien honestamente me gustó.
Ahora a trabajar desde ya en la edición 2017.
@J0Milan
Publicado por Eleven Paths en 7:30:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: ciberataques, Ciberseguridad, eventos seguridad, Internet de las Cosas, iot, RSA, san francisco
﻿Dentro de una misma empresa u organización hay “mundos” que no se cruzan, o si se cruzan, literalmente explotan…
Lamentablemente es muy normal que las áreas de seguridad, tecnología, desarrollo y/o auditoría se encuentren en conflictos permanentes entre sí, y sobre todo que se confundan los alcances de sus funciones, aunque todos conocemos la teoría de cómo deberíamos trabajar ( en equipo, empujando todos hacia el mismo objetivo, etc. etc.), pero las verdaderas preguntas son: “¿realmente debemos llevarnos mal? ¿Tan malo es que el área de auditoría interna participe en los informes de Ethical Hacking?”
Muchos deben pensar inmediatamente que no es función de Auditoria Interna, que no tiene los conocimientos necesarios, que el área de Seguridad posiblemente tenga dentro de sus objetivos la realización de los diferentes tipos de test de intrusión de forma periódica, etc. Sin embargo, mi planteo no apunta a que la ejecución de las tareas la realice auditoría interna sino a que los resultados puedan ser utilizados por ella para un proceso más global. Como técnico, a veces nos centramos en problemas meramente técnicos para identificar y señalar una falla, pero muchas veces esa falla responde a problema en un proceso (por no existir, por ser ineficiente, o por lo que sea), y en la mayoría de los casos ese proceso es demasiado grande y parece ser ajeno a nosotros. Claramente, no podemos desconocer que los controles técnicos no son ni serán en un corto plazo, lo suficientemente buenos como para no depender de las personas en algún punto, aunque a veces diminuto.
Desde una óptica mucho más amplia, un área de auditoria interna puede aprovechar un test de intrusión para:
Evaluar controles técnicos y estrategias de IT, compras, etcétera. A priori, este es el más obvio de todos porque todo aquel que contrata quiere evaluar controles técnicos. Pero los resultados de los informes, reflejan eso? Por lo general: NO. Solo reflejan agujeros de seguridad. Si el área de auditoria toma un informe de estos difícilmente entienda algo, pero si las áreas interesadas se reúnen, el resultado podría aportar información a la empresa sobre gestión, como por ejemplo: ¿Qué equipos o servicios se han comprado durante el año en el área ( IT/Seguridad/Infraestructura/Comunicaciones/Operaciones/etcétera)? En caso de poder hacer una comparación, esas compras o contrataciones ¿han permitido reducir brechas respecto a años anteriores? En caso de no poder hacer esa comparación, esas compras o contrataciones ¿han permitido mitigar de alguna manera la aparición de nuevas debilidades? En un informe técnico el nivel de detalle es importante para ir corrigiendo las pequeñas cosas que pueden causar grandes problemas. En un informe ejecutivo de auditoría, los detalles no importan, lo que importa es lo que se quiere medir más allá de un control determinado, como por ejemplo si la empresa invirtió bien o no.
Evaluar procesos y procedimientos. Un informe técnico de un test de intrusión entrega resultados del tipo: “Hemos detectado la vulnerabilidad conocida como MS08-067 por la cual hemos podido tomar control remoto del equipo tras su ejecución…”. El informe ejecutivo realizado por un técnico diría algo como: “se ha detectado la falta de parches de seguridad y/o actualización de algunos de los sistemas…” Pero si nos alejamos un poco y miramos el proceso macro, podríamos diferenciar e identificar si éste es un problema de un solo parche en un equipo, o si la ausencia de actualizaciones en varios de ellos y con un tiempo excesivo desde que fue desarrollado nos está indicando que no existe, o es ineficiente, un procedimiento adecuado para el monitoreo e implementación de parches dentro de la compañía (o en un sector de ella).
Evaluar campañas de concientización, métricas. Siempre se discute si las campañas de concientización son efectivas o no, si son un gasto necesario o si son un gasto absurdo, si los usuarios pueden cambiar sus hábitos o si es una mentira de las consultoras. Lo importante no es solo armar campañas dando charlas, videos y demás, sino medir su efectividad. En un test de ingeniería social esto se puede lograr, pero de nuevo, el área ejecutora difícilmente sea auditoría, sin embargo sería positivo que pueda evaluar como se diseño, quienes participaron en el diseño, si se tuvieron en cuenta las edades del publico objetivo como también sus usos y costumbres, la estructura organizacional, la forma en que se midió, etcétera.
Casi todo técnico (o todo) odia escribir reportes y por eso los automatizamos tanto como sea posible, y los informes ejecutivos no son nuestra especialidad, aunque claramente éstos son importantes para que la Alta Dirección los entienda. Si pudiéramos trabajar en equipo, auditoría podría tomar nuestros resultados, hacer unas cuentas preguntas más básicas, sin detalles técnicos y volcar información más que valiosa que permita a la cúpula evaluar y gestionar de una manera más eficiente. Durante años se dijo que las personas de seguridad debemos hablar el mismo idioma que el negocio, para mi, eso es utópico, desde mi óptica los resultados son mejores cuando las áreas pueden interactuar entre sí para hablar un idioma común y entregar información que sea de utilidad para la toma de decisiones.
Aunque a los técnicos no le gusten los auditores porque no nos entienden y a los auditores no les gustan los técnicos porque hablan raro, podemos complementarnos, ya lo decía A. Einstein: "Todos somos ignorantes, pero no todos ignoramos las mismas cosas".
Etiquetas: auditoría, ethical hacking, hackers, hacking, IT, organizaciones
Malware que instala certificados raíz en Windows y Firefox automáticamente
El malware y el mundo de los certificados parecen condenados a entenderse, y cada vez más. Aunque Avira ya ha hablado sobre una muestra parecida hace unos días, en ElevenPaths hemos encontrado otra evolución que le da una pequeña vuelta de tuerca a esta técnica de inyectar certificados raíz en el sistema. Veremos aquí en qué consiste el detalle y repasamos algunos incidentes anteriores.
Los creadores de malware se están viendo obligados a utilizar técnicas ingeniosas para utilizar inteligentemente la oportunidad que brindan los certificados en todas sus dimensiones y hacer gala así de una legitimidad de la que carecen. Una de las muestras recientemente detectadas por Avira, instala un certificado raíz legítimo de COMODO en el sistema, pidiendo al usuario que sea él mismo quien lo valide. Entendemos que se trata de una primera fase de la infección en la que, una vez con el certificado en el sistema, el malware lo redirigirá a páginas falsas firmadas con certificados hoja que se verán perfectamente legítimas en el navegador de la víctima.
Sin embargo, en ElevenPaths hemos observado una pequeña evolución en la que es el propio malware el que valida la instalación del certificado. O sea, se encarga de hacer desaparecer la ventana de seguridad, pulsando él mismo sobre "Sí" para que la víctima no perciba la instalación. Además, este malware también inyecta un certificado raíz no solo en el sistema, sino también en el TrustStore de Firefox (que no utiliza el de Windows). Por tanto, use el navegador que use, la víctima confiará en un certificado de un tercero. Esto permitirá que cuando visite un dominio real de su banco (pero alojado en un servidor falso) todo parezca perfectamente legal a ojos del navegador y del sistema.
Mostramos aquí un pequeño vídeo explicativo del funcionamiento en el que se observa la ventana de instalación siendo eliminada rápidamente por el propio malware. En un sistema "normal" sin demasiada carga de trabajo, la ventana no llegaría ni a percibirse, puesto que sería instantáneamente interceptada por el malware.
Esto es lo que debería ver el usuario,
pero que el malware intenta evitar programando un clic rápido sobre el botón de aceptar
Este tipo de ataque nos hace recordar incidentes similares en los que se ven involucrados certificados raíz instalados de serie, como los casos en portátiles Lenovo (Superfish) o eDellRoot. En esos casos, se hizo pública la clave privada, pero en este, la clave pertenece al atacante que además controla el sistema, por lo que el ataque es "personalizado" a la víctima y simplifica mucho la programación. Por ejemplo, al contrario que los míticos troyanos bancarios rusos tipo Zeus, aquí no debe acudir a técnicas de inyección en el navegador, sino que basta con montar un servidor falso para que la página troyanizada se vea bastante legítima. Sin resultar técnicamente espectacular, es una manera muy ingeniosa de mantener la simplicidad y la eficacia. Por lo demás, el malware resulta sencillo en cierta manera, y es bastante detectado por los antivirus. Puede tratarse de una especie de prueba de concepto o tanteo. Eso sí, el certificado no ha sido revocado aún y parece que está circulando desde hace ya cuatro meses. Algo muy curioso que realiza este malware es el uso de Powershell en general además de eliminar el proxy de Firefox. El registro que almacena el propio malware es bastante autoexplicativo. Instala un certificado y elimina las referencias a un potencial proxy en Firefox, lo que puede significar que el atacante no quiere que nada interfiera en la comunicación. Estas son algunas líneas interesantes.
[Firefox::InstallCert(): Init OK]:[firefox]:[92]
[Firefox::InstallCert(): Init find OK]:[firefox]:[98]
[Firefox::InstallCert(): Profile: '%APPDATA%\Mozilla\Firefox\Profiles\5
[Firefox::InstallCert(): Init cert OK]:[firefox]:[118]
[Firefox::InstallCert(): CERT_GetDefaultCertDB OK]:[firefox]:[131]
[Firefox::InstallCert(): CERT_ChangeCertTrust OK]:[firefox]:[139]
[Firefox::InstallCert(): Add cert OK]:[firefox]:[142]
[Firefox::InstallCert(): Find OK]:[firefox]:[144]
[Firefox::InstallCert(): Free OK]:[firefox]:[147]
[Cert was added to Firefox!]:[core]:[209]
Remove 'network.proxy.type' from '%APPDATA%\Mozilla\Firefox\Profiles\5\prefs.js']
Remove 'network.proxy.autoconfig_url' from '%APPDATA%\Mozilla\Firefox\Profiles\5\prefs.js']
[Pac was added to Firefox!]:[core]:[218]
Certificado raíz del atacante, que intenta simular venir de Thawte
El certificado en sí está firmado para poder hacer virtualmente cualquier cosa, pero entendemos que la intención del atacante es montar servidores maliciosos con certificados falsos (pero dominios verdaderos), creados para que validen contra esa CA que acaba de instalar en su víctima. El crimen perfecto. Es interesante comprobar cómo el malware aprovecha un viejo truco de pulsar las teclas por el propio usuario. Esto es algo ya resuelto en UAC por ejemplo con la atenuación de escritorio… pero no se hace con los certificados. Microsoft podría tomar nota y atenuar el escritorio cuando se va a aprobar la instalación de un certificado importante.
Más detalles sobre el certificado que instala el malware
Certificados: Authenticode y TLS
Las razones por las que el malware necesita utilizar certificados son varias. Además desde dos perspectivas diferentes. Intentemos esquematizar las ideas más importantes, de por qué son dos mundos relacionados.
Desde la perspectiva de Authenticode (código ejecutable firmado en Windows), la necesidad es clara. Hace ya algunos años que Windows obliga a que los drivers en 64 bits se encuentren firmados para poder ejecutarse. Esto hace que quien quiera instalar un rootkit necesite comprar un certificado específico y garantizar en cierta manera su identidad (falsa o no) o robar algún certificado de un tercero. De hecho, desde hace tiempo, el malware firmado en este sentido va en aumento.
Los atacantes que optan por robar certificados de terceros, han visto tal nicho en este negocio, que ya cuentan con un servicio de "certificados robados" que pueden comprar. Hasta ahora, habíamos visto certificados robados y usados para ataques ad-hoc.
El hecho de firmar un código, hoy por hoy, tiene cierto peso para los antivirus. Si hablamos de heurística, automáticamente un archivo firmado es menos sospechoso. También, los atacantes que se mueven en la zona gris (adware en general) utilizan certificados para firmar su código y darle un empaque del que carecen, pero que les cubre en cierta manera legalmente y les acerca un poco "más a la luz".
Desde la perspectiva de los certificados TLS, la relación con el malware es más indirecta, pero interesante, como muestra este mismo ejemplo, del que podemos sacar varias conclusiones: Podríamos estar ante una nueve tendencia interesante en la que el malware bancario intenta abusar de forma sencilla de los certificados raíz. Si bien esta muestra no es especialmente reciente, es pronto para saber la relevancia del alcance. Además, se podría reclamar a Microsoft, como medida de precaución, que exija la elevación con atenuación de escritorio para instalar certificados raíz. Firefox, por su parte, ni siquiera emite una advertencia de que se va instalar el certificado.
También desde el punto de vista de TLS, el malware bancario sí que se ha dedicado desde hace mucho a robar certificados cliente instalados en el navegador de la víctima para autenticarse.
Otras aproximaciones a los certificados
Otra aproximación curiosa que realizaba un malware no hace mucho, era la de bloquear a los antivirus aprovechando de nuevo el "TrustStore" de Windows y la firma electrónica de los binarios de los antivirus. En resumen, instalaba como "no confiables" los certificados de varios motores y así conseguía que dejasen de funcionar. Algo de lo más curioso, y que demostraba de una forma ingeniosa cómo eliminar elegantemente de la ecuación al enemigo natural.
Certificados de antivirus en el repositorio de no confiables, y un antivirus negándose a funcionar por ello.
Publicado por Eleven Paths en 9:36:00 1 comentario: Enlaces a esta entrada
Etiquetas: certificados, malware, spanish
» Descárgate el informe completo "Análisis demográfico de Google Play"
Publicado por Eleven Paths en 8:03:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: Android, Google Play Store, tacyt
A partir del próximo 17 de Marzo ElevenPaths lanzará una serie de Webcast sobre temáticas de interés en el mundo de la seguridad. Las sesiones serán semanales y con una duración de unos 30 minutos, divididos entre 20 y 25 minutos de exposición por parte del ponente y de 5 a 10 minutos de preguntas y respuestas. El horario escogido serán las 15.30 (GMT+1). La mayoría de sesiones serán en español, aunque algunas se celebrarán en inglés y portugues. Las sesiones serán grabadas y se publicarán en nuestro canal de Youtube. La plataforma sobre la que se realizarán los Webcast es Webex.
No pierdas la ocasión de saber todo sobre el mundo de la seguridad informática y de lo que está por venir de la mano de nuestros CSA, que serán nuestros ponentes en esta ocasión. A continuación, os dejamos el listado por fechas de los Webcast y el tema que será expuesto:
Os esperamos para que nuestros CSA os enseñen lo más novedoso en el mundo de la seguridad. Recuerda que tienes una cita el próximo 17 de Marzo en horario de 15.30 (GMT+1). Para registrarte debes usar el siguiente formulario de registro de Eleven Paths Talks.
Publicado por Eleven Paths en 16:23:00 3 comentarios: Enlaces a esta entrada
Etiquetas: elevenpaths, eventos, hacking, seguridad, webcast
Publicado por Eleven Paths en 17:20:00 2 comentarios: Enlaces a esta entrada
Durante los cuatro últimos días de esta semana hemos estado en la RSA de San Francisco, la feria de seguridad más importante a nivel mundial. Los más de 560 visitantes se han acercado al Stand de Telefónica en el Hall Norte #4902 a conocer de primera mano nuestras soluciones de seguridad. Te traemos lo más relevante para contártelo cómo si hubieras estado allí:
Chema Alonso contó que "Las empresas no pudieron detener la expansión del WiFi ni los smartphones, y no podrán detener el IoT". Antes de que sea demasiado tarde, mostramos el alcance y los riesgos del IoT. Aquí tienes nuestras soluciones de seguridad para el ámbito del Internet de las Cosas IoT Security.
Con Tacyt detectamos amenazas móviles. ¿Cómo? Analizando, correlacionando y clasificando apps mediante su tecnología BigData.
El coste del cibercrimen ya representa un 0,8% de la economía mundial, superando al tráfico de drogas y armas. Mostramos las capacidades de CyberThreats para prevenir, detectar y responder ante posibles ciberataques que amenazan las empresas.
Con Security Monitoring identificamos comportamientos anómalos de los dispositivos basándose en su tráfico de red y en sus logs de funcionamiento.
Con Mobile Connect mostramos la autentificación del futuro, ¡por un login sin contraseñas!
Latch es nuestro pestillo digital para utilizar como segundo factor de autenticación para nuestras cuentas y servicios online. Hemos mostrado como podemos echar la llave también a nuestas aplicaciones y servicios móviles.
Además de nuestra presencia con un stand, hemos celebrado numerosas reuniones al más alto nivel con vendors, partners estratégicos, buscando ampliar el número de alianzas de calidad que nos permitan seguir siendo líderes del mercado.
Incluso tuvimos tiempo para hacer un “ice cream party” ¡distribuyendo helados en pleno mes de febrero! Nos los quitaban de las manos y fue una de las actividades más comentadas a nuestro alrededor.
¡Nos vemos el año que viene, San Francisco!
Publicado por Eleven Paths en 15:33:00 No hay comentarios: Enlaces a esta entrada
Habiendo visto en la primera entrega, Gestión de Incidentes (I), los conceptos básicos de la gestión de incidentes, pasaremos a ver en este artículo, tal y como lo prometimos, la descripción del proceso en sí. Recordemos que son varios los propósitos de la gestión de incidentes en general, sin embargo debemos considerar como mínimo que busca:
﻿Descubrir variaciones en los servicios TI.
Registrar y clasificar estas variaciones.
Adicionalmente a lo anterior, se debe contemplar la asignación del talento humano (recurso de personal) encargado de restituir el servicio según se defina en el SLA correspondiente. Para esta actividad se requiere un estrecho contacto con los usuarios, por lo que el help desk desempeña un papel primordial en el mismo.
Registro de incidentes: Los incidentes pueden entrar al proceso de gestión proviniendo de una variedad de orígenes tales como: gestión de aplicaciones, soporte técnico, etc.
Verificar que el incidente aún no ha sido registrado es necesario para evitar duplicaciones innecesarias debido al reporte sobre el mismo inconveniente por parte de varios usuarios.
Al incidente se le asignará un identificador para su tratamiento en los procesos internos y en las comunicaciones con el cliente.
La hora, descripción del incidente, sistemas afectados, etc., debe ser información relevante para alimentar la base de datos asociada al procesamiento del incidente.
En determinado caso debe ser posible adjuntar información pertinente a la resolución del incidente; la cual puede ser solicitada al cliente mismo mediante formularios específicos diseñados para tal fin. Esta información también puede ser obtenida de la propia base de datos de la gestión de la configuración.
En los casos en que el incidente pueda impactar a otros usuarios estos deben ser informados para darles a conocer una probable afectación por parte del incidente tratado.
Clasificación: Esta etapa tiene como objetivo principal el seleccionar toda la información que pueda ser de utilidad para la resolución del incidente y entre otros aspectos puede contemplar:
Que se asigne una categoría y/o subcategoría.
Que se le asigne una priorización de acuerdo con unos parámetros definidos previamente.
Que se le asigne recurso (del segundo nivel) de talento humano por parte del help desk en caso de que en una primera instancia no se hubiese podido brindar solución.
Que se asocie un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estime el tiempo de resolución del incidente en base al nivel de servicio correspondiente y la prioridad.
Análisis, resolución y cierre del incidente: El primer paso es verificar si el incidente se ha presentado anteriormente y ha sido resuelto para poder aplicar el procedimiento asignado.
En caso tal de que el incidente pueda ser solucionado por el primer nivel, este debe ser escalado al nivel inmediatamente superior para su atención por parte de los especialistas correspondientes.
Durante el proceso de tratamiento del incidente, se debe documentar el mismo en las bases de datos de gestión de incidentes para que en caso de ser necesario, se pueda consultar por parte del actor autorizado e interesado.
Si el incidente fuese repetitivo y en dado caso que no se encuentre solución al mismo, se deberá informar a la “Gestión de Problemas” para el estudio detallado de las causas subyacentes.
En caso de solucionarse el incidente: Debe confirmársele al usuario la solución satisfactoria y debe ingresarse la resolución a la KB.
Reclasificar el incidente si es necesario.
Actualizar la información en la CMDB (Gestión de Configuraciones) sobre los elementos de configuración (CI) implicados en el incidente.
Entre otros aspectos, podríamos concluir como resumen de una correcta gestión de incidentes:
Que se aumenta la productividad de los usuarios.
Se logra un mejor control de los procesos y monitorización del servicio.
Se logra una optimización de los recursos disponibles.
Que principalmente se mejora la satisfacción general de clientes y usuarios.
Por otra parte, una inadecuada gestión de incidentes puede acarrear efectos contraproducentes tales como:
Reducción de los SLAs.
Se puede malgastar valiosos recursos trabajando concurrentemente en la resolución del incidente.
Publicado por Eleven Paths en 10:20:00 No hay comentarios: Enlaces a esta entrada
Etiquetas: Incident Response, Incident Response Management, Respuesta a incidentes, spanish
Publicado por Eleven Paths en 12:47:00 3 comentarios: Enlaces a esta entrada

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución