25 oct. 2020

Tipos de login en sistemas Microsoft

Hoy vamos a hablar de algunos aspectos de los mecanismos de autenticación básicos de los sistemas Microsoft que por comentarios y experiencia sospecho que no todo el mundo conoce.

Es importante conocer en profundidad los sistemas que manejamos, porque si todo va bien, es muy sencillo administrar un "guindo" pero si algún día tienes problemas, o sufres un incidente o tienes que estudiar si estás sufriendo un incidente... conocer estos términos te será fácil.

Vamos a empezar con el proceso de login, el denominado login interactivo. Es el que se produce cuando nos "sentamos" delante del equipo, cuando pulsamos Ctrl+Alt+Supr. Dentro del login interactivo podemos incluir el que realizamos por RDP, podemos imaginar el RDP como un "túnel" en el que nos sitúa delante del pc. Realmente podemos denominarlo login remoto interactivo. 

Cuando realizamos este login, estamos accediendo a la SAM (Security Account Manager) o a un dominio. Es muy importante entender esto. Si usamos un pc de empresa por ejemplo, podemos autenticarnos contra el propio pc, o contra el dominio. Esto se puede modificar, ya lo sabemos, pero es importante entender estos conceptos. Si haces login en la SAM, en local, si entras a una carpeta de red de un pc de dominio, tendrás que autenticarte en el equipo destino. Otro tipo de login interactivo es el que realizamos con una tarjeta, una smart card.

El siguiente grupo de logins es el denominado de red. El que realizas cuando te conectas a un recurso de red, como pueda ser una carpeta compartida o una GPO. Otro tipo de login puede ser como proceso Batch y como servicio.

Otro tipo de login muy interesante es el de la cache. Imagina un portátil corporativo que se inicia en casa del empleado sin haber levantado VPN contra la empresa. Usa las credenciales almacenadas en el equipo, por defecto 10 veces máximo, para autenticarse dentro de un entorno de dominio. Este comportamiento se debe cambiar, si los procesos de la empresa lo permiten, para evitar esta funcionalidad. Imagina un caso muy sencillo: se resetea la clave porque se ha comprometido. El atacante tendría 10 logins "locales" en el equipo hasta que sea obligado a autenticarse contra el DC con la nueva contraseña.

Otro tipo de login, denominada 10 es el que se produce cuando ejecutamos Runas/netonly. Con este parámetro el equipo se ejecutará en local con el usuario que levanta la consola, es decir, el que se logueo en el sistema local, pero si el programa accede a la red, usará el equipo usuario proporcionado con el comando runas.

Una vez explicados los logins, vamos a hablar de los dos grandes proveedores de autenticación en los sistemas Microsoft, NTLM y KERBEROS.

Imagina que un equipo cliente se conecta a un servidor de archivos. Mediante el handshake NTLM se establece una conexión entre PC y cliente, con un desafío o challenge que se cifra con el hash de la contraseña del archivo. El servidor de archivos comprueba la contraseña del cliente consultando al controlador de dominio, quien es el jefazo de la organización y conoce las claves de los usuarios (el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector)

El proceso con Kerberos es algo distinto, ya que el el servidor de archivos no se conecta al DC. El cliente solicita al DC un ticket de servicio para conectarse a un servidor destino, el DC le concede el ticket (el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector) y cuando el cliente se quiere conectar con el dichoso fileserver, le enseña ese ticket.

Voy a poner el ejemplo del parque de atracciones. Una persona entra al parque, y en la caseta le dan una pulsera. Cuando vas a la atracción, enseñas la pulsera. No va el tipo de la atracción a preguntar al de la caseta si realmente esa pulsera es válida. Entiende que si.

Un apunte sobre esta diferencia, cuando hacemos "barra barra" para conectarnos a un recurso de red, si usamos IP en vez de Nombre, estaremos usando NTLM en vez de Kerberos. Existen ataques muy conocidos para NTLM basados en Man-in-the-Middle por lo que es una buena práctica generalizada usar siempre nombres DNS, no direcciones IP.

Tenemos otros proveedores de autenticación en los sistemas Microsoft, estos se denominan SSPI (Security Support Provider Interface) y aquí tienes todos los disponibles

Esta imagen es la típica para explicar qué son estos interfaces.

Aquí aparece el famoso LSASS, el sistema local de autenticación, el encargado de recibir las credenciales del login y según el caso, equipo local (SAM) o dominio (DC) comprobar las credenciales. Otra función básicas del sistema LSA es proporcionar la "cache" de autenticación, es decir, lo que proporciona el Single Sign On del cliente.

De esta manera, las credenciales "suelen" cachearse en memoria, en ese proceso. Haciendo Debug a ese proceso conseguimos obtener las credenciales en memoria con herramientas como Mimikatz.

Una de las guías que más mecanismos de protección presenta es esta del SANS.

Fuente: Kinomakino

23 oct. 2020

GravityRAT: spyware con módulos para MacOS y Android

En 2018, los investigadores de Cisco Talos publicaron un análisis del espía GravityRAT utilizado en ataques selectivos contra las fuerzas armadas de la India. El Centro de respuesta a incidentes de seguridad informática de la India (CERT-IN), fue el primero en descubrir este troyano en 2017. Se atribuye la autoría de esta familia a grupos de hackers paquistaníes. Según conocemos, la campaña ha estado activa desde al menos 2015 y anteriormente estaba dirigida contra equipos con Windows.  Sin embargo, desde 2018 ha sufrido cambios y los dispositivos Android han aparecido en la lista de sus objetivos.

En 2019, en VirusTotal, Kaspersky se topó con un curioso espía para Android y al analizarlo encontron una conexión con GravityRAT. Los atacantes agregaron un módulo espía a la aplicación de Android Travel Mate para viajeros a la India, cuyo código fuente está publicado en Github. De acuerdo con los datos de la compañía, este malware de tipo Remote Access Toolkit (RAT) podría haber estado activo por primera vez en 2015. Sin embargo, por aquel entonces sus capacidades de espionaje se centraban principalmente en sistemas operativos Windows, tal y como también se muestra en el informe de CISCO Talos de 2018, donde se recogían las capacidades del malware para detectar máquinas virtuales a través de la comprobación de la temperatura del sistema, y en cuya publicación ya se mostraban distintas variantes del troyano.

