Yaakov's Group | Ciberseguridad

¿Es segura su tarjeta con chip? Esto depende de su Banco

Las tarjetas de crédito y débito basadas en chips están diseñadas para que no sea factible que los dispositivos de descremado o malware clonen su tarjeta cuando paga algo sumergiendo el chip en lugar de deslizar la banda. Pero una serie reciente de ataques de malware contra comerciantes con sede en los EE. UU. Sugiere que los ladrones están explotando las debilidades en cómo ciertas instituciones financieras han implementado la tecnología para eludir las características clave de seguridad de las tarjetas con chip y crear efectivamente tarjetas falsificadas utilizables.

Las tarjetas de pago tradicionales codifican los datos de la cuenta del titular de la tarjeta en texto sin formato en una banda magnética, que puede leerse y registrarse mediante dispositivos de descremado o software malicioso instalado subrepticiamente en terminales de pago. Esos datos pueden codificarse en cualquier otra cosa con una banda magnética y usarse para realizar transacciones fraudulentas.

Las nuevas tarjetas basadas en chips emplean una tecnología conocida como EMV que encripta los datos de la cuenta almacenados en el chip. La tecnología hace que se genere una clave de cifrado única, denominada token o «criptograma», cada vez que la tarjeta con chip interactúa con un terminal de pago con capacidad de chip.

Prácticamente todas las tarjetas basadas en chips aún tienen gran parte de los mismos datos almacenados en el chip codificado en una banda magnética en la parte posterior de la tarjeta. Esto se debe principalmente a razones de compatibilidad con versiones anteriores, ya que muchos comerciantes, particularmente aquellos en los Estados Unidos, aún no han implementado completamente los lectores de tarjetas con chip. Esta doble funcionalidad también permite a los titulares de tarjetas deslizar la banda si, por algún motivo, el chip de la tarjeta o el terminal habilitado para EMV de un comerciante no funciona correctamente.

Pero existen diferencias importantes entre los datos del titular de la tarjeta almacenados en chips EMV y las bandas magnéticas. Uno de ellos es un componente en el chip conocido como un valor de verificación de tarjeta de circuito integrado o «iCVV» para abreviar, también conocido como «CVV dinámico».

El iCVV difiere del valor de verificación de tarjeta (CVV) almacenado en la banda magnética física, y protege contra la copia de datos de banda magnética del chip y el uso de esos datos para crear tarjetas de banda magnética falsificadas. Tanto los valores de iCVV como de CVV no están relacionados con el código de seguridad de tres dígitos que está impreso visiblemente en el reverso de una tarjeta, que se utiliza principalmente para transacciones de comercio electrónico o para la verificación de la tarjeta por teléfono.

El atractivo del enfoque EMV es que, incluso si un skimmer o malware logra interceptar la información de la transacción cuando se sumerge una tarjeta con chip, los datos solo son válidos para esa transacción y no deberían permitir que los ladrones realicen pagos fraudulentos en el futuro.

Sin embargo, para que las protecciones de seguridad de EMV funcionen, se supone que los sistemas de back-end implementados por las instituciones financieras emisoras de tarjetas deben verificar que cuando una tarjeta chip se sumerge en un lector de chips, solo se presenta el iCVV; y viceversa, que solo se presenta el CVV cuando se desliza la tarjeta. Si de alguna manera no se alinean para un tipo de transacción determinado, se supone que la institución financiera rechazará la transacción.

El problema es que no todas las instituciones financieras han configurado adecuadamente sus sistemas de esta manera. Como era de esperar, los ladrones han sabido de esta debilidad durante años. En 2017, escribí sobre la creciente prevalencia de «shimmers», dispositivos de alta tecnología para descremado de tarjetas diseñados para interceptar datos de transacciones con tarjetas con chip.

Más recientemente, los investigadores de Cyber ​​R&D Labs publicaron un documento que detalla cómo probaron 11 implementaciones de tarjetas con chip de 10 bancos diferentes en Europa y los EE. UU. Los investigadores descubrieron que podían recolectar datos de cuatro de ellos y crear tarjetas de banda magnética clonadas que se utilizaron con éxito para realizar transacciones

Ahora hay fuertes indicios de que el malware detallado en el punto de venta (POS) está utilizando el mismo método detallado por Cyber ​​R&D Labs para capturar datos de transacciones de EMV que luego se pueden revender y utilizar para fabricar copias en banda magnética de tarjetas basadas en chips.

A principios de este mes, la red de tarjetas de pago más grande del mundo, Visa, lanzó una alerta de seguridad con respecto a un reciente compromiso comercial en el que las familias conocidas de malware POS aparentemente fueron modificadas para apuntar a terminales POS habilitados con chips EMV.

