Se vence un certificado raíz ¿Apagón de Internet? Naaa

Este miércoles 30 de septiembre está programado un apagón de Internet. ¿Para tanto? En realidad no. Este "apagón" sucederá normalmente debido al vencimiento de un certificado digital.

El 30 de septiembre de 2021, el certificado raíz que Let's Encrypt está utilizando actualmente, el certificado IdentTrust DST Root CA X3, caducará. Todos los certificados que impulsan HTTPS en la web son emitidos por una CA, una organización de confianza reconocida por su dispositivo / sistema operativo.

Estos certificados están integrados en todos los sistemas operativos y generalmente se actualizan como parte del proceso normal de actualización de su sistema operativo. El certificado aquí que va a causar un problema es este, el IdenTrust DST Root CA X3.

Como se puede ver, el tiempo corre y nos acercamos a la fecha de vencimiento del 30 de septiembre de 2021, pero no es solo una fecha de vencimiento, es una marca de tiempo de vencimiento que llamamos notAfter. Una vez que esta CA raíz haya expirado, los clientes, como los navegadores web, ya no confiarán en los certificados emitidos por esta CA.

Esta no es la primera vez que caduque un certificado de CA raíz, ni será la última. Si el certificado raíz en el que se ancla la cadena de certificados ha caducado, es muy probable que falle. Esto sucedió el año pasado, el 30 de mayo a las 10:48:38 2020 GMT para ser exactos, cuando la raíz externa de CA de AddTrust expiró y se llevó puestas un montón de cosas: incluso RedHat tuvo algo que decir sobre el evento.

En circunstancias normales, no valdría la pena hablar de este evento, una CA raíz que expira, porque la transición de un certificado raíz antiguo a un certificado raíz nuevo es completamente transparente. La razón por la que tenemos un problema es porque los clientes no se actualizan con regularidad y, si el cliente no se actualiza, la nueva CA raíz que reemplaza a la antigua CA raíz que vence no se descarga en el dispositivo.

Solo en el último año, Let's Encrypt ha aumentado bastante su participación en el mercado y, a medida que una CA se hace más grande, sus certificados permiten que funcione más la Web y, como resultado, cuando surge algo como esto, tienen el potencial de causar más problemas. Esto no tiene nada que ver con lo que Let's Encrypt ha hecho, o no ha hecho, todavía se reduce al mismo problema subyacente de que los dispositivos en el ecosistema no se actualizan como deberían.

¿Qué dispositivos dejarán de funcionar?

Todos los dispositivos que cuenten con ese certificado raíz perderán su conectividad:

• Uno de los clientes notables que se verá afectado por este vencimiento es cualquier cosa que dependa de la biblioteca OpenSSL 1.0.2 o anterior, la versión del 22 de enero de 2015 y la última actualización como OpenSSL 1.0.2u el 20 de diciembre de 2019. OpenSSL ha publicado una nora en el blog que detalla qué acciones pueden tomar los afectados, pero todos requieren una intervención manual para evitar roturas.
• OpenSSL <= 1.0.2
• Windows < XP SP3
• macOS < 10.12.1
• iOS < 10 (iPhone 5 is the lowest model that can get to iOS 10)
• Android < 7.1.1 (but >= 2.3.6 will work if served ISRG Root X1 cross-sign)
• Mozilla Firefox < 50
• Ubuntu < 16.04
• Debian < 8
• Java 8 < 8u141
• Java 7 < 7u151
• NSS < 3.26
• Amazon FireOS (Silk Browser)

¿Cómo evitar que mi dispositivo deje de funcionar?

La solución consiste en actualizar los controladores de los dispositivos. Los más modernos no tendrán ningún inconveniente ya que las compañías lanzan actualizaciones constantes para sus últimos productos.

Sin embargo, en muchos casos las empresas consideran obsoletos a sus productos más viejos y no realizan un actualización de software, por lo que actualizar el certificado root será difícil o imposible. Se estima que el 30% de los celulares Android podrían quedar fuera de servicio.

