24 nov. 2020

SAD DNS: nueva técnica de envenenamiento de caché de DNS

Esta semana, en la ACM CCS 2020 conference, los investigadores de UC Riverside y la Universidad de Tsinghua anunciaron un nuevo ataque contra el Sistema de nombres de dominio (DNS) llamado SAD DNS (Side channel AttackeD DNS). Este ataque aprovecha las características recientes de la pila de redes en los sistemas operativos modernos (como Linux) para permitir que los atacantes revivan una categoría de ataque clásica: envenenamiento de la caché de DNS.

Los investigadores publicaron a fines de octubre de este año un paper en el que demuestran la existencia de una vulnerabilidad presente en el ecosistema DNS que permite realizar ataques de envenenamiento de la caché DNS, un problema que había sido descubierto en 2008 por el investigador Dan Kaminsky y que en principio se creía solucionado. Este hallazgo volvió a demostrar que mediante esta nueva técnica, es posible provocar el envenenamiento de la caché DNS y lograr que tras una consulta para un nombre de dominio en particular el servidor devuelva una IP potencialmente maliciosa que redireccione a la víctima a un sitio controlado por el atacante y no al sitio que corresponde al nombre de dominio legítimo.

Cómo funciona el ecosistema DNS

Antes de entrar en el análisis de SAD DNS, para comprender esta vulnerabilidad es necesario explicar más en detalle cómo funciona la infraestructura global que permite realizar estas traducciones. Para ello veamos la Figura 1. Aquí se muestra el flujo de mensajes completo que se debe realizar, en casos normales, entre distintos servidores públicos para encontrar el registro que contiene la traducción —o resolución— que buscamos.

Figura 1 – Fuente: Cloudflare

Como se observa en la imagen anterior, un cliente realiza una petición a un servidor denominado Resolver, también conocido como resolutor recursivo, que para la mayoría de los usuarios será el que les haya asignado su proveedor de servicios de Internet (ISP), o bien, algún servicio público como 8.8.8.8 de Google.

Cuando el Resolver recibe una consulta por parte del cliente, primero se fija en su caché si ya contiene la resolución buscada, en caso de no contar con ese registro, inicia una serie de consultas a otros servidores, en el orden que se ve en la Figura 1.

Lo siguiente que debemos entender es que las consultas DNS típicamente se realizan utilizando el protocolo de capa de transporte UDP, que no mantiene un estado o sesión entre cliente y servidor y cuyo encabezado puede ser fácilmente modificado para aparentar que la consulta proviene de otro equipo. Si bien este protocolo incorpora algunas debilidades en cuanto a la seguridad, su uso es una elección de diseño, ya que estos servidores manejan un gran volumen de consultas y el UDP requiere una menor cantidad de procesamiento y mensajes que el protocolo TCP para intercambiar datos.

Lo que puede ocurrir es que un atacante modifique el encabezado UDP haciéndose pasar por un Servidor Autoritativo e introduzca una resolución falsa que finalmente el Resolver almacene en su caché, provocando su contaminación o "envenenándolo". A partir de este momento, cualquier cliente que solicite la resolución de un determinado nombre de dominio al Resolver envenenado, recibirá una IP potencialmente maliciosa que lo redireccione al sitio del atacante o a su casilla de email, dependiendo del tipo de registro DNS que se modifique.

Ataque de Kaminsky

Antes de comprender el ataque SAD DNS recientemente conocido, volvamos primero al 2008, año en el que surgieron los primeros ataques de envenenamiento de caché DNS conocidos. En esta época, los Resolvers utilizaban un puerto UDP fijo (53) y la única medida de seguridad que existía era un identificador de 16 bits contenido en el paquete que debía coincidir entre la consulta y la respuesta. Existían (y siguen existiendo) otros tipos de chequeos, como el "bailiwick check", pero no vienen al caso, ya que no afectan en mayor medida a este tipo de ataques y buscan prevenir otro tipo de problemas.