“La implementación de la tecnología de aceptación segura, como el chip EMV®, redujo significativamente la usabilidad de los datos de la cuenta de pago por parte de los actores de amenazas, ya que los datos disponibles solo incluían el número de cuenta personal (PAN), el valor de verificación de la tarjeta de circuito integrado (iCVV) y la fecha de vencimiento «, Escribió Visa. “Por lo tanto, siempre que iCVV esté validado correctamente, el riesgo de fraude falsificado fue mínimo. Además, muchas de las ubicaciones comerciales empleaban encriptación punto a punto (P2PE) que encriptaba los datos de PAN y reducía aún más el riesgo para las cuentas de pago procesadas como Chip EMV® ”.

Visa no nombró al comerciante en cuestión, pero algo similar parece haber sucedido en Key Food Stores Co-Operative Inc., una cadena de supermercados en el noreste de los Estados Unidos. Key Food reveló inicialmente un incumplimiento de tarjeta en marzo de 2020, pero hace dos semanas actualizó su aviso para aclarar que los datos de transacciones EMV también fueron interceptados.

«Los dispositivos POS en las tiendas involucradas estaban habilitados para EMV», explicó Key Food. «Para las transacciones EMV en estas ubicaciones, creemos que el malware no habría encontrado el número de tarjeta y la fecha de vencimiento (pero no el nombre del titular de la tarjeta o el código de verificación interno).

Si bien la declaración de Key Food puede ser técnicamente precisa, pasa por alto la realidad de que los estafadores aún podrían utilizar los datos robados de EMV para crear versiones de banda magnética de tarjetas EMV presentadas en los registros de tiendas comprometidas en los casos en que el banco emisor de la tarjeta no EMV implementado correctamente.

Hoy temprano, la firma de inteligencia de fraude Gemini Advisory publicó una publicación en el blog con más información sobre compromisos comerciales recientes, incluido Key Food, en el que los datos de transacciones de EMV fueron robados y terminaron a la venta en tiendas la dark web que atienden a ladrones de tarjetas.

«Las tarjetas de pago robadas durante esta violación se ofrecieron a la venta en la dark web «, explicó Gemini. «Poco después de descubrir esta violación, varias instituciones financieras confirmaron que las tarjetas comprometidas en esta violación se procesaron todas como EMV y no confiaron en la banda magnética como alternativa».

Gemini dice que ha verificado que otra violación reciente, en una tienda de licores en Georgia, también resultó en datos de transacciones EMV comprometidas que se muestran a la venta en tiendas dark web  que venden datos de tarjetas robadas. Como han señalado tanto Gemini como Visa, en ambos casos la verificación adecuada de iCVV por parte de los bancos debería hacer que estos datos EMV interceptados sean inútiles para los delincuentes.

Géminis determinó que debido a la gran cantidad de tiendas afectadas, es extremadamente improbable que los ladrones involucrados en estas violaciones interceptaran los datos de EMV utilizando reflectores de tarjetas EMV instalados físicamente.

«Dada la extrema impracticabilidad de esta táctica, probablemente utilizaron una técnica diferente para violar de forma remota los sistemas POS para recopilar suficientes datos EMV para realizar la clonación de derivación EMV», escribió la compañía.

Stas Alforov, director de investigación y desarrollo de Gemini, dijo que las instituciones financieras que no realizan estos controles corren el riesgo de perder la capacidad de darse cuenta cuando esas tarjetas se usan para fraude.

Esto se debe a que muchos bancos que han emitido tarjetas basadas en chips pueden asumir que, siempre y cuando esas tarjetas se usen para transacciones con chips, prácticamente no hay riesgo de que las tarjetas se clonen y se vendan en la dark web. Por lo tanto, cuando estas instituciones buscan patrones en transacciones fraudulentas para determinar qué comerciantes pueden verse comprometidos por el malware POS, pueden descontar por completo los pagos basados ​​en chips y centrarse solo en aquellos comerciantes en los que un cliente ha deslizado su tarjeta.

«Las redes de tarjetas se están dando cuenta del hecho de que hay muchas más infracciones basadas en EMV en este momento», dijo Alforov. «Los emisores de tarjetas más grandes, como Chase o Bank of America, de hecho están verificando [para detectar una falta de coincidencia entre el iCVV y el CVV], y eliminarán las transacciones que no coinciden. Pero claramente ese no es el caso con algunas instituciones más pequeñas ”.

Para bien o para mal, no sabemos qué instituciones financieras no han podido implementar correctamente el estándar EMV. Es por eso que siempre vale la pena vigilar de cerca sus estados de cuenta mensuales e informar de inmediato cualquier transacción no autorizada. Si su institución le permite recibir alertas de transacciones por mensaje de texto, esta puede ser una forma casi en tiempo real de estar atento a dicha actividad.

Fuente: Krebxs on Security

Nuevos protocolos de red abusados para lanzar ataques de denegación de servicio distribuido a gran escala (DDoS)

La Oficina Federal de Investigación emitió una alerta la semana pasada advirtiendo sobre el descubrimiento de nuevos protocolos de red que han sido explotados para lanzar ataques de denegación de servicio distribuido a gran escala (DDoS).

La alerta registra tres protocolos de red y una aplicación web como vectores de ataque DDoS recién descubiertos.