GravityRAT afecta a sistemas operativos Windows, pero por primera vez también se hallaron nuevos módulos que permitirían el espionaje de sistemas MacOS y Android. Según recoge la publicación de Kaspersky, parte del código contenido en estos módulos no es habitual en troyanos de tipo spyware.

En cuanto a las funcionalidades, son las siguientes:

  • Recuperación de datos de dispositivos.
  • Listado de contactos.
  • Listado de direcciones de correo electrónico.
  • Acceso a lista de llamadas.
  • Acceso a mensajes SMS.
  • Acceso a archivos.
Sobre esta última, las muestras investigadas estaban programadas para detectar y enviar al C&C distintos tipos de archivos, tales como logs que se encontraran en la memoria del dispositivo infectado, documentos de texto, hojas de cálculo, imágenes, y otros ficheros con extensiones .xml, .pdf, y .opus, que es el formato en el que se almacenan las notas de voz y audio de la aplicación WhatsApp.

Y es que este troyano ha seguido evolucionando según se puede extraer de lo expuesto y de las palabras de Tatyana Shishkova, experta en seguridad de Kaspersky. La investigadora sostiene que el hecho de que los actores detrás de GravityRAT hayan modificado la muestra para poder afectar a otros sistemas operativos y perpetrar ataques de forma más amplia, apoya la tendencia de que a los creadores de malware no solo les interesan los nuevos desarrollos, sino que también invierten en la evolución del código de malware ya existente, con la intención de tener el mayor éxito posible.

Fuente: SecureList

22 oct. 2020

Hallan sesgos raciales y de género en el reconocimiento facial de Amazon

Un nuevo estudio de MIT encontró que el software de reconocimiento facial de Amazon comete más errores al identificar a mujeres o de tez más oscura. Amazon ha anunciado este miércoles que suspenderá el uso que hace la policía de su controvertida tecnología de reconocimiento facial durante un año, después de que muchos activistas y trabajadores criticaran a la compañía por apoyar a los manifestantes estos días mientras promueve el uso de este desarrollo en los cuerpos de seguridad.

El software de reconocimiento facial de Amazon ha vuelto a generar polémica. Una investigadora del Instituto Tecnológico de Massachusetts (MIT) encontró que Rekognition se desempeña peor al identificar el sexo de un individuo si es mujeres o de tez más oscura.


En el estudio publicado esta semana por el Media Lab de MIT, las pruebas dirigidas por Joy Buolamwini señalan que el software de reconocimiento facial no cometió errores al identificar el género de hombres de piel más clara, pero confundió a mujeres con hombres el 19% de las veces. Además, confundió a mujeres de piel más oscura con hombres el 31% de las veces.

En febrero del año pasado, la investigadora de Media Lab y fundadora de la Liga de Justicia Algorítmica realizó el mismo estudio, en el cual identificó sesgos raciales y de género similares en el software de reconocimiento facial creado por Microsoft, IBM y la firma china Megvii. Después de compartir sus hallazgos, Microsoft e IBM dijeron que mejorarían su software, lo cual ha sido comprobado en este último estudio.

Buolamwini, quien es de ascendencia ghanesa, se dedica a hacer conciencia sobre el sesgo de este tipo de software y a hacer que las empresas hagan su tecnología más precisa, pues el sesgo en los algoritmos es frecuentemente resultado de datos de entrenamiento sesgados.

Ante una audiencia en el Foro Económico Mundial de 2019 en Davos, Suiza, la investigadora explicó que este tipo de software son un "reflejo de las prioridades, las preferencias y también a veces los prejuicios de quienes tienen el poder de dar forma a la tecnología", lo cual ha definido como "la mirada codificada".

Tras haber publicado su estudio en febrero pasado, IBM publicó una base de datos curada que, aseguró, aumentaría la precisión de su software. Por su parte, el presidente ejecutivo de Microsoft, Satya Nadella, habló sobre la necesidad de regular este tipo de tecnología para garantizar estándares más altos en el mercado también durante el Foro Económico Mundial de 2019, según recoge CNBC.

En contraste, Amazon negó que esta investigación sugiriera algo sobre la precisión de su tecnología, de acuerdo con The Verge. De acuerdo con la empresa de Jeff Bezos, los investigadores no usaron en sus pruebas la última versión de Rekognition.

Además, la compañía de Seattle asegura que la prueba de identificación de género era un análisis facial que detecta expresiones y características como el vello facial, pero no una identificación facial que hace coincidir los rostros escaneadas con fotografías. Por tanto, según Amazon, son dos paquetes de software separados.

"No es posible llegar a una conclusión sobre la precisión del reconocimiento facial para ningún caso de uso, incluyendo la aplicación de la ley, sobre la base de los resultados obtenidos mediante el análisis facial", dijo Matt Wood, gerente general de aprendizaje profundo e inteligencia artificial de Amazon Web Services, en un comunicado de prensa, informa The Verge.

En julio de 2018, una investigación de la Unión Estadounidense por las Libertades Civiles (ACLU, por sus siglas en inglés) puso a prueba la tecnología de reconocimiento que Amazon vende a las autoridades estadounidenses, demostrando su margen de error. Según sus hallazgos, Rekognition confundió a 28 miembros del Congreso de los Estados Unidos por personas que habían sido arrestadas por cometer un crimen. Los congresistas eran tanto demócratas como republicanos, así como hombres y mujeres de todas las edades. La compañía atribuyó los resultados a la mala calibración del algoritmo. 

El nuevo estudio de Buolamwini señala:

El potencial de usar como un arma y el abuso de las tecnologías de análisis facial no se puede ignorar ni las amenazas a la privacidad o las violaciones de las libertades civiles menoscabas, incluso a medida que disminuyen las disparidades de precisión.
El software de Rekognition es actualmente usado por el Servicio de Inmigración y Control de Aduanas de los Estados Unidos (ICE), siendo probado en diversos aeropuertos del país, incluyendo el de Los Ángeles, Nueva York y Orlando. Asimismo, Aduanas y Protección Fronteriza (CBP) está probando esta tecnología en la frontera con México.

Fuente: Hipertextual

IPStorm: una botnet al servicio del mejor postor

Ya llevamos algún tiempo hablando de las modalidades de malware as a service, y IPStorm (Interplanetary Storm) podría ser el más reciente ejemplo de ello, así como una muestra de que, en ocasiones, y tras la mano ejecutora de los ciberataques, existen motivaciones diferentes de la pura extorsión y el robo que suelen practicar los ciberdelincuentes. Motivaciones como el espionaje y el sabotaje, los intentos de interferir en procesos para deslegitimizar su resultado, etcétera.

Detectada por primera vez en junio de 2019, la botnet IPStorm [PDF] opera principalmente en Asia, si bien se han detectado acciones en otros lugares del mundo, España entre ellos. Desde mayo de este año, al hilo de una campaña llevada a cabo con la misma y que pudo ser detectada por los honeypots de Bitdefender, la compañía de ciberseguridad ha llevado a cabo una completa investigación de la misma, y la principal conclusión es que IPStorm podría ser ofertada como red proxy anónima para la comisión de actividades ilícitas.

En este periodo de tiempo los investigadores han comprobado que los responsables de IPStorm actualizan el malware de manera constante. Algunas de estas acciones van dirigidas, claro, a mejorar su efectividad, pero también han añadido otras funciones con el fin de hacerlo parecer inofensivo al generar tráfico no relacionable con sus actividades delictivas. Intentar enmascarar las acciones maliciosas entre un conjunto mayor de otras presuntamente legítimas es una técnica que, en casos, provoca que al analizar el conjunto de tráfico, erróneamente se identifique la fuente del mismo como benigna.

La última revisión del malware de IPStorm ataca sistemas basados en Unix y Linux (lo que, entre otros, también incluye Android) con servidor SSH con credenciales débiles, así como servidores ADB (Android Debug Bridge) inseguros. Una vez en los mismos, crea una puerta trasera (backdoor), obtiene los permisos necesarios para poder ejecutar comandos de shell y, como es común en estas redes, se suma a la botnet en la búsqueda de nuevos sistemas para comprometer su seguridad. Todo, claro, a la espera de órdenes por parte de los servidores de comando y control que, en cualquier momento, pueden tomar el control de la red.

Al concluir la investigación, cuyo informe puedes leer aquí, Bitdefender ha determinado que el objetivo principal de la botnet es convertir los dispositivos infectados en proxies como parte de un plan con fines lucrativos, que pasaría por ofrecer a terceros los servicios de la misma. De confirmarse esta conclusión, aquí tendríamos un ejemplo más de que la modalidad as a service tiene bastante recorrido también en el mundo del cibercrimen, y que al igual que ya ocurre desde hace años con las herramientas «point and click» para crear patógenos, cada vez es menos necesario tener conocimientos técnicos para dirigir un ataque.

Fuente: Muy Seguridad

21 oct. 2020

Sandworm: grupo ruso tras muchos ciberataques

En 2017 había otro virus que tenía paralizado al mundo. Con la llegada del covid todo esto puede parecer ciencia ficción pero en junio de hace solo tres años, medio mundo se preparaba para luchar contra otro agente infeccioso que se cobraba víctimas sin parar. Su nombre era NotPetya y se convirtió en uno de los virus que en solo unos meses paralizaron desde grandes compañías a infraestructuras críticas poniendo a la orden del día el frágil sistema de ciberseguridad en el que vivimos. Ahora Estados Unidos asegura saber quién estuvo detrás de aquel virus y de otros grandes ataques cibernéticos y ha lanzado una orden de busca y captura contra ellos.

El FBI acaba de publicar un anuncio a nivel global con la imagen de hasta seis ciudadanos rusos que, según la agencia de seguridad americana, estarían tras "la serie de ataques informáticos más disruptiva y destructiva jamás atribuida a un solo grupo". Todos ellos formarían parte del grupo de oscuros 'hackers' mejor conocido como Sandworm (Gusano de arena), que trabaja en nombre de la Unidad 74455 de la Dirección Principal de Inteligencia de Rusia (más conocida como GRU). ¿Cuál es y ha sido el supuesto objetivo de estos expertos informáticos para realizar estas acciones? Desestabilizar naciones extranjeras, interferir con su política interna y causar pérdidas monetarias, según los agentes.

Así de claro lo asegura el Departamento de Justicia de EEUU que además desgrana la lista de los siete delitos que imputa a cada uno de los seis acusados y que van desde fraude informático a conspiración y están relacionados con las consecuencias del ya mencionado NotPetya (se calcula que el ataque provocó más de 10.000 millones de dólares), ataques a infraestructuras críticas o el intento de injerencia en las últimas elecciones generales francesas. Una ristra de medallas que lleva a preguntarse quiénes son estos expertos y cómo han llegado tan lejos. Y lo cierto es que su historial los convierte incluso en pioneros en este campo.

Como explican en la revista Wired, Sandworm está detrás del primer ataque que consiguió tumbar la electricidad de distintas poblaciones en un ataque realizado contra enclaves ucranianos en 2015, un claro acto de ciberguerra que incluso llegó a impactar en la capital del país, Kiev, en 2016. Tras ello vino NotPetya y su último gran golpe, un ataque malware dirigido contra los sistemas IT de los Juegos Olímpicos de invierno celebrados en Corea del Sur en 2018 y que dejó temblando todo su engranaje. "Es probablemente uno de los grupos de delincuentes informáticos más peligrosos y agresivos que existen", apunta un funcionario del Departamento de Justicia de Estados Unidos.
Anuncio del FBI