16 bits representan 65536 valores posibles. El ataque de Kaminsky simplemente consiste en enviar todas estas combinaciones posibles al Resolver, spoofeando la IP de un Servidor DNS Autoritativo en el encabezado UDP, con la esperanza de que uno de esos paquetes contenga el ID correcto (que envió el Resolver y cuya respuesta aún está pendiente) y que llegue al Resolver antes de la respuesta del servidor legítimo. No era exitoso el 100% de las veces, pero si se continúa intentando, las chances aumentan y efectivamente en algún momento se termina contaminando el caché del Resolver. En la práctica, utilizando herramientas automatizadas era posible contaminar el caché en aproximadamente 10 segundos.

¿Cómo se mitigó este ataque? Si en lugar de utilizar siempre el puerto 53 se eligen puertos aleatorios al momento de enviar una consulta, la entropía aumenta significativamente de 65536 valores posibles a 4,294,836,225 (216  * 216  = 232). Si la respuesta DNS llegara a un puerto distinto del cual se realizó la consulta, el paquete es descartado por el sistema operativo y resulta prácticamente imposible que un atacante pueda probar todas estas combinaciones antes de que se produzca la respuesta por parte del servidor legítimo, sin importar cuantas veces lo intente.

¿Problema Resuelto? Aparentemente, no

Después de 12 años desde que se conoció el primer ataque de envenenamiento de caché DNS, al parecer ha vuelto. Como vimos en el análisis del ataque de Kaminsky, la medida de seguridad que se adoptó para mitigar la vulnerabilidad fue la “randomizacion” de los puertos UDP, también conocido como "Source Port Randomization".

Sin embargo, si un atacante pudiera predecir el puerto abierto de una forma más sencilla que probando todas las combinaciones posibles, estaríamos ante un escenario prácticamente idéntico al anterior que describimos. Aquí es donde entra en juego el hallazgo realizado por los investigadores de la Universidad de California en Riverside y de la Universidad Tsinghua de Beijng.

La idea es simple pero muy ingeniosa. Se trata de derrotar el "Source Port Randomization" mediante mensajes de error ICMP, utilizados como un ataque tipo canal lateral. La técnica hace uso de una funcionalidad de este protocolo llamada Response Rate Limiting (RRL) que, irónicamente, fue adoptada por motivos de seguridad para prevenir ataques de denegación de servicio distribuidos (DDoS).

De forma predeterminada, este valor máximo de respuestas por segundo es 1000 en servidores Linux, 200 en Windows Server 2019 (versión 1809) y FreeBSD y finalmente, 250 en MacOS 10.15.

Este comportamiento, adoptado para prevenir los ataques conocidos como "Smurf Attack", permite hacer inferencias sobre la configuración del servidor, en particular, si un puerto se encuentra abierto o cerrado, como veremos más adelante.

Si enviamos un paquete UDP a un puerto cerrado obtendremos un mensaje de error "port unreachable", pero si el puerto está abierto no obtendremos ninguna respuesta ICMP (la conexión fue exitosa).

Supongamos que el límite de mensajes establecido por el servidor es 1000 por segundo. El ataque SAD DNS consiste en agotar primero este límite con 1000 solicitudes que sepamos que generarán un mensaje de error ICMP y a partir de ese momento, enviar tandas controladas de paquetes UDP, aumentando el número de puerto de manera secuencial en cada consulta. En la Figura 2 se puede observar un diagrama del ataque enviando tandas de 50 paquetes cada 20 milisegundos (máxima velocidad permitida en este ejemplo).

Figura 2. Diagrama del ataque. Fuente: Cloudflare

Los primeros 49 paquetes que envía el atacante suplantan la IP del servidor autoritativo, mientras que el último contiene su propia dirección IP. La mayoría de las respuestas ICMP irán a la dirección IP spoofeada, por lo que el atacante no las podrá ver, sin embargo, no lo necesita. El truco consiste en que si todos los puertos se encontraban cerrados el contador del sistema operativo de la víctima ya habrá llegado a 1000, agotando el límite de respuestas establecido por RRL.

Eso significa que si el último paquete de cada tanda que envía el atacante —enviado con su dirección IP— no recibe ningún mensaje de error ICMP, todos los puertos estaban cerrados. Pero si recibe un mensaje de error significa que el contador llegó hasta 999; es decir, uno de los puertos estaba abierto. De esta manera se puede acotar la búsqueda de manera significativa.