La lista incorpora CoAP (Protocolo de aplicación restringida), WS-DD (Descubrimiento dinámico de servicios web), ARMS (Servicio de administración remota de Apple) y el software de automatización basado en la web de Jenkins.

Tres de los cuatro (CoAP, WS-DD, ARMS) acaban de ser explotados en realidad para lanzar monstruosos ataques DDoS, dijo el FBI dependiendo de los informes anteriores de ZDNet.

COAP

En diciembre de 2018, los actores cibernéticos comenzaron a explotar las funciones de transmisión de comandos y multidifusión del Protocolo de aplicación restringida (CoAP) para liderar la reflexión DDoS y los ataques de amplificación, generando un factor de mejora de 34, como lo indican los informes de código abierto.

WS-DD

En mayo y agosto de 2019, los ciber-actores abusaron de la convención de descubrimiento dinámico de servicios web (WS-DD) para lanzar más de 130 ataques DDoS, con algunos alcanzando tamaños de más de 350 Gigabits por segundo (Gbps), en dos flujos de ataque separados , como lo indica el informe de código abierto.

ARMS

En octubre de 2019, los ciber actores abusaron del Servicio de administración remota de Apple (ARMS), una parte de la función de Escritorio remoto de Apple (ARD), para liderar los ataques de amplificación DDoS, según informes de código abierto.

JENKINS

En febrero de 2020, los investigadores de seguridad del Reino Unido identificaron una vulnerabilidad en los protocolos de descubrimiento de red inherentes de los trabajadores de automatización de código abierto y libres de servidores de Jenkins utilizados para ayudar al proceso de desarrollo de software que los ciber actores podrían explotar para realizar ataques de amplificación DDoS, como lo indica open -informe de fuente.

Los funcionarios del FBI creen que estas nuevas amenazas DDoS se seguirán explotando aún más para causar tiempo de inactividad y daños en el «futuro previsible».

La razón de la alerta es advertir a las compañías estadounidenses sobre el ‘peligro inminente’, para que puedan poner recursos en los sistemas de mitigación de DDoS y crear asociaciones con sus proveedores de servicios de Internet para responder rápidamente a cualquier ataque que utilice estos nuevos vectores.

A partir de ahora, estos cuatro nuevos vectores de ataque DDoS se han utilizado de manera inconsistente, sin embargo, los especialistas de la industria anticipan que serán ampliamente abusados por los servicios DDoS de alquiler.

Fuente: ehackingnews

Investigadores revelan nuevos métodos para reemplazar el contenido en archivos PDF firmados

Un equipo de investigadores de la Universidad Ruhr  Bochum en Alemania han revelado una serie de nuevos métodos de ataque contra archivos PDF firmados.

Apodado Shadow Attacks, las nuevas técnicas permiten que un hacker oculte y reemplace contenido en un documento PDF firmado sin invalidar su firma. El hacker puede crear un documento con dos contenidos diferentes, uno que el firmante espera ver y otro que se mostrará al destinatario del documento.

“Los firmantes del PDF reciben el documento, lo revisan y lo firman. Los atacantes usan el documento firmado, lo modifican ligeramente y lo envían a las víctimas. Después de abrir el PDF firmado, las víctimas verifican si la firma digital se verificó con éxito. Sin embargo, las víctimas ven un contenido diferente al de los firmantes ”, explicaron los investigadores.

Han probado 28 aplicaciones de visor de PDF y descubrieron que 15 de ellas eran vulnerables a al menos uno de los ataques, incluidas las aplicaciones creadas por Adobe, Foxit y LibreOffice. Estas tres organizaciones ya han lanzado parches, pero muchos de los vendedores afectados no respondieron a los mensajes de los investigadores o no proporcionaron información sobre la disponibilidad de los parches.

Los mismos investigadores revelaron previamente métodos para romper las firmas de archivos PDF y realizar cambios no autorizados en documentos firmados. Ahora han presentado tres nuevos ataques a las firmas PDF.

Las organizaciones y los individuos, esto incluye gobiernos, investigadores y empresas, a menudo firman documentos PDF para evitar cambios no autorizados. Si alguien realiza modificaciones en el documento firmado, su firma no será válida.

Sin embargo, los investigadores de la Ruhr University Bochum han demostrado tres variantes de los Shadow Attacks, que los atacantes pueden aprovechar para ocultar, reemplazar u ocultar y reemplazar contenido en archivos PDF. Las vulnerabilidades que permiten estos ataques se rastrean como CVE-2020-9592 y CVE-2020-9596.

La variante «Ocultar» de los Shadow Attacks implica ocultar algo de contenido en un PDF detrás de otra capa, como una imagen de página completa. En un escenario de ataque descrito por los expertos, el atacante envía al firmante un documento con una imagen de un mensaje tentador o inofensivo sobre el contenido que desea ocultar. Una vez que el documento ha sido firmado y enviado de vuelta al atacante, pueden manipular el archivo para que el visor de PDF ya no muestre la imagen, lo que hace que el contenido oculto sea visible.