Para EEUU las personas tras el gusano son seis hombres de entre 20 y 30 años y que en algunos casos ya son viejos conocidos de las autoridades norteamericanas. Sus nombres son Yuriy Sergeyevich Andrienko, Sergey Vladimirovich Detistov, Pavel Valeryevich Frolov, Artem Valeryevich Ochichenko, Petr Nikolayevich Pliskin y Anatoliy Sergeyevich Kovalevich, este último es el más señalado por las autoridades, ya que en 2016 ya le acusaron de intentar intervenir en las elecciones estadounidenses y además acumula otras cuatro acusaciones. De los 6 que aparecen en el cartel, 5 están relacionados con el ataque a los JJOO y 4 con NotPetya.

El primero de muchos

Estos pioneros también lo serán en cuanto a lo que acusaciones de este tipo se refiere. Aunque EEUU y otros tantos países llevan años avisando de la injerencia rusa y de su apuesta por la ciberguerra, este será el primer caso en el que el país norteamericano señala de forma tan clara y concisa no solo a un grupo de todos los que están relacionados con el GRU y el gobierno ruso, sino a sus propios miembros. Un primer paso celebrado por muchos expertos conocedores de sus movimientos, según recoge Wired y que esperan que sea el primero de muchos.

Sandworm es uno de los equipos más potentes, como deja claro el fiscal del Departamento de Justicia, pero no el único. Hace pocas semanas saltaron a la fama otros grupos muy similares y que todo indica que también están relacionados con agencias rusas como son Fancy Bear o APT28 y Cozy Bear o APT29, sobre todo por el intento de robo de información de las vacunas de distintos laboratorios de Occidente aunque también compañías como Microsoft los han relacionado con intentos de intervención en la campaña de las elecciones presidenciales de EEUU. Un continuo goteo que muestra el poder de Rusia en este sector y su capacidad para la ciberguerra.

Esto lo verbaliza incluso John Demers, fiscal general adjunto de Seguridad Nacional de EEUU, en un comunicado en el que deja claro que "ningún país ha armado sus capacidades cibernéticas de manera tan maliciosa o irresponsable como Rusia, causando daños sin precedentes para perseguir pequeñas ventajas tácticas y satisfacer arrebatos de rencor". A falta de saber si este nuevo paso dado por las autoridades norteamericanas conseguirá aunque sea aumentar la presión sobre los ciberdelincuentes, el gesto demuestra que la lucha cibernética cada vez tiene más peso en nuestro día a día y en el tablero geopolítico.

Fuente: El Confidencial

Los delincuentes aman las herramientas de hacking ofensivo de código abierto (OST)

En el campo de la seguridad, el término OST (Offensive Security Tools) se refiere a aplicaciones de software, bibliotecas y exploits que poseen capacidades de hacking ofensivo y se han lanzado para descargas gratuitas o bajo una licencia de código abierto. Estas herramientas de hacking lanzadas por investigadores de seguridad a menudo también terminan siendo abusadas por "los malos".

Los proyectos OST generalmente se publican para proporcionar un exploit de prueba de concepto para una nueva vulnerabilidad, para demostrar una técnica de hacking nueva (o antigua) o como utilidades de prueba de penetración compartidas con la comunidad.

Hoy en día, OST es uno de los temas más (si no el más) controvertidos en la comunidad de seguridad de la información (infosec). Por un lado, está la gente que está a favor de lanzar tales herramientas, argumentando que pueden ayudar a los defensores a aprender y preparar sistemas y redes para futuros ataques.

En el lado opuesto, están los que dicen que los proyectos OST ayudan a los atacantes a reducir los costos de desarrollar sus propias herramientas y ocultar actividades en una nube de pruebas y pruebas de detección legítimas.

Un mapa interactivo para el uso de OST

Estas discusiones se llevan a cabo durante más de una década. Sin embargo, siempre se han basado en experiencias y convicciones personales, y nunca en datos reales en bruto.

Esto es lo que Paul Litvak, investigador de seguridad de la firma de seguridad cibernética Intezer Labs, ha tratado de abordar a principios de este mes, en una charla en la conferencia de seguridad Virus Bulletin.

Litvak compiló datos sobre 129 herramientas de hacking ofensivo de código abierto y buscó a través de muestras de malware e informes de seguridad cibernética para descubrir qué tan generalizada estaba la adopción de proyectos OST entre grupos de delincuentes, como bandas de malware de bajo nivel, grupos de delincuencia financiera de élite e incluso a nivel nacional -APT patrocinadas por el estado-.

Los resultados se recopilaron en este mapa interactivo. Una versión en PDF de su investigación está disponible aquí.

Los OST más populares

Litvak descubrió que los OST se adoptan ampliamente en todo el ecosistema del ciberdelito. Desde grupos famosos de estados-nación como DarkHotel hasta operaciones de ciberdelito como TrickBot, muchos grupos implementaron herramientas o bibliotecas que habían sido desarrolladas inicialmente por investigadores de seguridad, pero que ahora se utilizan regularmente para el ciberdelito.

"Descubrimos [que] los proyectos adoptados con mayor frecuencia eran las bibliotecas de inyección de memoria y las herramientas RAT. La herramienta de inyección de memoria más popular fue la biblioteca ReflectiveDllInjection, seguida de la biblioteca MemoryModule. Para las RAT [herramientas de acceso remoto], Empire, Powersploit y Quasar fueron los proyectos líderes".

La categoría de movimiento lateral estuvo dominada por Mimikatz, para sorpresa de nadie. Las bibliotecas de derivación de UAC estaban dominadas por la biblioteca de UACME. Sin embargo, los grupos de delincuentes informáticos asiáticos parecían haber preferido Win7Elevate, probablemente debido a la base de instalación regional más grande de Windows 7.