En general, los productos fabricados a partir del 2017 no se verán afectados ya que la mayoría de ellos cuentan con el ISGR Root X1, cuya fecha de caducidad es en junio de 2035.

Fuente: Scott Helme | Let's Encrypt

Seguir leyendo...

Bloquear LOLBins de Microsoft con WDAC

El concepto LolBins, LoLBas es la manera que tenemos de identificar ejecutables y funciones del sistema operativo diseñados para un cometido, pero que pueden ser usados para un fin un tanto "alternativo".

El contexto de esto es muy sencillo. Imagina que se compromete un servidor Windows, por el fallo que sea, una vez comprometido debemos realizar otras acciones, escalado, movimientos, exfiltración, lo que sea que tengamos como objetivo. Si en ese host comprometido necesitamos herramientas, tenemos la opción de descargarlas, con el riesgo de que un sistema defensivo las detecte, como un antivirus, o usar binarios del sistema, que gozan de la confianza del antivirus, ya que están diseñados para "EQUIS" cosas, pero nosotros las vamos a usar para el mal.

El más sencillo de los Lolbins para entenderlo es el "hh.exe". Este binario está diseñado para ejecutar las pantallas de ayuda cuando usamos esta función por cualquier parte de Windows, pero si le añadimos una URL, nos hace las veces de navegador, por lo que en un entorno en el que se prohíbe Chrome o Internet Explorer, podríamos navegar y saltarnos esta medida.

Existe distintos proyectos que aglutinan los Lolbins que van saliendo, es decir, que se descubre un uso un poco alternativo y los jefes de Flu Project hablaron ya en su día de esto.

Vamos a comentar otro muy interesante, por ejemplo, el "PresentationHost.exe". Imagina un entorno con Powershell capado, algo habitual o debiera serlo... podemos usar este LolBins que es un intérprete de aplicaciones web para aplicaciones Xaml, siguiendo este magnifico post, para invocar a Powershell desde ese proceso (presentationhost.exe) con lo que podemos evadir Applocker.

La propia Microsoft ha recopilado una serie de binarios muy concretos con un potencial muy peligroso y nos emplaza a bloquearlos mediante Device Guard For Application (WDAC) con una plantilla a tal efecto, mucho más efectivo que Applocker.

Esta medida es muy sencilla de implementar mediante GPO y la directiva de reglas creada.

Si quieres saber más de como crear un conjunto apropiada de políticas, puedes leer esta interesante guía. Por supuesto que mientras decides la viabilidad de bloquear dichos ficheros, puedes empezar por auditar el acceso a estos objetos.

Fuente: Kinomakino

Seguir leyendo...

La decisión del FBI de retener las claves de descifrado del ransomware Kaseya despierta debate

Esta semana, el Washington Post informó que el FBI tenía las claves de descifrado para las víctimas del ataque generalizado de ransomware Kaseya que tuvo lugar en julio, pero que no las compartió durante tres semanas.

Cientos de organizaciones se vieron afectadas por el ataque de Kaseya, incluidas decenas de hospitales, escuelas, empresas e incluso una cadena de supermercados en Suecia. REvil exigió un rescate de $ 70 millones de Kaseya y miles de víctimas individuales antes de apagarse y cerrar partes significativas de su infraestructura poco después del ataque. Desde entonces, el grupo ha regresado, pero muchas organizaciones aún se están recuperando del amplio ataque del 4 de julio.

Los reporteros del Washington Post Ellen Nakashima y Rachel Lerman escribieron esta semana que el FBI logró obtener las claves de descifrado porque accedieron a los servidores de REvil, la banda criminal con sede en Rusia que estuvo detrás del ataque masivo.