Los 1000 puertos todavía representan una cantidad muy alta de posibilidades, pero se puede repetir este proceso de forma similar algunas veces más para acotar aún más la búsqueda.

En teoría, el ataque completo puede tomar hasta 65 segundos, por lo que es probable que la respuesta legítima del servidor haya llegado antes y que el ataque falle. Sin embargo, al igual que en el caso del ataque de Kaminsky, aumentan las chances de que el ataque sea exitoso cuantas más veces se repite.

Los investigadores no han indicado un tiempo promedio que demora una contaminación de caché exitosa, sin embargo, se ha confirmado que el 34% de todos los Resolvers en Internet son vulnerables, incluyendo, por ejemplo, los servicios 8.8.8.8 de Google y 1.1.1.1 de Cloudflare. Los investigadores trabajaron con estas y otras organizaciones para que las vulnerabilidades sean parcheadas antes de publicar el paper.

Si tengo un resolutor recursivo propio, ¿qué mitigaciones debería implementar?

Este nuevo fallo afecta a los sistemas operativos Linux (kernel 3.18-5.10), Windows Server 2019 (versión 1809) y posteriores, macOS 10.15 y posteriores, y FreeBSD 12.1.0 y posteriores. Se estima que el 34% de los resolvers abiertos en Internet son vulnerables, 85% de los cuales forman parte de servicios DNS tan populares como los de Google y Cloudflare.

Para mitigar este ataque se recomienda deshabilitar las respuestas ICMP salientes y configurar el tiempo de espera de las consultas de DNS de manera más agresiva. Por otro lado, el parche del kernel lo que hace es que no haya un valor fijo de 1000 respuestas por segundo, sino de un valor aleatorio de entre 500 y 2000.

Este ataque puede tener un impacto severo, por lo que se recomienda a aquellos administradores de red que operen servidores DNS de este tipo que adopten las siguientes recomendaciones lo antes posible:

Recomendaciones:

  • Actualizar el kernel de Linux y Windows a su versión más reciente. Esta vulnerabilidad ya fue corregida mediante la randomización del RRL para agregar aún mayor entropía y efectivamente volver a este ataque impracticable.
  • Bloquear los mensajes de error ICMP "port unreachable" en el firewall.
  • Mantener el software DNS que se utilice al día.

Detección de un ataque:

  • Detectar el timing de los ataques, por ejemplo, si se envían tandas de 50 paquetes cada 20ms, seguramente se trate de un ataque.
  • Detectar ID DNS incorrectos en las respuestas que recibe el servidor, es poco habitual que el tráfico legítimo contenga ID incorrectos.

Fuentes

Cientos de miles de contraseñas de Spotify filtradas en un servidor, cambia tu pass

Un grupo consiguió recopilar aproximadamente 350.000 contraseñas de Spotify. No es que el servicio haya sido 'hackeado', sino que los atacantes usaron listas de contraseñas robadas de otros sitios y las comprobaron para crear una base de usuarios que saben que pueden atacar.

El problema en realidad es algo más básico y simple: que la mayoría de la gente usa la misma contraseña en varios servicios. Esto es algo que los atacantes saben muy bien, y por eso, cada vez que hay una filtración de contraseñas se dedican a probarlas en varios sitios.

Hacer algo como esto es realmente simple, y no es necesario tener conocimientos avanzados de ciberseguridad; solo hace falta paciencia y gente dispuesta a ayudar a comprobar las contraseñas, o mejor aún, usar un algoritmo para que lo haga por su cuenta.

  • Tamaño de la bade de datos: 72 GB; 380+ millones de registros
  • Números de usuarios robados: de 300.000 - 350.000
  • Tipos de datos expuestos: correos electrónicos y credenciales de login (username/password)

Reutilizar las contraseñas es el camino fácil para ser hackeados

Una base de datos con semejante cantidad de contraseñas puede ser muy valiosa, si se usa correctamente. Por ejemplo, vendiendo el acceso a cuentas Premium, para disfrutar de las ventajas de Spotify sin pagar. En los últimos años esto se está usando para manipular los resultados de los servicios de streaming; los delincuentes cobran por mejorar las visitas o reproducciones de una canción a cambio de un pago.