Los únicos proyectos OST que no fueron populares fueron los que implementaron funciones de robo de credenciales. Litvak cree que no eran populares debido a herramientas similares proporcionadas por los sombreros negros en foros de hacking clandestinos, herramientas que vienen con características superiores y que las bandas de malware eligen adoptar en lugar de las herramientas ofensivas proporcionadas por la comunidad de seguridad.

Formas de mitigar el abuso general de OST

Pero Litvak hizo una observación aún más interesante. El investigador dijo que los atacantes rara vez empleaban herramientas OST que implementaban características complejas que requerían un nivel más profundo de comprensión para su uso, incluso si sus capacidades de hacking ofensiva eran obvias.

Continuando con esta observación, Litvak argumenta que los investigadores de seguridad que deseen lanzar herramientas de hacking ofensivas en el futuro también deberían adoptar este enfoque e introducir complejidad en su código, para disuadir a los actores de amenazas de adoptar sus conjuntos de herramientas.

Si esto no es posible, Litvak argumentó que los investigadores de seguridad deberían al menos hacer que su código sea único "rociando la biblioteca con valores especiales o irregulares" para permitir una fácil detección y toma de huellas dactilares. "Por ejemplo, este enfoque fue adoptado por el autor de Mimikatz, donde la vida útil de un ticket generado se deja en 10 años por defecto, un número muy irregular", dijo Litvak.

Fuente: ZDNet

20 oct. 2020

Explotan vulnerabilidades en SS7 para robar cuenta de Telegram y email

Se explotó la vulnerabilidad del protocolo de telecomunicaciones SS7, para dirigirse a 20 criptoejecutivos. A pesar de que se desarrolló por primera vez en 1975, el protocolo SS7 actualmente se utiliza de manera generalizada en todo el mundo.

Se cree que los estafadores han intentado interceptar los códigos de autenticación de dos factores de las víctimas en un ataque contra la empresa de telecomunicaciones Partner Communications Company, con sede en Israel, antes conocida como Orange Israel. El mes pasado varios delincuentes comprometieron las cuentas de mensajería de Telegram y de correo electrónico de varios ejecutivos de criptomonedas al explotar una vulnerabilidad en el protocolo creado hace décadas.

La Autoridad Nacional de Seguridad Cibernética de Israel y el organismo nacional de inteligencia del Mossad actualmente están investigando los ataques. Según la publicación de Bleeping Computer, los dispositivos de al menos 20 suscriptores de Partner Communications Company fueron puestos en peligro.

El análisis del evento realizado por la empresa Pandora Security, con sede en Israel, sugiere que es probable que los dispositivos hayan sido violados a través de un ataque al Signaling System 7 (SS7). Este sistema de señalización comprende un conjunto de protocolos que se utilizan para facilitar el intercambio de información dentro de las redes telefónicas públicas conmutadas que interactúan a través de las redes de señalización digital.

Los atacantes pueden explotar el SS7 para interceptar mensajes de texto y llamadas utilizando una función de itinerancia y "actualizando la ubicación de su dispositivo como si estuviera registrado en una red diferente".

El cofundador de Pandora, Tsashi Ganot, advirtió que los gobiernos nacionales deben actualizar su infraestructura de telecomunicaciones para protegerse contra las amenazas modernas a la seguridad. Dijo que los delincuentes también se habían hecho pasar por sus víctimas en Telegram en intentos infructuosos de atraer a conocidos cercanos para hacer operaciones de criptomonedas:

Los ataques al SS7 son semejantes al intercambio de SIM que reasigna el número de teléfono asociado a la tarjeta SIM de la víctima a un dispositivo bajo el control de los atacantes. Los proveedores de telecomunicaciones con sede en los Estados Unidos se han enfrentado a múltiples demandas de clientes ejecutivos de criptomonedas que han sido blanco de ataques de intercambio de SIM.

Fuente: BC

Cómo prevenir las 11 amenazas en Cloud Computing [II]

Los últimos riesgos involucrados en la computación en la nube apuntan a problemas relacionados con la configuración y la autenticación en lugar del enfoque tradicional en el malware y las vulnerabilidades, según un nuevo informe de Cloud Security Alliance.

El uso de la nube para alojar los datos, las aplicaciones y otros activos de su empresa ofrece varios beneficios en términos de administración, acceso y escalabilidad. Pero la nube también presenta ciertos riesgos de seguridad. Tradicionalmente, esos riesgos se han centrado en áreas como denegación de servicio, pérdida de datos, malware y vulnerabilidades del sistema. El informe argumenta que las últimas amenazas en la seguridad de la nube ahora se han trasladado a decisiones tomadas en torno a la estrategia e implementación de la nube.

Este artículo también está disponible para descargar en inglés: Cómo prevenir las 11 amenazas principales en la computación en la nube [PDF en inglés].

Los 5 puntos anteriores se pueden leer aquí: Cómo prevenir las 11 amenazas en Cloud Computing.

6. Amenazas internas (Insiders)

Los insiders no tienen que atravesar firewall, VPN u otras defensas de seguridad y, en su lugar, operan en un nivel confiable donde pueden acceder directamente a redes, sistemas informáticos y datos confidenciales.

Impacto de negocios

  • Las amenazas internas pueden resultar en la pérdida de información patentada y propiedad intelectual.
  • El tiempo de inactividad del sistema asociado con los ataques internos puede afectar la productividad de la empresa.
  • La pérdida de datos puede reducir la confianza en los servicios de la empresa.
  • Tratar con incidentes de seguridad interna requiere contención, remediación, respuesta a incidentes, investigación, análisis posterior a incidentes, escalado, monitoreo y vigilancia, todo lo cual puede sumarse a la carga de trabajo y al presupuesto de seguridad de una empresa.