A pesar de la gran cantidad de víctimas del ataque, el FBI no compartió las claves de descifrado y decidió conservarlas mientras se preparaban para lanzar un ataque a la infraestructura de REvil. Según The Washington Post, el FBI no quería avisar a los operadores de REvil entregando las claves de descifrado.

El FBI también afirmó que "el daño no fue tan severo como se temía inicialmente". El ataque del FBI a REvil nunca sucedió debido a la desaparición de REvil, dijeron funcionarios al periódico. El FBI finalmente compartió las claves de descifrado con Kaseya el 21 de julio, semanas después de que ocurriera el ataque. Varias víctimas hablaron con The Washington Post sobre los millones que se perdieron y el daño significativo causado por los ataques.

Otra fuente policial finalmente compartió las claves de descifrado con Bitdefender, que lanzó un descifrador universal a principios de este mes para todas las víctimas infectadas antes del 13 de julio de 2021. Más de 265 víctimas de REvil han utilizado el descifrador, dijo un representante de Bitdefender a The Washington Post.

Durante su testimonio ante el Congreso el martes, el director del FBI, Christopher Wray, culpó del retraso a otras agencias de aplicación de la ley y aliados que, según dijeron, les pidieron que no divulgaran las claves. Dijo que estaba limitado en lo que podía compartir sobre la situación porque todavía están investigando lo sucedido.

"Tomamos las decisiones como grupo, no unilateralmente. Son decisiones complejas..., diseñadas para crear el máximo impacto, y eso lleva tiempo para ir contra adversarios donde tenemos que reunir recursos no solo en todo el país sino en todo el mundo... Se requiere mucha ingeniería para desarrollar una herramienta", dijo Wray al Congreso.

La revelación provocó un debate considerable entre los expertos en seguridad, muchos de los cuales defendieron la decisión del FBI de dejar a las víctimas luchando por recuperarse del ataque durante semanas.

El CISO de Critical Insight, Mike Hamilton, quien se enfrentó a una situación particularmente espinosa en la que una víctima de Kaseya quedó en la estacada después de pagar un rescate justo antes de que REvil desapareciera, dijo que tener cuidado con la divulgación de métodos es un elemento básico de las comunidades de inteligencia y aplicación de la ley.

Sin embargo, hay un 'indicio' de que nos hemos confirmado. Se cita al FBI diciendo que el daño no fue tan grave como pensaban y eso les dio algo de tiempo para trabajar. Esto se debe a que el evento no fue una infiltración sigilosa típica, seguida de un pivote a través de la red para encontrar los recursos clave y las copias de seguridad. Según todos los indicios, los únicos servidores que fueron cifrados por el ransomware fueron los que tenían el agente de Kaseya instalado; este fue un ataque de smash-and-grab.

Sean Nikkel, analista sénior de inteligencia de amenazas en Digital Shadows, dijo que el FBI puede haber visto la necesidad de prevenir o cerrar las operaciones de REvil como algo que supera la necesidad de salvar a un grupo más pequeño de empresas que luchan en un solo ataque.

Debido a la creciente escala de ataques y demandas de extorsión de REvil, una situación de rápido desarrollo que requiere una respuesta igualmente rápida probablemente se adelantó a una respuesta más mesurada a las víctimas de Kaseya, explicó Nikkel, y agregó que es fácil juzgar la decisión ahora que tenemos más información, pero que debe haber sido una decisión difícil en ese momento.

"Puede haber sido un paso prudente llegar directamente a las víctimas en silencio, pero los atacantes que ven a las víctimas descifrando archivos o abandonando las negociaciones en masa pueden haber revelado la estratagema del FBI para tomar contramedidas", dijo Nikkel a ZDNet.

Es posible que los atacantes hayan derribado la infraestructura o cambiado de táctica. También existe el problema de que el sonido anónimo sobre el descifrado se abre paso en los medios públicos, lo que también podría alertar a los atacantes. Los grupos criminales prestan atención a las noticias de seguridad tanto como lo hacen los investigadores, a menudo con su propia presencia en las redes sociales.