Pero se nota mucho que este grupo no tenía estos conocimientos, porque cometieron un error básico a la hora de almacenar estas contraseñas: no pusieron contraseña al servidor. Eso significa que cualquiera podía ver esas contraseñas, sin necesidad de hacer nada, directamente desde el navegador. El mayor desafío era encontrar el servidor, pero eso tampoco es demasiado difícil para quienes van buscando específicamente servidores con mala seguridad. Los investigadores de VPNmentor que han descubierto el servidor no pueden saber si otros lo encontraron antes, o si hicieron una copia de las contraseñas.

Por todo esto, Spotify ha enviado un correo a los usuarios que aparecían en la base de datos, pidiéndoles que cambien la contraseña; también es recomendable cambiar la contraseña de Spotify si es la misma que usamos en otro servicio y utilizar un 2FA.

El aspecto positivo de este descubrimiento es que puede ayudar a bloquear futuros robos de cuentas; entre la información encontrada se encuentran las direcciones IP usadas para acceder al servidor, que asocian a los atacantes con unos servidores 'proxy' usados por este tipo de grupos, lo que podría permitir bloquear el acceso en el futuro.

Fuente: El Español

Vulnerabilidad de doble extensión en Drupal. Parchea YA!

El equipo detrás del popular CMS de Drupal ha lanzado esta semana actualizaciones de seguridad para parchear una vulnerabilidad crítica que es fácil de explotar y puede otorgar a los atacantes un control total sobre los sitios vulnerables.

Registrada como CVE-2020-13671, la vulnerabilidad es ridículamente fácil de explotar y se basa en el viejo truco de la "doble extensión". Los atacantes pueden agregar una segunda extensión a un archivo malicioso, cargarlo en un sitio de Drupal a través de campos de carga abiertos y ejecutarlo.

Drupal, que es actualmente el cuarto CMS más utilizado en Internet después de WordPress, Shopify y Joomla, calificó a la vulnerabilidad como "Crítica", y advirtió a los propietarios de sitios que parcheen lo antes posible.

Por ejemplo, un archivo malicioso como "malware.php" podría cambiarse a "malware.php.txt". Cuando se carga en un sitio Drupal, el archivo se clasificaría como un archivo de texto en lugar de un archivo PHP, pero Drupal terminaría ejecutando el código PHP malicioso al intentar leer el archivo de texto.

Los desarrolladores de Drupal instan a los administradores del sitio a revisar los archivos subidos recientemente. Normalmente, se detectarían archivos con dos extensiones, pero en un aviso de seguridad publicado el miércoles, los desarrolladores de Drupal dijeron que la vulnerabilidad reside en el hecho de que Drupal CMS no desinfecta "ciertos" nombres de archivos, lo que permite que se escapen algunos archivos maliciosos.

Los desarrolladores de Drupal dicen que esto "puede llevar a que los archivos interpreten la extensión incorrecta y sirvan el tipo MIME incorrecto o se ejecuten como PHP para ciertas configuraciones". Se lanzaron actualizaciones de seguridad para las versiones 7, 8 y 9 de Drupal para corregir los procedimientos de desinfección de carga de archivos. Pero el equipo de Drupal también insta a los administradores del sitio a revisar las cargas recientes de archivos con dos extensiones; en caso de que el error haya sido descubierto y explotado por atacantes antes del parche.

Las extensiones "no exhaustiva" a revisar son: phar, php, pl, py, cgi, asp, js, html, htm, phtml.

Es sorprendente que se haya descubierto un error de este tipo en Drupal. El truco de la doble extensión es uno de los más antiguos del libro y es uno de los principales vectores de ataque que los productos CMS validan al procesar los campos de carga.

Se deben instalar las siguiente versiones:

Fuente: ZDNet

22 nov. 2020

Publican casi 50.000 Fortinet vulnerables. Verifica si estas en la lista...