La variante «Reemplazar» del ataque implica agregar un nuevo objeto, un objeto que se considera inofensivo pero que puede afectar la forma en que se presenta el contenido, a un documento firmado.

“Por ejemplo, la (re) definición de fuentes no cambia el contenido directamente. Sin embargo, influye en la vista del contenido mostrado y hace posible el intercambio de números o caracteres ”, explicaron los investigadores.

La variante «Ocultar y reemplazar», que los investigadores describieron como «la más poderosa», permite a un atacante cambiar todo el contenido de un documento firmado. En este ataque, el pirata informático inserta contenido oculto y contenido visible en el documento utilizando dos objetos que tienen la misma ID de objeto, y lo envía al objetivo. Una vez que reciben el documento firmado, el atacante agrega una nueva tabla Xref y un nuevo Trailer para que se muestre el contenido oculto en lugar de lo que vio la víctima antes de firmar el documento.

Fuente: Security Week

Fortalecimiento de su servidor GitHub Enterprise

GitHub almacena su código fuente, versiones y una gran cantidad de información invaluable en emisiones y solicitudes de extracción. Si bien GitHub Enterprise Server (GHES), nuestra solución de alojamiento propio, proporciona una gran seguridad de forma predeterminada, los administradores pueden tomar medidas adicionales para fortalecer aún más su dispositivo. Esta publicación lo guiará a través de las configuraciones más importantes.

Configure una contraseña segura de Management Console

Management Console es la herramienta de administración GHES más poderosa. Entre otras cosas, le permite otorgar a las personas acceso de shell administrativo. Establezca una contraseña segura para acceder a ella y cámbiela  con regularidad (por ejemplo, con cada actualización de versión de GHES).

Revisar permisos de administrador

Los administradores del sitio tienen derechos de acceso significativos (por ejemplo, suplantar a los usuarios o acceder a todos los repositorios privados), por lo tanto, considere mantener pequeña la cantidad de personas en esa lista. Una buena regla general es tener dos administradores del sitio por zona horaria que puedan ayudar a los usuarios normales en un día laboral promedio.

Recuerde que los administradores del sitio pueden crear tokens de acceso personal con el alcance del administrador del sitio, para la automatización. Asegúrese de que estos tokens solo se usen en sistemas que estén completamente asegurados y auditados.

Los administradores con acceso de shell administrativo tienen derechos completos sobre el dispositivo; por ejemplo, pueden promocionarse como administradores del sitio. Cada administrador debe usar su propia clave SSH protegida con frase de contraseña para que sus actividades sean auditables. También recomendamos usar la última sección en una clave SSH pública para describir el propietario o la función de esa clave cuando la agregue a la Consola de administración. Aquí hay un ejemplo:

ssh-ed25519 AAA...key...ZZZ Mona Lisa, Employee ID 123
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
                              SSH key comment section

Intente mantener el número de personas con acceso de shell administrativo lo más pequeño posible.

Tenga en cuenta que es probable que haya dos claves que no desee eliminar de la lista de acceso del shell administrativo. Primero, la clave que utiliza la réplica de GHES para conectarse al primario en una configuración de alta disponibilidad. Generalmente se llama admin-ssh-key. En segundo lugar, la clave que permite que el servidor de respaldo GHES se conecte al primario.

Al igual que los tokens de Persona Access, las claves SSH sin frase de contraseña, que se utilizan para tareas automatizadas como el servidor de respaldo, solo deben usarse y almacenarse en sistemas seguros.

Los administradores con plataforma de virtualización, hipervisor o acceso físico a la máquina también podrían acceder a los datos de GitHub. Nuevamente, trate de mantener pequeño el número de personas en esa lista.

 

Actualice GitHub Enterprise Server regularmente

Le recomendamos encarecidamente que siga la frecuencia de actualización quincenal de GitHub y que se mantenga en la última versión de parche en caliente compatible. Esto garantiza que su dispositivo contenga todas las últimas correcciones de seguridad. Debería poder aplicar estas actualizaciones de parches en caliente (por ejemplo, de 2.20.4 a 2.20.5) durante las horas de trabajo sin interrupción del usuario, ya que no requieren tiempo de inactividad.

También recomendamos realizar actualizaciones de la versión completa (por ejemplo, de 2.20.5 a 2.21.3) al menos dos veces al año. Al hacer esto, siempre estará ejecutando una versión compatible de GHES, y también tendrá todas nuestras funciones más recientes.

Habilite la autenticación de dos factores para todos los usuarios

Considere requerir autenticación de dos factores (2FA) si su método de autenticación lo admite. Si está utilizando cuentas integradas o cuentas LDAP, puede usar las instalaciones 2FA de GitHub. La mayoría de los proveedores de SAML también admiten 2FA y recomendamos encarecidamente aprovechar esa característica para una postura de seguridad mejorada.

Habilitar la seguridad de la capa de transporte (TLS)