Nikkel sugirió que un mejor enfoque podría haber sido abrir las comunicaciones de canal secundario con las empresas de respuesta a incidentes involucradas para coordinar mejor los recursos y la respuesta, pero señaló que es posible que el FBI ya lo haya hecho.

El CTO de BreachQuest, Jake Williams, calificó la situación como un caso clásico de una evaluación de ganancia / pérdida de inteligencia. Es fácil para la gente jugar al "mariscal de campo del lunes por la mañana" y culpar al FBI por no entregar las llaves después del hecho.

Pero Williams notó que el daño financiero directo fue casi con certeza más generalizado de lo que creía el FBI, ya que retuvo la clave para proteger su operación. "Por otro lado, liberar la clave resuelve una necesidad inmediata sin abordar el problema más amplio de interrumpir las futuras operaciones de ransomware. En resumen, creo que el FBI tomó la decisión equivocada al retener la clave", dijo Williams.

John Bambenek, principal cazador de amenazas de Netenrich, dijo que los críticos deben recordar que, ante todo, el FBI es una agencia de aplicación de la ley que siempre actuará de una manera que optimice los resultados de la aplicación de la ley.

"Si bien puede ser frustrante para las empresas que podrían haber recibido ayuda antes, la aplicación de la ley lleva tiempo y, a veces, las cosas no funcionan según lo planeado", dijo Bambenek. "El beneficio a largo plazo de las operaciones policiales exitosas es más importante que las víctimas individuales de ransomware".

Fuente: ZDNet

Seguir leyendo...

Nueva función de privacidad de Apple revela la dirección IP real del usuario

Una nueva debilidad aún sin parchear en la función de retransmisión privada de iCloud de Apple podría utilizarse para filtrar las direcciones IP verdaderas de los usuarios de los dispositivos iOS que ejecutan la última versión del sistema operativo.

Introducido con iOS 15, que se lanzó oficialmente esta semana, iCloud Private Relay tiene como objetivo mejorar el anonimato en la web mediante el empleo de una arquitectura de doble salto que protege eficazmente la dirección IP, la ubicación y las solicitudes de DNS de los usuarios de sitios web y proveedores de servicios de red.

Lo logra enrutando el tráfico de Internet de los usuarios en el navegador Safari a través de dos proxies para enmascarar quién está navegando y de dónde provienen esos datos en lo que podría verse como una versión simplificada de Tor.

Sin embargo, la función está disponible para los suscriptores de iCloud+ que ejecutan iOS 15 o macOS 12 Monterey y versiones posteriores.

"Si se lee la dirección IP de una solicitud HTTP recibida por su servidor, obtendrá la dirección IP del proxy de salida", dijo el investigador de FingerprintJS Sergey Mostsevenko. "Sin embargo, puede obtener la IP del cliente real a través de WebRTC".

WebRTC, abreviatura de Web Real-Time Communication, es una iniciativa de código abierto destinada a proporcionar a los navegadores web y aplicaciones móviles comunicación en tiempo real a través de API que permiten la comunicación de audio y video de igual a igual sin la necesidad de instalar complementos dedicados o aplicaciones. Este intercambio de medios en tiempo real entre dos puntos finales se establece a través de un proceso de descubrimiento y negociación llamado señalización que implica el uso de un marco denominado Interactive Connectivity Establishment (ICE), que detalla los métodos (también conocidos como candidatos) que pueden utilizar los dos pares para encontrar y establecer una conexión entre sí, independientemente de la topología de la red.

FingerprintJS dijo que alertó a Apple sobre el problema, y ​​que el fabricante del iPhone ya lanzó una solución en su última versión beta de macOS Monterey. Sin embargo, la filtración no se ha corregido cuando se usa iCloud Private Relay en iOS 15.