Alguien ha publicado en un foro una lista de casi 50.000 dispositivos VPN de Fortinet vulnerables. En la lista de están presentes los dominios de los principales bancos y organizaciones gubernamentales de todo el mundo. La vulnerabilidad en el portal web FortiOS SSL VPN puede permitir que un atacante no autenticado descargue archivos FortiOS a través de solicitudes HTTP especialmente diseñadas.

La lista de IP no será compartida pero, si alguien desea conocer el estado de una IP particular, puede ingresar a verificarlo en este formulario que hemos creado desde Segu-Info.

La vulnerabilidad a la que se hace referencia aquí es CVE-2018-13379, una falla de Path Traversal identificada en 2018 como FG-IR-18-384 (CVSS 9.8 /10) que afecta a una gran cantidad de dispositivos FortiNet FortiOS SSL VPN sin parchear. La vulnerabilidad fue encontrada en 2018, corregida por Fortinet en mayo de 2019 pero todavía quedan miles de dispositivos sin actualizar.

La vulnerabilidad afecta a: FortiOS 6.0.0 - 6.0.4, FortiOS 5.6.3 - 5.6.7 y FortiOS 5.4.6 - 5.4.12

Al aprovechar esta vulnerabilidad, los atacantes remotos no autenticados pueden acceder a los archivos del sistema a través de solicitudes HTTP especialmente diseñadas.

La lista publicada permite a los atacantes acceder a los archivos sslvpn_websession de las VPN de FortiNet para robar las credenciales de inicio de sesión. Estas credenciales robadas podrían usarse para poner en peligro una red e implementar ransomware. Aunque el error de 2018 se reveló públicamente hace más de un año, los investigadores han detectado alrededor de 50.000 objetivos que aún pueden ser atacados por atacantes.

Esta semana, el analista de inteligencia de amenazas Bank_Security encontró un hilo de un foro donde un actor de amenazas compartió una gran lista de 49.577 dispositivos de tales objetivos explotables.

Después de analizar la lista, se encontró que los objetivos vulnerables incluían dominios gubernamentales de todo el mundo y aquellos que pertenecen a bancos y compañías financieras reconocidos y más de cuatro docenas pertenecían a organizaciones bancarias, financieras y gubernamentales de buena reputación. Entonces, ahora existe un exploit público funcional y alguien ya se ha encargado de filtrar de potenciales víctimas. Se supone que no todas las IPs son verdaderas e incluso algunas de ellas pueden ser honeypots, aunque seguramente el atacante ya recuperó los datos de acceso.

Bank Security analizó la lista de direcciones IP para identificar qué organizaciones se vieron afectadas. "Para saber mejor qué empresas se vieron afectadas, lancé un nslookup en todas las direcciones IP de la lista y, para muchas de ellas, encontré el dominio asociado". Luego, el analista refinó los resultados obtenidos para identificar nombres de dominio asociados con organizaciones de interés y bancos notables. Aunque este es un error antiguo que es trivial de explotar, las organizaciones tienen un proceso de parcheo "muy lento", lo que permite a los atacantes seguir explotando errores conocidos.

El año pasado, los atacantes aprovecharon la misma falla para irrumpir en los sistemas de apoyo a las elecciones del gobierno de EE.UU. Por lo tanto, se recomienda a los administradores de red y profesionales de la seguridad que parcheen esta grave vulnerabilidad de inmediato.

La lista de IP no será compartida pero, si alguien desea conocer el estado de una IP particular, puede ingresar a verificarlo en este formulario que hemos creado desde Segu-Info.

Fuente: BC

Certificación gratuita "Cyber Security Foundation" basada en CyBOK

La empresa CertiProf ha publicado de forma gratuita durante un mes su Certificación Cyber Security Foundation - CSFPC™.

Esta certification está basada en el cuerpo de estudio Cyber Security Body of Knowledge (CyBOK) version 1.0. Este proyecto tiene como objetivo alinear la ciberseguridad con las ciencias más establecidas mediante la extracción de conocimientos de los principales expertos reconocidos internacionalmente para formar su cuerpo de estudio.

El proyecto, fue creado y es financiado por The National Cyber Security Centre 2019 y está dirigido por el profesor Awais Rashid de la Universidad de Bristol, junto con otros expertos líderes en ciberseguridad. 