Habilitar “solo TLS” en la Consola de administración de su dispositivo asegura que todo el tráfico web desde y hacia el dispositivo esté encriptado. Recomendamos permitir solo los protocolos TLS modernos y más seguros 1.2 y 1.3.

Habilitar aislamiento de subdominio

Habilitar el aislamiento del subdominio aislará adecuadamente los diferentes componentes de GitHub entre sí. Esto es importante ya que sus usuarios de GitHub Enterprise pueden cargar cualquier código HTML en sus sitios de páginas de GitHub en sus dispositivos. Si el aislamiento del subdominio no está habilitado, este código podría ser un vector de ataque que permita el acceso a otros componentes de GitHub a través de secuencias de comandos entre sitios.

Active el modo privado y desactive las páginas públicas.
Al activar el modo privado en la Consola de administración, puede asegurarse de que solo los usuarios con credenciales de inicio de sesión válidas puedan ver cualquier contenido en su dispositivo.

Además, deshabilitar las páginas públicas garantiza que no se pueda acceder a la información de las páginas de GitHub sin credenciales válidas.

Deshabilitar el acceso de lectura Git anónimo

La desactivación de todo el acceso de lectura Git anónimo garantiza que siempre se necesiten credenciales válidas para acceder a su código fuente.

Revise la configuración y los permisos del servidor de respaldo
Ejecute copias de seguridad periódicas con las utilidades de copia de seguridad de GitHub en una máquina de copia de seguridad dedicada. Asegúrese de que la máquina de respaldo ejecute una distribución de Linux actualizada con las últimas correcciones de seguridad y limite el número de usuarios con acceso a ese sistema. Todos los datos de GitHub (código fuente, versiones, comentarios de problemas, …) se almacenan sin cifrar de forma predeterminada en el host de copia de seguridad.

Use un servidor proxy saliente

Sus usuarios de GHES pueden configurar webhooks que pueden filtrar información potencialmente confidencial (por ejemplo, emitir comentarios) a servidores web externos si su dispositivo tiene acceso a Internet. La configuración de un proxy saliente le permite controlar qué servidores web externos se pueden usar. Póngase en contacto con los servicios profesionales de GitHub para obtener información sobre cómo configurar dicho servidor proxy.

Restrinja los puertos de red de acceso público

Los usuarios habituales de GHES solo deberían poder acceder al dispositivo a través de los puertos HTTPS / 443 y SSH / 22. Una forma popular de lograrlo es usar un equilibrador de carga frente al dispositivo GHES que solo reenvía estos puertos. Además, los administradores pueden usar un host de bastión para conectarse directamente a los puertos administrativos del dispositivo GHES.

Un diseño de red de alta disponibilidad con máquina de respaldo y servidor proxy saliente podría verse así:

Hardened GitHub Enterprise Server architecture diagram

 

Fuente: Git Hub

 

 

Black Box: un nuevo ataque en cajero automático advierte Diebold Nixdorf

Ha surgido un tipo único de ataque ATM llamado «Black Box». El desarrollador de cajeros automáticos Nixdorf advierte al sector financiero que se mantenga alerta. El ataque fue generalizado en toda Europa recientemente. Los ataques de cajero automático de Black Box son similares a Jackpotting, en el que los piratas informáticos hacen que los cajeros automáticos distribuyan efectivo en pilas. Los piratas informáticos usan jackpotting para adjuntar un malware en el cajero automático o utilizan un cuadro negro en su lugar. «Algunos de los ataques exitosos muestran un nuevo Modus Operandi adaptado sobre cómo se realiza el ataque.
«Aunque el estafador todavía está conectando un dispositivo externo, en esta etapa de nuestras investigaciones, parece que este dispositivo también contiene partes de la pila de software del cajero automático atacado», dice Diebold.

En el caso de ataques de caja negra, el pirata informático manipula la carcasa externa del cajero automático y obtiene acceso al puerto. El hacker también puede hacer un agujero en la máquina para encontrar cables y conectores internos. Una vez que el hacker tiene acceso, conecta la caja negra con el cajero automático a través de una computadora portátil, estableciendo una conexión con los sistemas internos. Después de esto, el pirata informático tiene control sobre las opciones de comando y lo usa para dispensar efectivo del cajero automático.

Este tipo de ataques de jackpotting en cajeros automáticos han ocurrido durante una década. Los ataques con jackpotting han sido bastante famosos entre las pandillas, ya que el método es muy rentable y rentable. Los ataques de Jackpotting son más directos en comparación con las tarjetas de clonación, el robo de cajeros automáticos y el lavado de dinero, lo que consume mucho tiempo. Otra razón para la popularidad de los ataques de caja negra es que los novatos hackers (aficionados) no tienen que gastar mucho dinero para obtener una caja negra. Uno puede comprar un dispositivo y lanzar un ataque en un cajero automático sin tener que perder mucho tiempo.