Conclusiones y recomendaciones clave

  • Tome medidas para minimizar la negligencia interna para mitigar las consecuencias de las amenazas internas.
  • Brinde capacitación a sus equipos de seguridad para instalar, configurar y monitorear adecuadamente sus sistemas informáticos, redes, dispositivos móviles y dispositivos de respaldo.
  • Brinde capacitación a sus empleados habituales para informarles cómo manejar los riesgos de seguridad, como el phishing y la protección de los datos corporativos que llevan fuera de la empresa en computadoras portátiles y dispositivos móviles.
  • Se requieren contraseñas seguras y actualizaciones frecuentes de contraseñas.
  • Informar a los empleados de las repercusiones relacionadas con la participación en actividades maliciosas.
  • Audite de forma rutinaria los servidores en la nube y en las instalaciones, y luego corrija cualquier cambio desde la línea de base segura establecida en toda la organización.
  • Asegúrese de que los sistemas de seguridad de acceso privilegiado y los servidores centrales estén limitados a un número mínimo de empleados, y que estas personas incluyan solo a aquellos con la capacitación para manejar la administración de servidores informáticos de misión crítica.
    Supervise el acceso a todos los servidores informáticos en cualquier nivel de privilegio.

7. Interfaces y API inseguras

Las API (Interfaces de Programación de Aplicaciones) y las UI (Interfaces de Usuario) suelen ser las partes más expuestas de un sistema, a menudo el único activo con una dirección IP pública disponible fuera del límite de confianza.

Desde la autenticación y el control de acceso hasta el cifrado y el monitoreo de la actividad, estas interfaces deben diseñarse para proteger contra intentos tanto accidentales como maliciosos de eludir la seguridad.

Impacto de negocios

  • Aunque la mayoría de los proveedores de la nube intentan integrar la seguridad en sus modelos, los clientes de la nube también deben comprender las implicaciones de seguridad.
  • Un conjunto débil de interfaces y API expone a las organizaciones a varios problemas de seguridad relacionados con la confidencialidad, integridad, disponibilidad y responsabilidad.

Conclusiones y recomendaciones clave

  • Practique una buena higiene de API. Esto incluye la supervisión diligente de elementos como inventarios, pruebas, auditorías y protecciones de actividad anormal.
  • Asegure la protección adecuada de las claves API y evite la reutilización.
  • Considere la posibilidad de utilizar frameworks de API abiertos y estándar; por ejemplo Open Cloud Computing Interface (OCCI) e Cloud Infrastructure Management Interface (CIMI).

8. Plano de control débil

El plano de control habilita la seguridad y la integridad para complementar el plano de datos, que proporciona la estabilidad de los datos. Un plano de control débil significa que la persona a cargo no tiene el control total de la lógica, la seguridad y la verificación de la infraestructura de datos.

Impacto de negocios

  • Un plano de control débil podría provocar la pérdida de datos, ya sea por robo o corrupción.
  • También se puede incurrir en sanciones reglamentarias por la pérdida de datos.
  • Con un plano de control débil, es posible que los usuarios tampoco puedan proteger sus aplicaciones y datos comerciales basados ​​en la nube.

Conclusiones y recomendaciones clave

  • Los controles de seguridad adecuados proporcionados a través de un proveedor de nube son necesarios para que los clientes de la nube puedan cumplir con sus obligaciones legales y estatutarias.
  • Los clientes de la nube deben realizar la debida diligencia y determinar si el servicio en la nube que pretenden utilizar posee un plano de control adecuado.

9. Fallos de la metaestructura y de la aplicación

Existen fallas potenciales en múltiples niveles en el modelo de metaestructura y aplicación. Por ejemplo, la implementación deficiente de la API por parte del proveedor de la nube ofrece a los atacantes la oportunidad de interrumpir a los clientes de la nube la confidencialidad, la integridad o la disponibilidad del servicio.

Impacto de negocios

  • La metaestructura y la estructura de la aplicación son componentes críticos de un servicio en la nube. Las fallas que involucran estas características a nivel de proveedor de nube pueden afectar gravemente a todos los consumidores de servicios.
  • Al mismo tiempo, las configuraciones incorrectas por parte del cliente podrían perturbar al usuario financiera y operativamente.

Conclusiones y recomendaciones clave

  • Los proveedores de la nube deben ofrecer visibilidad y exponer las mitigaciones para contrarrestar la falta de transparencia inherente de la nube para los clientes.
  • Los clientes de la nube deben implementar funciones y controles adecuados en los diseños nativos de la nube.
  • Todos los proveedores de la nube deben realizar pruebas de penetración y proporcionar hallazgos a los clientes.

10. Visibilidad limitada del uso de la nube

La visibilidad limitada del uso de la nube ocurre cuando una organización no tiene la capacidad de visualizar y analizar si el uso del servicio en la nube dentro de la organización es seguro o malicioso.

Impacto de negocios

  • Falta de gobernanza. Cuando los empleados no están familiarizados con el acceso adecuado y los controles de gobierno, los datos corporativos confidenciales se pueden colocar en ubicaciones de acceso público en lugar de en ubicaciones de acceso privado.
  • Falta de conciencia. Cuando los datos y los servicios están en uso sin el conocimiento de la empresa, no pueden controlar su IP. Eso significa que el empleado tiene los datos, no la empresa.
  • Falta de seguridad. Cuando un empleado configura incorrectamente un servicio en la nube, puede volverse explotable no solo para los datos que residen en él, sino también para datos futuros.
  • El malware, las redes de bots, el malware de minería de criptomonedas y más pueden comprometer los contenedores en la nube, poniendo datos organizacionales, servicios y finanzas en riesgo.