El libro de estudio también se puede descargar de forma gratuita.

Contenido

  • Module 0: NIST - Cybersecurity for Small Business
  • Module 1: CyBOK - Cybersecurity Fundamentals
  • Module 2: Risk Management
  • Module 3: Law / Regulation
  • Module 4: Human Factors
  • Module 5: Privacy & Online Rights
  • Module 6: Malware & Attack Technologies
  • Module 7: Adversarial Behavior
  • Module 8: Security Operations & Incident Management
  • Module 9: Certification Exam

No hay prerequisitos para rendir la certificación y simplemente hay que leer el libro para afianzar conocimientos.

El examen tiene las siguiente características:

  • Formato: multiple choice
  • Preguntas: 40
  • Idioma: Inglés
  • Puntaje: 28/40 or 70%
  • Duración: 60 minutos
  • Forma de rendir: cuestionario online

Fuente: CertiProf

21 nov. 2020

Múltiples vulnerabilidades graves en VMware

VMware ha lanzado actualizaciones de seguridad para corregir vulnerabilidades críticas y de alta gravedad en VMware ESXi, Workstation, Fusion y Cloud Foundation, lo que permite la ejecución de código y el escalamiento de privilegios.

Las dos vulnerabilidades fueron explotadas con éxito por Xiao Wei y Tianwen Tang del Qihoo 360 Vulcan Team durante el primer día del Concurso de Pwn de la Copa Tianfu 2020. Uno de los errores de seguridad, con una clasificación de gravedad crítica y registrado como CVE-2020-4004, permite a los atacantes con privilegios administrativos locales en una máquina virtual abusar de una vulnerabilidad de uso después de la liberación en el controlador USB XHCI de VMware ESXi, Workstation, y Fusion.

La explotación exitosa permite la ejecución de código como el proceso VMX de la máquina virtual que se ejecuta en el host, un proceso que se utiliza para configurar y alojar instancias de VM.

Una segunda vulnerabilidad, rastreada como CVE-2020-4005 y clasificada como de alta gravedad, permite a los atacantes abusar de un error de escalamiento de privilegios de VMware ESXi de alta gravedad en la forma en que se administran las llamadas al sistema para escalar los privilegios.

"Un actor malintencionado con privilegios dentro del proceso VMX únicamente, puede escalar sus privilegios en el sistema afectado", dice VMware. Sin embargo, explotar CVE-2020-4005 con éxito requiere cambiar con el error de uso después de la liberación del controlador USB XHCI. 

VMware lanzó actualizaciones de seguridad para abordar CVE-2020-4004, pero también proporciona una solución alternativa que implica eliminar el controlador XHCI (USB 3.x) de las máquinas virtuales potencialmente objetivo si no está en uso.

VMware también ha publicado actualizaciones de seguridad para abordar CVE-2020-4005 en todas las versiones vulnerables de VMware ESXi. La compañía todavía está trabajando en el lanzamiento de versiones fijas para VMware Cloud Foundation de ESXi durante los próximos días.

Hace dos días, VMware también parcheó varias vulnerabilidades de gravedad media y alta en el servicio de administración de SD-WAN Orchestrator alojado en la nube y de múltiples inquilinos que podrían conducir a la ejecución de código, acceso no autorizado a datos, ataques Pass-the-Hash y escalamiento de privilegios.

Fuente: BC

Damn Vulnerable Bank: aplicación vulnerable en Android (para aprendizaje)

Damn Vulnerable Bank es una aplicación para Android que simula ser una app de un banco y que nos proporciona una interfaz para realizar pruebas y poder obtener una comprensión detallada de los aspectos internos y de seguridad más comunes.

Aplicación

  • Descargar la apk e instalarla a través de adb o manualmente
  • Abrir la aplicación y agregar la IP de backend en la pantalla de inicio
  • Probar el estado de ejecución presionando verificación de estado
  • Crear una cuenta mediante la opción de registro o signup y luego iniciar sesión con las credenciales
  • Realizar operaciones bancarias
  • Iniciar sesión como administrador para aprobar al beneficiario