«En incidentes recientes, los atacantes se centran en sistemas exteriores y están destruyendo partes de la fascia para obtener acceso físico al compartimento de la cabeza. Luego, el cable USB entre el dispensador CMD-V4 y la electrónica especial, o el cable entre la electrónica especial y el La PC del cajero automático se desconectó. Este cable está conectado a la caja negra del atacante para enviar comandos de dispensación ilegítimos «, dice Diebold en su sitio web.

Fuente: E Hacking News

Ataques de Ransonware a Orange y Telecom

Según diversas fuentes, no se han afectado a cuenta de los clientes, y los usuarios internos afectados podrían seguir trabajado luego de la recuperación de los backups correspondientes. Los sistemas internos afectados serían la VPN corporativa, Citrix, Siebel, Genesys, las máquinas virtuales del Customer y Field Service y PC de usuarios internos.
Por ahora no se conoce un comunicado oficial de la empresa a sus clientes corporativos, lo cual lamentablemente hace que la situación de incertidumbre sea aún mayor.

Al parecer el ataque ha sido sobre archivos de Office365 y OneDrive de empleados de Telecom Argentina, habiendo sido cifrados con nombres aleatorios y pidiendo un rescate por los archivos.
De acuerdo a distintas fuentes, se trataría del ransomware REvil (también conocido como Sodinokibi) que se identificó por primera vez el 17 de abril de 2019. Este ransomware es utilizado por el grupo de amenazas GOLD SOUTHFIELD, motivado financieramente, que distribuye el ransomware a través de kits de explotación, técnicas de exploración y explotación y servidores RDP expuestos.

Estas son algunas de las muestras del malware que se habría detectado.

El grupo REvil o Sodinokibi o Gandcrab es el mismo que róbo información de la firma de abogados Grubman Shire Meiselas & Sacks y luego exigieron un pago de 42 millones de dólares en criptomonedas para no revelar secretos legales de celebridades e individuos importantes. Recientemente ha evolucionado con nuevas versiones que le han permitido robar información de Travelex , GEDIA , Har Shalom , Artech , etc. Están siguiendo la tendencia reciente en grupos de ransomware, como robar datos antes de cifrar los archivos. Y si el rescate propuesto no se paga, amenaza con filtrar los datos.

Orange confirmó a BleepingComputer que sufrieron un ataque de ransomware exponiendo los datos de veinte de sus clientes empresariales. Orange es una compañía de telecomunicaciones francesa que ofrece servicios de comunicación al consumidor y servicios comerciales a la empresa. Con 266 millones de clientes y 148.000 empleados, Orange es el cuarto operador móvil más grande de Europa.
Orange confirmó que sufrieron un ataque de ransomware dirigido a su división de «Orange Business Services» en la noche del sábado 4 de julio de 2020 al 5 de julio. El 15 de julio pasado, los operadores de ransomware detrás del Nefilim agregaron Orange a su sitio de fuga de datos y declararon que habían violado a la compañía a través de su división «Orange Business Solutions».

Este ataque permitió a los operadores de Nefilim obtener acceso a veinte datos de clientes de Orange Pro/SME.

Como parte de la filtración de los operadores del ransomware publicaron un archivo de 339 MB titulado ‘Orange_leak_part1.rar’ que contenía datos que supuestamente le habían robado a Orange durante el ataque.

La cuenta de Twitter Ransom Leaks, administrada por investigadores que analizan las fugas de ransomware, dijo que este archivo contenía correos electrónicos, esquemas de aviones y archivos de ATR Aircraft, un fabricante francés de aviones. Estos datos pueden indicar que ATR es un cliente de la plataforma de Orange y fue robado durante el ataque.

Dado que el robo de archivos sin cifrar es un componente importante de las operaciones de ransomware dirigidas a empresas, todos los ataques deben considerarse violaciones de datos. Casi todos los ataques de ransomware ahora incluyen un componente de pre-cifrado donde los atacantes roban archivos no cifrados de la víctima.

La amenaza de liberar públicamente estos archivos robados es la última utilizada como palanca para obligar a las víctimas a pagar la demanda de rescate.

 
Fuente: Varias

CISA publica directiva de emergencia sobre vulnerabilidad crítica de Microsoft

La Agencia de Seguridad de Ciberseguridad e Infraestructura (CISA) ha publicado la Directiva de emergencia 20-03 que aborda una vulnerabilidad crítica (CVE-2020-1350) que afecta a todas las versiones de Windows Server con el rol del Sistema de nombres de dominio (DNS) habilitado. Un atacante remoto podría aprovechar esta vulnerabilidad para tomar el control de un sistema afectado. Esta vulnerabilidad se considera «wormable» porque el malware que lo explota en un sistema podría, sin la interacción del usuario, propagarse a otros sistemas vulnerables.

Aunque la Directiva de emergencia 20-03 se aplica solo a ciertos departamentos y agencias del Poder Ejecutivo, CISA recomienda encarecidamente a los gobiernos estatales y locales, el sector privado y otros que corrijan esta vulnerabilidad crítica tan pronto como sea posible. Revise los siguientes recursos para obtener más información:

Fuente: CISA

¿Quién está detrás del hackeo épico de Twitter del miércoles?

Twitter cayó en el caos el miércoles después de que algunas de las figuras públicas, ejecutivos y celebridades más reconocidas del mundo comenzaron a tuitear enlaces a estafas de bitcoin. Twitter dice que el ataque ocurrió porque alguien engañó o coaccionó a un empleado para que proporcionara acceso a herramientas administrativas internas de Twitter. Esta publicación es un intento de diseñar parte de la línea de tiempo de este ataque y señalar pistas sobre quién pudo haber estado detrás de él.

Los primeros signos públicos de la intrusión llegaron alrededor de las 3 p.m. EST, cuando la cuenta de Twitter para el intercambio de criptomonedas Binance tuiteó un mensaje que decía que se había asociado con «CryptoForHealth» para devolver 5000 bitcoins a la comunidad, con un enlace donde las personas podían donar o enviar dinero.

Minutos después, salieron tweets similares de las cuentas de otros intercambios de criptomonedas y de las cuentas de Twitter para el candidato presidencial democrático Joe Biden, el CEO de Amazon Jeff Bezos, el presidente Barak Obama, el CEO de Tesla, Elon Musk, el ex alcalde de Nueva York Michael Bloomberg y la inversión magnate Warren Buffet.

Si bien puede sonar ridículo que alguien se deje engañar para enviar bitcoins en respuesta a estos tweets, un análisis de la billetera BTC promovido por muchos de los perfiles pirateados de Twitter muestra que el 15 de julio la cuenta procesó 383 transacciones y recibió casi 13 bitcoins en julio 15 – o aproximadamente USD $ 117,000.

Twitter emitió un comunicado diciendo que detectó «un ataque coordinado de ingeniería social por parte de personas que se dirigieron con éxito a algunos de nuestros empleados con acceso a sistemas y herramientas internos. Sabemos que utilizaron este acceso para tomar el control de muchas cuentas altamente visibles (incluidas las verificadas) y tuitear en su nombre. Estamos investigando qué otra actividad maliciosa pueden haber realizado o información a la que hayan accedido y compartiremos más aquí como la tenemos «.

Hay fuertes indicios de que este ataque fue perpetrado por personas que tradicionalmente se han especializado en el secuestro de cuentas de redes sociales a través del «intercambio de SIM», una forma cada vez más desenfrenada de delito que consiste en sobornar, piratear o coaccionar a los empleados de empresas de telefonía móvil y redes sociales para que proporcionen acceso a la cuenta de un objetivo.

Las personas dentro de la comunidad de intercambio de SIM están obsesionadas con el secuestro de las llamadas cuentas de redes sociales «OG». Abreviatura de «gángster original», las cuentas de OG generalmente son aquellas con nombres de cuenta cortos (como @B o @joe). La posesión de estas cuentas OG confiere una medida de estado y la influencia percibida y la riqueza en los círculos de intercambio de SIM, ya que tales cuentas a menudo pueden alcanzar miles de dólares cuando se revenden en el subsuelo.

En los días previos al ataque del miércoles en Twitter, hubo indicios de que algunos actores de la comunidad de intercambio de SIM estaban vendiendo la posibilidad de cambiar una dirección de correo electrónico vinculada a cualquier cuenta de Twitter. En una publicación en OGusers, un foro dedicado al secuestro de cuentas, un usuario llamado «Chaewon» anunció que podría cambiar la dirección de correo electrónico vinculada a cualquier cuenta de Twitter por $ 250, y proporcionar acceso directo a cuentas por entre $ 2,000 y $ 3,000 cada uno.

«Este NO es un método, se le dará un reembolso completo si por alguna razón no recibe el correo electrónico / @, sin embargo, si es reverenciado / suspendido, no se me hará responsable», escribió Chaewon en su hilo de ventas, que se tituló «Extracción de correo electrónico para cualquier solicitud de Twitter / Tomar».

Horas antes de que cualquiera de las cuentas de Twitter para plataformas de criptomonedas o figuras públicas comenzaran a lanzar estafas de bitcoin el miércoles, los atacantes parecen haber centrado su atención en secuestrar un puñado de cuentas OG, incluida «@ 6».

Esa cuenta de Twitter era propiedad de Adrian Lamo, el «hacker sin hogar» ahora fallecido, tal vez mejor conocido por irrumpir en la red del New York Times y por denunciar el robo de documentos clasificados por parte de Chelsea Manning. @ 6 ahora está controlado por el viejo amigo de Lamo, un investigador de seguridad y phreaker telefónico que pidió ser identificado en esta historia solo por su apodo en Twitter, «Lucky225».

Lucky225 dijo que justo antes de las 2 p.m. EST el miércoles, recibió un código de confirmación de restablecimiento de contraseña a través de Google Voice para la cuenta de Twitter @ 6. Lucky dijo que previamente había deshabilitado las notificaciones por SMS como un medio para recibir códigos de múltiples factores de Twitter, optando en su lugar por generar códigos únicos generados por una aplicación de autenticación móvil.