En todo caso, la revelación es otra indicación de que iCloud Private Relay nunca puede reemplazar a las VPN, y los usuarios que estén preocupados por la visibilidad de sus direcciones IP deben usar una VPN real o navegar por Internet a través de la red Tor y deshabilitar completamente JavaScript desde Safari para desactivar las funciones relacionadas con WebRTC.

Fuente: THN

Seguir leyendo...

Google está trabajando en un modo Solo-HTTPS para Chrome

Siguiendo los pasos de navegadores como Mozilla Firefox y Microsoft Edge, Google Chrome también está en línea para recibir un modo solo HTTPS que actualizará todas las conexiones HTTP no cifradas a alternativas HTTPS cifradas, cuando sea posible.

Se está trabajando para agregar configuraciones específicas en la interfaz del navegador porque actualmente no hay ninguna funcionalidad real de HTTP a HTTPS.

Actualmente, el nuevo modo solo HTTPS de Chrome aún está en desarrollo en las distribuciones de Chrome Canary. Si bien se está trabajando en esta nueva función en Chrome Canary 93, no está claro si el nuevo modo HTTPS-Only se enviará con la versión estable de Chrome 93, que comenzará a funcionar en agosto de este año.

Actualmente, Chrome 93 incluye un nuevo indicador ubicado en chrome://flags/#https-only-mode-setting que, cuando está habilitado, agrega una nueva opción llamada "Usar siempre conexiones seguras" en la configuración de seguridad del navegador Chrome.

El trabajo de Chrome para agregar un modo solo HTTPS se produce después de que Mozilla agregó una función con un nombre similar a Firefox en v83. A principios de este mes, Microsoft también agregó una función llamada HTTPS automático a su navegador insignia Edge.

Actualmente, alrededor del 82,2% de todos los sitios de Internet admiten conexiones HTTPS. Los fabricantes de navegadores como Chrome y Mozilla informaron anteriormente que el tráfico HTTPS generalmente representa del 90% al 95% de su tráfico diario de usuarios.

En un informe del mes pasado que analizaba el lanzamiento de su modo solo HTTP, Mozilla dijo que Firefox actualizó el tráfico HTTP a HTTPS solo para el 3,5% de las páginas web, ya que el 92,8% ya se cargaba a través de conexiones HTTPS.

En años anteriores, Google ha tomado medidas similares para promover el uso de la tecnología HTTPS, que incluyen:

• haciendo que HTTPS sea el protocolo predeterminado en su dirección / barra de búsqueda [ver anuncio aquí]
• actualización automática de contenido mixto de HTTP a HTTPS [ver anuncio aquí]
• bloquear descargas HTTP iniciadas desde páginas HTTPS aparentemente seguras [ver anuncio aquí]

Fuente: TheRecord

Seguir leyendo...

Encuentran bombas lógicas en paquetes Python (vía PyPi)

Investigadores de SonaType descubrieron un ataque de bomba lógica en el repositorio del índice de paquetes de Python (PyPI), que es un repositorio de código para los desarrolladores de Python y parte de la cadena de suministro de software. Los atacantes tenían como objetivo que los desarrolladores de software incluyeran esas bombas en sus aplicaciones por accidente.

Las herramientas de análisis detectan y bloquean constantemente componentes de software falsificados y maliciosos antes de que lleguen a las cadenas de suministro de software modernas. De hecho, desde su lanzamiento en 2019, Release Integrity ha identificado más de 12.000 paquetes de código abierto npm sospechosos, muchos de los cuales han aparecido en los titulares una y otra vez [1, 2, 3, 4, ...].

Los investigadores encontraron seis payloads, todas subidas por un solo usuario: "nedog123". El atacante los diseñó para que se ejecutaran durante la instalación de un paquete. La gente ha descargado colectivamente estas "bombas" unas 5.000 veces. Algunas de las bombas lógicas eran typosquating, diseñadas para engañar a las personas haciéndoles creer que eran programas normales. Su propósito: secuestrar los sistemas de desarrollo para hacer criptominería.