Características

  • Sign up/login
  • Interfaz de profile
  • Cambio de contraseña
  • Interfaz de configuración para actualizar la URL del backend
  • Agregar la verificación de fingerprints antes de transferir/ver fondos
  • Agregar chequeo de PIN antes de transferir/ver fondos
  • Ver saldo
  • Transferir dinero
    • Mediante entrada manual
    • Mediante escaneo QR
  • Agregar/Ver beneficiario (eliminar pendiente)
  • Ver historial de transacciones (descarga pendiente)

Construyendo la Apk con ofuscación

  • Ir a Opciones de compilación y seleccionar Generar paquete firmado/APK
  • Luego seleccionar Apk como opción y hacer clic en siguiente
  • Crear un nuevo almacén de claves para firmar el apk y recordar la contraseña
  • Seleccionar ese almacén de claves e ingresar la contraseña
  • Ahora seleccionar Build variant como Release y Signature version como V2
  • Construir (build) la APK

Lista de vulnerabilidades en la aplicación (Alerta de spoiler)

  • Detección de root y emulador
  •  Comprobaciones anti-debugging (evita hooking con frida, jdb, etc.)
  • SSL pinning: pinear el certificado/clave pública
  • Ofuscar todo el código
  • Cifrar todas las solicitudes y respuestas
  • Información confidencial encodeada
  • Fuga de Logcat
  • Almacenamiento inseguro (tal vez números de tarjetas de crédito guardados)
  • Actividades exportadas
  • Token JWT
  • Integración de WebView
  • Deep links
  • IDOR

Autores

Repo: https://github.com/rewanth1997/Damn-Vulnerable-Bank

Fuente: HackPlayers 

20 nov. 2020

TFSec: escáner de seguridad para Terraform


TFSec
es un escáner de seguridad para desarrolladores de plantillas Terraform. Utiliza análisis estático y una integración profunda con el analizador de HCL oficial para garantizar que se puedan detectar problemas de seguridad antes de que los cambios de infraestructura entren en vigor.

Esta diseñado para ejecutarse localmente y en los CI pipelines; brinda una salida amigable para el desarrollador y las comprobaciones completamente documentadas significan que la detección y la corrección pueden llevarse a cabo de la manera más rápida y eficiente posible, para encontrar y solucionar problemas de seguridad.

Se puede utilizar de una imagen Docker o a través de un binario para acoplarlo a los pipelines de compilación. TFSec influye más de 50 tipos de análisis distintos para cada una de las siguientes plataformas.

Fuente:  TFSec

19 nov. 2020

Vulnerabilidad Zerologon y sus exploits públicos

En septiembre se había confirmado que los controladores de dominio Samba anteriores a 4.8 son vulnerables a CVE-2020-1472, una vulnerabilidad de escalada de privilegios CVSS-10 en el proceso de autenticación Netlogon de Microsoft que los autores del documento bautizaron como "Zerologon".

Ahora ya hay varios exploits y PoC públicos disponibles, la mayoría, si no todos, son modificaciones al PoC original de Secura construido en Impacket. Hay informes sobre la explotación activa de la vulnerabilidad e incluso para propagar ransomware.

Además, Benjamin Delpy (aka @gentilkiwi) el creador de la popular herramienta de post-explotación Mimikatz también ha anunciado una nueva versión de la herramienta que integra el soporte de detección y explotación de Zerologon.

Varios hilos sobre los rastros de explotación y las reglas de detección de la comunidad también han llamado la atención de investigadores e ingenieros de seguridad. 

La vulnerabilidad, que se solucionó parcialmente en el lanzamiento del martes de parches de agosto de 2020 de Microsoft, surge de una falla en la implementación criptográfica del protocolo Netlogon, específicamente en su uso del cifrado AES-CFB8. El impacto de una explotación exitosa es enorme: la falla permite el control total de los dominios de Active Directory al comprometer los servidores de Windows que se ejecutan como controladores de dominio; en palabras de Secura, lo que permite que "un atacante con un punto de apoyo en su red interna se convierta esencialmente en administrador de dominio con un solo clic. Todo lo que se requiere es que una conexión con el controlador de dominio sea posible desde el punto de vista del atacante".