Conclusiones y recomendaciones clave

  • La mitigación de estos riesgos comienza con el desarrollo de un esfuerzo completo de visibilidad de la nube de arriba hacia abajo. Este proceso generalmente comienza con la creación de una solución integral que se vincule con las personas, los procesos y la tecnología.
  • Solicite capacitación a toda la empresa sobre las políticas y el cumplimiento de uso de la nube aceptados.
  • Todos los servicios en la nube no aprobados deben ser revisados ​​y aprobados por el arquitecto de seguridad en la nube o la administración de riesgos de terceros.
  • Invierta en soluciones como agentes de seguridad de acceso a la nube (CASB) o puerta de enlace definida por software (SDG) para analizar las actividades salientes y ayudar a descubrir el uso de la nube, los usuarios en riesgo y seguir el comportamiento de los empleados con credenciales para identificar anomalías.
  • Invierta en un firewall de aplicaciones web (WAF) para analizar todas las conexiones entrantes a sus servicios en la nube en busca de tendencias sospechosas, malware, denegación de servicio distribuida (DDoS) y riesgos de botnet.
  • Seleccione soluciones que estén diseñadas específicamente para monitorear y controlar todas sus aplicaciones empresariales clave en la nube (planificación de recursos empresariales, gestión de capital humano, experiencia comercial y gestión de la cadena de suministro) y garantizar que se puedan mitigar los comportamientos sospechosos.
  • Implemente un modelo de confianza cero en toda su organización.

11. Abuso y uso nefasto de los servicios en la nube

Los actores maliciosos pueden aprovechar los recursos de computación en la nube para dirigirse a usuarios, organizaciones u otros proveedores de la nube, y también pueden alojar malware en los servicios en la nube. Algunos ejemplos del uso indebido de los recursos de la nube incluyen: lanzamiento de ataques DDoS, campañas de correo electrónico no deseado y phishing, "extracción" de moneda digital, fraude de clics automatizado a gran escala, ataques de fuerza bruta de bases de datos de credenciales robadas y alojamiento de contenido malicioso o pirateado.

Impacto de negocios

  • Si un atacante ha comprometido el plano de gestión de la infraestructura en la nube de un cliente, el atacante puede utilizar el servicio en la nube con fines ilícitos mientras el cliente paga la factura. La cuenta podría ser sustancial si el atacante consumiera recursos sustanciales, como la minería de criptomonedas.
  • Los atacantes también pueden usar la nube para almacenar y propagar malware. Las empresas deben tener controles para hacer frente a estos nuevos vectores de ataque. Esto puede significar la adquisición de tecnología de seguridad que pueda monitorear la infraestructura en la nube o las llamadas API desde y hacia el servicio en la nube.

Conclusiones y recomendaciones clave

  • Las empresas deben monitorear a sus empleados en la nube, ya que los mecanismos tradicionales no pueden mitigar los riesgos que plantea el uso de servicios en la nube.
  • Emplee tecnologías de prevención de pérdida de datos (DLP) en la nube para monitorear y detener cualquier exfiltración de datos no autorizada.

"La complejidad de la nube puede ser el lugar perfecto para que los atacantes se escondan, ofreciendo ocultación como plataforma de lanzamiento para un daño mayor", dijo John Yeoh, vicepresidente global de investigación de CSA, en un comunicado de prensa. "El desconocimiento de las amenazas, los riesgos y las vulnerabilidades hace que sea más difícil proteger a las organizaciones de la pérdida de datos. Los problemas de seguridad descritos en esta iteración del informe Top Threats, por lo tanto, son un llamado a la acción para desarrollar y mejorar la concientización, configuración y gestión de identidad".

Fuente: TechRepublic

19 oct. 2020

2BaGoldMule: Operación internacional contra casos de lavado de dinero con criptomonedas

En los últimos días hubo una oleada de redadas, arrestos y cargos en todo el mundo contra el lavado de dinero mediante criptomonedas. El 15 de octubre, Europol anunció una operación exitosa a lo largo de 16 países que resultó en el arresto de 20 personas sospechosas de trabajar para la red criminal QQAAZZ.

La organización está acusada de lavar decenas de millones de euros para los principales ciberdelincuentes desde 2016. Los fondos supuestamente se transfieren a través de cuentas bancarias internacionales, empresas fantasma con sede en Polonia y Bulgaria y mediante servicios de mezcla de criptomonedas.

Se registraron alrededor de 40 sitios en Reino Unido, España, Italia, Letonia y Bulgaria como parte de la "Operación 2BaGoldMule", con arrestos realizados en Australia, Estados Unidos, Reino Unido, Portugal, España, Letonia y Polonia.


Mapa de países participantes y detenciones: Europol

El uso de criptomonedas con fines criminales se ha puesto en evidencia una vez más con la última acusación del Departamento de Justicia de los EE.UU. contra una red de lavado de dinero para carteles de drogas en México.

El mismo día, un hombre de 40 años fue arrestado en Nueva Zelanda por usar criptomonedas para lavar más de $2 millones de dólares para criminales. El hombre también lavó fondos comprando vehículos de lujo, incluidos un Lamborghini y un Mercedes G63. El residente de Auckland ahora enfrenta 30 cargos, incluidas acusaciones de obtener $1 millón en crédito de un banco usando el mismo método. Otros seis neozelandeses fueron arrestados en una serie de redadas y confiscaciones de activos en todo el país el día anterior.

El 15 de octubre se produjo también la apertura por parte del Departamento de Justicia de EE.UU. de una acusación sustitutiva en la que se acusaba a seis personas de participar en una conspiración para "lavar millones de dólares producto de la droga en nombre de cárteles extranjeros".

La acusación formal alega que los individuos utilizaron casinos, empresas falsas, contrabando de efectivo y cuentas bancarias para lavar dinero en nombre de los sindicatos de la droga. Un sospechoso también está acusado de planear sobornar a un funcionario del Departamento de Estado de los Estados Unidos utilizando criptomonedas, con la esperanza de que el funcionario creara pasaportes estadounidenses fraudulentos para él y sus asociados.

El Departamento de Justicia de los Estados Unidos realizó una acusación formal el pasado 15 de octubre del 2020 contra seis individuos acusados de lavar millones de dólares de ganancias de drogas en nombre de carteles mexicanos.