Este evento es complejo porque combina tres tipos diferentes de ataques: bombas lógicas, cryptojacking y ataques a la cadena de suministro de software. Sirve como un recordatorio para que todas las empresas y agencias se protejan contra los tres tipos de ataques.

La amenaza que representan este tipo de bombas lógicas y los ataques de malware en la cadena de suministro requieren un enfoque de toda la industria por parte de los desarrolladores, los repositorios y el mundo más amplio de herramientas y especialistas de seguridad.

Desactivar una bomba lógica

Una bomba lógica es un conjunto de instrucciones que se ejecutan bajo ciertas condiciones, generalmente con intenciones maliciosas. Un desafío con los ataques con bombas lógicas es que no hacen nada al principio. No se puede encontrarlas buscando un comportamiento extraño mientras están inactivos. Otra es que varían en forma y función entre sí. Evitar patrones conocidos ayuda a los actores malintencionados a plantar bombas lógicas que las víctimas no pueden detectar fácilmente

Pueden hacer cualquier cantidad de cosas, como robar, borrar o corromper datos, bloquear sistemas o iniciar procesos de criptominería.

Un tipo común se llama bomba de tiempo, lo que significa que la condición de activación del malware es una fecha y una hora. Otros se activan después de algún evento o actividad específica en la máquina donde está instalado. Los atacantes pueden instalar este tipo de malware en múltiples sistemas dentro de una organización, y las muchas instancias aumentan la posibilidad de que la carga útil maliciosa tenga el efecto deseado. El disparador de tiempo asegura que el disparo de una bomba no alertará a los profesionales de seguridad sobre la existencia de las otras.

Fuente: Security Intelligence

Seguir leyendo...

Bug Bounty en Software Libre

Internet Bug Bounty de HackerOne comezó a recompensa la investigación de seguridad sobre las vulnerabilidades que afectan los proyectos de Software de Código Abierto (OSS)   dentro de la cadena de suministro de software.

Uno de los mitos más extendidos (y equivocados) es que el software libre o de código abierto es más seguro por definición porque existen miles de ojos mirándolo y corrigiendo problemas. En un mundo ideal sí, pero la realidad es que los fallos están ahí, sea abierto o cerrado, de igual forma.

Incluso en el código abierto más popular puede retrasarse la detección de fallos. Según un estudio de GitHub se tardan de media cuatro años en detectar un fallo de seguridad, aunque solo un mes en arreglarlo. Cuando cada vez más, el software en general depende de piezas Open Source (el 94% en GitHub), esto es un problema global que se ha materializado en ataques de Supply Chain que pueden poner en peligro importantes infraestructuras.

Los pagos van de 300 a 5.000 dólares por las más críticas. Las recompensas se otorgan siguiendo un modelo dividido 80/20, donde el 80% de la recompensa se paga al buscador y el 20% se paga al Proyecto OSS. El monto de la recompensa se determina en el momento de la recompensa, NO en la presentación inicial de la vulnerabilidad. Las recompensas serán dinámicas y cambiarán regularmente según la cantidad de socios participantes.

El programa busca incentivar la investigación de seguridad en las dependencias de la cadena de suministro de software y código abierto; permitir que los beneficiarios del código abierto contribuyan a nuestra seguridad colectiva de manera equitativa y; brindar apoyo financiero a los investigadores de seguridad y los mantenedores de código abierto, que a menudo ofrecen su talento como voluntarios.

Fuente: CyberPulse | HackerOne

Seguir leyendo...

Infección de Ransomware a través de un exploit de 11 años en ColdFusion

Actores de amenazas no identificados violaron un servidor que ejecutaba una versión de 11 años sin parche del software ColdFusion 9 de Adobe en minutos para tomar el control de forma remota e instalar el ransomware Cring en la red del objetivo, 79 horas después del ataque.