Esta conexión RPC se puede realizar directamente o mediante SMB a través de canalizaciones con nombre. El blog de Secura incluye código de prueba de concepto (PoC) que realiza la omisión de autenticación y se puede convertir fácilmente en un arma para su uso en operaciones de atacantes, incluido el ransomware y la propagación de otro malware.

Products afectados

  • Windows Server 2008 R2 for x64-based Systems Service Pack 1
  • Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)
  • Windows Server 2012
  • Windows Server 2012 (Server Core installation)
  • Windows Server 2012 R2
  • Windows Server 2012 R2 (Server Core installation)
  • Windows Server 2016
  • Windows Server 2016 (Server Core installation)
  • Windows Server 2019
  • Windows Server 2019 (Server Core installation)
  • Windows Server, version 1903 (Server Core installation)
  • Windows Server, version 1909 (Server Core installation)
  • Windows Server, version 2004 (Server Core installation)

Se insta a las organizaciones que aún no hayan aplicado las actualizaciones de seguridad de Microsoft del 11 de agosto de 2020 a que consideren parchear CVE-2020-1472 en caso de emergencia. Los clientes de Microsoft que hayan aplicado con éxito las actualizaciones de seguridad de agosto de 2020 pueden implementar el modo de aplicación del controlador de dominio (DC) ahora o después de la actualización del primer trimestre de 2021 que incluye la segunda parte del parche para esta vulnerabilidad.

Microsoft ha publicado una orientación sobre cómo administrar los cambios en las conexiones de canal seguro Netlogon asociadas con esta vulnerabilidad. Para obtener una evaluación más detallada del documento técnico de Secura y una guía, consulte el documento AttackerKB de Zerologon

Referencias

Trump despidió a experto en ciberseguridad por negar fraude en las elecciones

El presidente de los Estados Unidos, Donald Trump, despidió este martes a uno de los máximos expertos en ciberseguridad del gobierno por contradecir sus afirmaciones de que hubo fraude en las elecciones de Estados Unidos.

Se trata de Chris Krebs, quien se desempeñaba como director de ciberseguridad e infraestructura del departamento de Seguridad Nacional (CISA). El funcionario había reiterado su postura en público durante las últimas semanas y, de hecho, había anticipado a algunos de sus colegas que esperaba ser relevado de su cargo por ello.

"La reciente declaración de Chris Krebs sobre la seguridad de las elecciones de 2020 es completamente falsa. Hubo cantidades masivas de fraude, incluyendo votos de gente muerta. A los observadores no se les permitió entrar a los recintos donde se contaban los votos, hubo ‘errores’ en las máquinas de votación que cambiaron los votos de Trump a Biden, hubo votos tardíos y mucho más", comienza el mensaje del mandatario, publicado en su cuenta de Twitter. Y concluye: "En consecuencia, con efecto inmediato, Chris Krebs ha sido despedido de su puesto de director de ciberseguridad e infraestructura del departamento de Seguridad Nacional".

Entre las distintas declaraciones vinculadas a Krebs se destaca una publicada por CISA el pasado viernes, cuando representantes de 11 agencias involucradas en la organización de los comicios aseguraron que "las últimas elecciones fueron las más seguras de la historia. No hay pruebas de que ningún sistema de votación eliminó o perdió votos, cambió votos o estuviera en riesgo de alguna manera", agrega el documento que, en lo que pareció ser una referencia al mandatario, advirtió sobre "muchas afirmaciones infundadas y oportunidades de información errónea sobre el proceso de nuestras elecciones" e instó a los estadounidenses a recurrir a administradores y funcionarios electorales para obtener información precisa.

Con la partida de Krebs, el departamento queda acéfalo. Bryan Ware, director asistente de seguridad cibernética en CISA, quien renunció el pasado jueves por la mañana después de aproximadamente dos años en la agencia. Asimismo, Valerie Boyd, subsecretaria de asuntos internacionales del Departamento de Seguridad Nacional, que supervisa CISA, también se marchó, según otras dos personas. Krebs y Ware habían sido designados por Trump. El primero había logrado apoyo bipartidario en el momento de su designación.

Fuente: Infobae