Pero debido a que los atacantes pudieron cambiar la dirección de correo electrónico vinculada a la cuenta @ 6 y deshabilitar la autenticación multifactor, el código de autenticación único se envió tanto a su cuenta de Google Voice como a la nueva dirección de correo electrónico agregada por los atacantes.

«La forma en que funcionó el ataque fue que, dentro de las herramientas de administración de Twitter, aparentemente puede actualizar la dirección de correo electrónico de cualquier usuario de Twitter, y lo hace sin enviar ningún tipo de notificación al usuario», dijo Lucky a KrebsOnSecurity. «Entonces [los atacantes] podrían evitar la detección al actualizar primero la dirección de correo electrónico de la cuenta y luego desactivar 2FA».

Lucky dijo que aún no ha podido revisar si se enviaron tweets desde su cuenta durante el tiempo que fue secuestrado porque todavía no tiene acceso a él (ha reunido un desglose de todo el episodio en esta publicación de Medium) )

Pero casi al mismo tiempo que @ 6 fue secuestrado, otra cuenta de OG – @B – fue robada. Luego, alguien comenzó a tuitear imágenes del panel de herramientas internas de Twitter que muestra la cuenta @B.

Twitter respondió eliminando todos los tweets de su plataforma que incluían capturas de pantalla de sus herramientas internas y, en algunos casos, suspendió temporalmente la capacidad de esas cuentas para seguir tuiteando.

Otra cuenta de Twitter, @shinji, también estaba tuiteando capturas de pantalla de las herramientas internas de Twitter. Minutos antes de que Twitter cerrara la cuenta @shinji, se vio la publicación de un tweet que decía «follow @ 6», en referencia a la cuenta secuestrada de Lucky225.

La fuente de seguridad de la industria móvil le dijo a KrebsOnSecurity que PlugWalkJoe en la vida real es un joven de 21 años de Liverpool, Reino Unido, llamado Joseph James Connor. La fuente dijo que PlugWalkJoe está en España, donde asistía a una universidad hasta principios de este año. Agregó que PlugWalkJoe no ha podido regresar a su hogar debido a restricciones de viaje debido a la pandemia de COVID-19.

La fuente de la industria móvil dijo que PlugWalkJoe fue objeto de una investigación en la que se contrató a una investigadora para entablar una conversación con PlugWalkJoe y convencerlo de que aceptara un chat de video. La fuente explicó además que un video que grabaron de ese chat mostraba una piscina distintiva en el fondo.

Según esa misma fuente, el grupo que aparece en la cuenta de Instagram de PlugWalkJoe (instagram.com/j0e) es el mismo que vieron en su video chat con él.

Si PlugWalkJoe fue de hecho fundamental para este compromiso de Twitter, tal vez sea apropiado que fuera identificado en parte a través de la ingeniería social. Tal vez todos deberíamos estar agradecidos de que los autores de este ataque en Twitter no hayan puesto sus ojos en objetivos más ambiciosos, como interrumpir una elección o el mercado de valores, o intentar iniciar una guerra emitiendo tweets falsos e inflamatorios de los líderes mundiales.

Además, parece claro que este truco de Twitter podría haber permitido a los atacantes ver los mensajes directos de cualquier persona en Twitter, información que es difícil de ponerle precio pero que, sin embargo, sería de gran interés para una variedad de partidos, desde estados nacionales hasta espías corporativos y chantajistas.

Esta es una historia de rápido movimiento. Estén atentos para más actualizaciones. KrebsOnSecurity desea agradecer a la Unidad 221B por su ayuda para conectar algunos de los puntos en esta historia.

Fuente: https://krebsonsecurity.com/

Actividad Maliciosa Dirigida a la Investigación, Desarrollo de Vacunas del COVID-19

En respuesta a actividades maliciosas dirigidas a la investigación de COVID-19 y al desarrollo de vacunas en los Estados Unidos, el Reino Unido (Reino Unido) y Canadá, la Agencia de Seguridad de la Ciberseguridad e Infraestructura (CISA), el Centro Nacional de Seguridad Cibernética (NCSC) del Reino Unido, el Establecimiento de Seguridad de Comunicaciones de Canadá (CSE) y la Agencia de Seguridad Nacional (NSA) lanzaron un Aviso Conjunto de Ciberseguridad para exponer la amenaza. Un actor cibernético malicioso está utilizando una variedad de herramientas y técnicas para dirigirse a organizaciones involucradas en la investigación de COVID-19 y el desarrollo de vacunas. Las herramientas incluyen malware SOREFANG, WELLMESS y WELLMAIL.

CISA alienta a los usuarios y administradores a revisar el Aviso Conjunto de Ciberseguridad y los siguientes Informes de Análisis de Malware para obtener más información y aplicar las mitigaciones proporcionadas.

Fuente: CISA