El archivo publicado en el sitio oficial del organismo de justicia estadounidense, va en contra de seis personas de origen asiático acusados de participar en una conspiración de un año para usar casinos, compañías fantasmas, efectivo, criptomonedas y cuentas bancarias en los EE.UU. , para blanquear dinero en nombre de organizaciones de tráfico de drogas de México.

Según el documento, la acusación también alega que uno de los implicados "planeaba sobornar a un funcionario del Departamento de Estado de los EE.UU. Mediante transferencias bancarias y criptomonedas para crear pasaportes estadounidenses que ésta persona y sus socios usarían para ingresar a los Estados Unidos".

Las acusaciones son resultados de una investigación encubierta de siete meses, además del trabajo general realizado contra la redes asiáticas de lavado de dinero en los Estados Unidos, China y otros lugares no especificados por espacio de cuatro años por el Departamento de Justicia.

El caso fue investigado como parte de dos Grupos de Trabajo de Lucha contra las Drogas del Crimen Organizado "OCDETF", un grupo de trabajo de múltiples agencias y jurisdicciones que proporciona fondos federales a las agencias involucradas en la lucha contra el tráfico de drogas.

Además, el Departamento de Justicia contó con la colaboración de organismo de México, Australia, Nueva Zelanda y Guatemala durante esta investigación, que ha llevado a cinco de las seis personas tras las rejas por los delitos de tráficos de drogas y lavado de dinero.

Los seis delincuentes según el informe, se comunicaban la mayoría de las actividades ilícitas entre ellos a través de aplicaciones de mensajería móvil como WhatsApp y WeChat, y trabajaban como una organización cuya tarea consistía en ayudar a los carteles de la droga en México a lavar millones de dólares producto de las ganancias por el tráfico de estupefacientes.

Drogas y criptomonedas

No es la primera vez que las criptomonedas aparecen entre los archivos de acusaciones de los organismos de justicia como medio de pago o blanqueo de capitales de dinero proveniente de actividades ilícitas

Desde el célebre caso de Silk Road en el 2013, el uso de Bitcoin y otras criptomonedas ha estado a la orden del día para criminales y organizaciones especializadas en el blanqueo de capitales en todo el mundo, tal cómo ocurre con el dólar americano.


El pasado mes de julio de este año, las fuerzas del orden estadounidense anunciaban en ese sentido que estaban vigilando la compra de drogas con Bitcoin en la darknet , o mejor conocida como la 'web oscura'.

El NCIS señalaba en ése entonces, que había visto un aumento en las compras en la darknet usando Bitcoin de estupefacientes por parte de usuarios en suelo americano.

Según el informe de CipherTrace sobre delitos de criptomonedas y Contra Lavado de Dinero de la primavera de 2020, el promedio mundial de fondos delictivos directos recibidos por los exchanges disminuyó en un 47% en 2019. Esto demuestra un mínimo en tres años para los exchanges de criptomonedas en todo el mundo, ya que sólo el 0,17% de los fondos recibidos por los exchanges en 2019 proceden de fuentes delictivas.

Fuente: CoinTelegraph

Arquitectura CHERI podría reducir la cantidad de parches de MS y permitir el desarrollo de apps seguras

Microsoft, que publica unos 100 parches cada mes, está trabajando en una nueva arquitectura experimental que podría ser incluso más valiosa y barata que migrar a Rust. Desde hace algún tiempo, Rust ha sido visto como un potencial reemplazo de C++ en lo relativo a escribir algunos componentes de Windows.

Hay quienes consideran que C++ es anticuado y la propia Microsoft incluso reconoce que el cambio a Rust podría eliminar la necesidad constante de parches de seguridad. Tal suposición se debe principalmente a que la mayoría de las vulnerabilidades gravitan en torno a la seguridad de la memoria, aspecto supuestamente inherente a C++.

Sin embargo, hay razones para suponer que Microsoft no migrará a Rust a corto plazo, ya que la compañía está trabajando en una nueva arquitectura experimental que podría ser aún más valiosa.

Llamado CHERI (Capability Hardware Enhanced RISC), la infraestructura podría haber mitigado cerca de dos tercios de las vulnerabilidades de seguridad de la memoria que tuvieron que ser parcheadas en 2019, según ZDNet .

"[CHERI] proporciona características de protección de la memoria contra muchas vulnerabilidades explotadas, o en otras palabras, una solución arquitectónica que desbarata los expoits", explicaron Nicolas Joly, Saif ElSherei y Saar Amar del Centro de Respuesta de Seguridad de Microsoft.

El trabajo en las arquitecturas de conjuntos de instrucciones (ISA) de CHERI está en marcha en la Universidad de Cambridge en asociación con el diseñador de chips RISC Arm y Microsoft. CHERI tiene objetivos similares a Project Verona, el desarrollo de lenguaje experimental inspirado en Rust de Microsoft para la programación de infraestructura segura. Un portavoz de la Universidad de Cambridge añadió que "CHERI amplía las arquitecturas convencionales de conjuntos de instrucciones de hardware (ISA) con nuevas características arquitectónicas para permitir una protección de la memoria granular y una compartimentación del software altamente escalable".

CHERI tiene características de protección de memoria que adaptarían los lenguajes de programación históricamente inseguros para la memoria y los harían más seguros contra vulnerabilidades ampliamente explotadas. El equipo de Microsoft revisó la séptima versión de CHERI ISA, la última versión de CHERI. Los investigadores también utilizaron CheriBSD, basado en el sistema operativo FreeBSD con protección de memoria y funciones de compartimentación de software compatibles con CHERI ISA. "Evaluamos de manera conservadora el porcentaje de vulnerabilidades informadas al Centro de respuesta de seguridad de Microsoft en 2019 y descubrimos que aproximadamente el 31% ya no representaría un riesgo para los clientes y, por lo tanto, no sería necesario abordarlo mediante una actualización de seguridad en un sistema CHERI basado en la configuración predeterminada. del sistema operativo CheriBSD", escribieron los investigadores de Microsoft en el artículo de investigación.

Fuente: ZDNet