El servidor, que pertenecía a una empresa de servicios sin nombre, se utilizaba para recopilar horarios y datos contables para la nómina, así como para alojar varias máquinas virtuales, según un informe publicado por Sophos y compartido con The Hacker News. Los ataques se originaron en una dirección de Internet asignada al ISP ucraniano Green Floid.

"Los dispositivos que ejecutan software vulnerable y obsoleto son un fruto fácil para los ciberatacantes que buscan una manera fácil de llegar a un objetivo", dijo el investigador principal de Sophos, Andrew Brandt. "Lo sorprendente es que este servidor estaba en uso diario activo. A menudo, los dispositivos más vulnerables son máquinas inactivas o fantasmas, ya sea olvidadas o pasadas por alto cuando se trata de parches y actualizaciones".

La firma británica de seguridad dijo que el "robo rápido" fue posible gracias a la explotación de una instalación de hace 11 años de Adobe ColdFusion 9 que se ejecuta en Windows Server 2008. Ambos han llegado al final de su vida útil.

Al hacerse un hueco inicial, los atacantes utilizaron una amplia gama de métodos sofisticados para ocultar sus archivos, inyectar código en la memoria y cubrir sus huellas sobrescribiendo los archivos con datos confusos, sin mencionar el deshabilitación de los productos de seguridad.

Especialmente, el adversario aprovechó CVE-2010-2861, un conjunto de vulnerabilidades de Path Traversal en la consola de administrador en Adobe ColdFusion 9.0.1 y versiones anteriores que podrían ser abusadas por atacantes remotos para leer archivos arbitrarios, como aquellos que contienen hashes de contraseña de administrador ("password.properties").

En la siguiente etapa, se cree que el actor malintencionado aprovechó otra vulnerabilidad en ColdFusion, CVE-2009-3960, para cargar un archivo de hoja de estilo en cascada (CSS) malicioso en el servidor y, en consecuencia, lo utilizó para cargar un ejecutable de Cobalt Strike Beacon. Este binario, entonces, actuó como un conducto para que los atacantes remotos instalaran payloads adicionales, crearan una cuenta de usuario con privilegios de administrador e incluso deshabilitaran los sistemas de protección y los motores anti-malware como Windows Defender, antes de comenzar el proceso de cifrado.

"Este es un claro recordatorio de que los administradores de TI se benefician de tener un inventario preciso de todos sus activos conectados y no pueden dejar los sistemas comerciales críticos desactualizados frente a la Internet pública", dijo Brandt. "Si las organizaciones tienen estos dispositivos en cualquier lugar de su red, pueden estar seguras de que atraerán a los ciberatacantes".

Fuente: THN

Seguir leyendo...

Google restablecerá automáticamente los permisos de aplicaciones de Android

Google restablecerá automáticamente los permisos de aplicaciones de Android no utilizadas durante meses en millones de dispositivos móviles. Se trata de una ampliación de la función equivalente que se estrenó con Android 11.

Los permisos de aplicaciones de Android es un asunto que lleva coleando prácticamente desde que se lanzó el sistema móvil, ante lo que ha sido un delicado equilibrio entre la facilidad de uso y la seguridad. Si su simplificación lleva a un mayor riesgo, dificultar su gestión molesta a los usuarios y la dejadez termina perjudicando seguridad y privacidad.

Con Android 11, el gigante de Internet introdujo una opción de restablecimiento automático de permisos que ayuda a mejorar la privacidad del usuario al restablecer automáticamente los permisos de una app para acceder a funciones sensibles como el almacenamiento o la cámara si la aplicación en cuestión no se utiliza durante meses. Algo que ocurre más frecuentemente de lo que nos pensamos.

La expansión de esta función entrará en funcionamiento a finales de este año y se habilitará en teléfonos Android con servicios de Google Play que ejecutan Android 6.0 (nivel de API 23) o superior. Según Google, debería cubrir "miles de millones de dispositivos más" ya que el lanzamiento de Marshmallow sucedió el 5 de octubre de 2015 y desde entonces la venta de dispositivos ha sido multimillonaria.

"Algunas aplicaciones y permisos están automáticamente exentos de revocación, como las aplicaciones activas de administración de dispositivos que utilizan las empresas y los permisos fijados por la política empresarial", señaló Google. Si bien el restablecimiento automático de permisos se activará de forma predeterminada para las aplicaciones destinadas a Android 11 (nivel de API 30) o superior, la nueva función debe habilitarse manualmente para las aplicaciones que tienen como objetivo los niveles de API 23 a 29.

Estos cambios son parte de una serie de características de seguridad y privacidad de cara al usuario que Google ha lanzado en los últimos meses como la de no permitir que los usuarios inicien sesión en sus cuentas de Google desde dispositivos Android con versiones 2.3.7 o inferiores a partir del 27 de septiembre de 2021.

A principios de este año, Google anunció planes para agregar etiquetas de privacidad al estilo de iOS a las listas de aplicaciones en Play Store que resaltan los diversos tipos de datos que se recopilan y cómo se usan, además de limitar el acceso de las aplicaciones. En junio de 2021, Google también se movió para quitar las identificaciones de publicidad de los usuarios al optar por no personalizar los anuncios en la configuración de Android como parte de una actualización de los servicios de Google Play.

A pocas semanas del lanzamiento de Android 12 es interesante que Google se preocupe de mejorar la seguridad de versiones anteriores de Android incluso aunque ya no estén soportadas por los fabricantes de dispositivos.

Fuente: Muy Seguridad

Seguir leyendo...

APT-C-36: troyano con amplia difusión en América Latina

Un grupo de delincuentes informáticos, aparentemente con sede en Colombia, está ejecutando una campaña de phishing que suplanta correos y busca cosechar víctimas en Sudamérica. Los actores maliciosos utilizan una amplia gama de malware y filtros de geolocalización para infectar a ordenadores y evitar ser detectados.

La compañía de ciberseguridad Trend Micro ha identificado a la operación de los ciberdelincuentes como APT-C-36. Como estos utilizan una herramienta de acceso remoto (RAT), se cree que pueden monitorizar y recopilar cualquier tipo de información del ordenador. En el mundo del malware estas herramientas son troyanos que usan backdoor. Este grupo ha ido cambiando y evolucionando los distintos tipos de RATs, tales como:

• njRAT
• Imminent Monitor
• ProyectoRAT modificado
• Warzone RAT
• Async RAT
• Lime RAT
• Remcos RAT
• BitRAT

De momento se sabe que la mayoría de los objetivos están ubicados en Colombia, Ecuador y Panamá. Los ciberdelincuentes utilizan distintos señuelos para lograr que los usuarios bajen el malware. Estos envían correos electrónicos fraudulentos que se hacen pasar principalmente por la Dirección Nacional de Impuestos y Aduanas de Colombia, y la Dirección de Impuestos y Aduanas Nacionales (DIAN).

Los correo correos electrónicos fraudulentos hablan de una "orden de embargo de la cuenta bancaria" e invitan a abrir un archivo con información sobre la supuesta deuda (PDF o Word). Al hacer clic en un enlace incluido en el documento adjunto, el usuario es redirigido a un servidor de alojamiento de archivos y un archivo comprimido se descarga automáticamente.

Cuando el usuario abre el archivo comprimido con la clave suministrada anteriormente, se ejecuta un troyano de acceso remoto basado en BitRAT que fue descubierto por primera vez en 2020. Según los investigadores, entre los afectados se encuentran organizaciones de gobierno, finanzas, salud, telecomunicaciones y energía, petróleo y gas.

Fuente: HiperTextual | TrendMicro

Seguir leyendo...