22 may. 2018

Wicked-Mirai: nueva variante más agresiva

Expertos de la empresa Fortinet identificaron a esta nueva variante de la famosa botnet Mirai a la que denominaron Wicked-Mirai. Esta nueva variante incluye al menos 3 nuevos exploit en comparación a la versión original.

Usualmente los módulos que están dentro del bot Mirai son 3: Attack, Killer, y Scanner. En el analisis que realizó Fortiguard, esta nueva variante "Wicked" se centró en el mecanismo de distribución del malware. La versión original de Mirai utilizaba intentos de fuerza bruta para ganar acceso a los dispositivos Iot, pero la versión nueva viene con algunos exploit ya conocidos para realizar los ataques.

Wicked utiliza los puertos 8080, 8443 80 y 81 para intentar realizar la detección de los dispositivos.
Si la conexión es exitosa este intentará utilizar el exploit y descargar la carga útil.

Dispositivos Objetivos

El exploit que utiliza Wicked depende del puerto en el cual se conectó.

Puerto 8080: Netgear DGN1000 y DGN2200 Routers
Puerto 81: CCTV-DVR
Puerto 8443: Netgear R7000 y R6400
Puerto 80: Invocar Shell de los servidores comprometidos.
Si se realiza la explotación de la vulnerabilidad, este malware descarga un payload desde una página web, en este caso, hxxp://185.246.152.173/exploit/owari.{extension}. Dentro de esa página web, existen varias muestras del botnet Omni, el cual fue aparentemente utilizado en la vulnerabilidad de Gpon CVE-2018-10561.
Encontrar la conexión entre los botnets Wicked, Sora, Owari y Omni nos llevó a una entrevista en abril pasado con un investigador de seguridad que creemos que es el autor de estas variantes de botnet. Básicamente, el autor que usa el pseudo nombre "Wicked" confirmó que es el autor tanto de Sora como de Owari. Cuando se le preguntó sobre el futuro de Sora y Owari, la respuesta de Wicked fue: "SORA es un proyecto abandonado por el momento y seguiré trabajando en OWARI. No verán un tercer proyecto de mí en el corto plazo, ya que continúo expandiendo mis actuales"

Fuente: SeguridadyFirewall

Speculative Store Buffer Bypass: vulnerabilidad en Red Hat y KVM

El equipo de Red Hat Product Security ha sido notificado de una vulnerabilidad calificada como importante que tiene impacto en todas las versiones actualmente soportadas de Red Hat Enterprise Linux y otros productos que contengan kernel. La vulnerabilidad fue detectada en microprocesadores modernos y ocasiona que un atacante sin privilegios pueda hacer uso de este defecto para sortear las restricciones de seguridad y obtener acceso memoria privilegiada. A este problema se le asignó la CVE-2018-3639. Todas las versiones actualmente soportadas de Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Virtualization y Red Hat OpenStack Platform se encuentran afectadas.

Este defecto de ejecución especulativa en la microarquitectura afecta a muchos microprocesadores modernos y puede ser mitigado en el kernel de Linux o en combinación con paquetes de virtualización actualizados y actualizaciones del microcódigo, dependiendo de la arquitectura. Un atacante sin privilegios puede utilizar este defecto para sortear restricciones y obtener acceso a memoria privilegiada que, de otro modo, sería inaccesible.

Speculative Store Bypass es una vulnerabilidad de seguridad descubierta recientemente por varios investigadores de seguridad de Google y Microsoft y bautizada por Spectre-NG y parece ser una cuarta variante del error de hardware de Spectre divulgado públicamente a principios de este año en microprocesadores modernos, y luego descubierto para afectar miles de millones de dispositivos.

Los investigadores de Google y Microsoft descubrieron el error de forma independiente. Los errores se funcionan de manera similar a los errores Meltdown y Spectre, una razón por la cual se clasificaron como "variante 3a" y "variante 4" en lugar de vulnerabilidades separadas por completo.
  • Variante 1: bounds check bypass (CVE-2017-5753) - Spectre v1
  • Variante 2: branch target injection (CVE-2017-5715) - Spectre v2
  • Variante 3: rogue data cache load (CVE-2017-5754) - Meltdown
  • Variante 3a: rogue system register read (CVE-2018-3640)
  • Variante 4: speculative store bypass (CVE-2018-3639)
AMD, ARM, Intel, Microsoft, y Red Hat han publicado avisos de seguridad en el momento de la redacción, con explicaciones de cómo funcionan los errores, junto con los consejos de mitigación.

Esta vulnerabilidad permite a un atacante sin privilegios eludir las restricciones y obtener acceso de lectura a la memoria con privilegios. "Debido a la amenaza planteada por el encadenamiento de vulnerabilidad (la capacidad de explotar una vulnerabilidad explotando otra más), Red Hat sugiere enfáticamente que los usuarios actualicen todos los sistemas incluso si no creen que su configuración esté directamente amenazada", dijo Red Hat en un comunicado de prensa.

En los últimos meses RedHat ha aprendido mucho sobre este ataque Speculative Store Buffer Bypass, para desarrollar mitigaciones y en las próximas semanas, planean compartir más detalles técnicos mientras trabajan con sus clientes para implementar las últimas actualizaciones.

Los clientes que corran kernels y componentes de virtualización, en los productos que se mencionan a continuación, se encuentran afectados. Esta vulnerabilidad afecta tanto al kernel de Linux como a la tecnología de virtualización KVM. Se ha creado un detector de vulnerabilidad y Reglas Red Hat Insights para ayudar a los clientes a comprender su nivel de exposición a la vulnerabilidad.

Red Hat recomienda que los clientes que corran cargas de trabajo en servidores, virtualizadas (host y guest) o en contenedores apliquen los parches necesarios (actualización del kernel, componentes de virtualización y microcódigo de cpu) lo antes posible. Más información en el siguiente artículo: Red Hat Customer Portal Vulnerability Response. Los clientes que corran productos de Red Hat con nuestros partners certificados como proveedores de Cloud deben contactarse con su proveedor de Cloud para obtener más información.

La naturaleza de esta vulnerabilidad y su solución implican la posibilidad de una reducción en el rendimiento de los sistemas en los que se apliquen los parches. El impacto en el rendimiento dependerá del hardware y las aplicaciones en cuestión. Red Hat se encuentra trabajando activamente con sus partners de tecnología para reducir o eliminar el impacto en el rendimiento lo antes posible.

Impacto: El problema tiene impacto en los siguientes productos:
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux for Real Time
  • Red Hat Enterprise Linux for SAP Applications
  • Red Hat Enterprise Linux for SAP HANA
  • Red Hat Enterprise Linux for SAP Solutions
  • RHEL Atomic Host
  • Red Hat Enterprise MRG 2
  • Red Hat Openshift Online v2
  • Red Hat Openshift Online v3
  • Red Hat Virtualization (RHEV-H/RHV-H) 3.6
  • Red Hat Virtualization (RHEV-H/RHV-H) 4.1
  • Red Hat Enterprise MRG (realtime kernel)
  • Red Hat Openstack 7
  • Red Hat Openstack 8
  • Red Hat Openstack 9
  • Red Hat Openstack 10
  • Red Hat Openstack 11
  • Red Hat Openstack 12
Fuente: RedHat

21 may. 2018

Cambiar el hash MD5 de un archivo

MD5 (Message-Digest Algorithm 5) es un algoritmo criptográfico muy utilizado en Internet que nos permite saber muy fácilmente si un archivo mantiene su integridad (por ejemplo, para comprobar que un archivo ha sido descargado correctamente de Internet) o ha sido modificado, tanto por una descarga errónea como mediante un ataque MITM o un ataque al servidor remoto. Siempre que un archivo no haya sido modificado, el MD5 permanecerá intacto. Sin embargo, si por alguna razón necesitamos modificar esta suma de verificación, hay aplicaciones que nos permiten hacerlo muy fácilmente, como es el caso de MD5 Hash Changer.

MD5 Hash Changer es una aplicación muy simple diseñada para permitirnos cambiar el hash de cualquier archivo muy fácilmente sin modificar su propia integridad. Como el hash es siempre igual mientras el fichero permanezca intacto, lo que hace esta aplicación es añadir al final de su código hexadecimal caracteres NULL de manera que, aunque este caracter no afecta a la integridad del archivo, al calcular su suma de integridad el valor es completamente distinto.

Esta aplicación es totalmente gratuita y de código abierto, y la podemos descargar ya compilada para utilizarla en Windows (está programa en C#) desde su página web principal. La única dependencia para que funcione esta aplicación es tener instalado en nuestro ordenador .Net Framework 4.0.

Una vez descargada la aplicación, la ejecutamos en nuestro ordenador (es portable, no tenemos que instalarla) y podremos ver así la ventana principal del programa. Una vez en ella, en la parte inferior podremos ver una serie de botones, de los cuales debemos pulsar sobre el primero para añadir los archivos para los que queremos cambiar el hash al programa.
MD5 Hash Changer

El archivo ya modificado estará en el mismo sitio que el original y, además, funcionará sin problemas y sin ningún tipo de pérdida de contenido, ya que el único cambio realizado es añadir un caracter NULL al final del código hexadecimal del mismo. Eso sí, no estaría mal tener la opción de guardar una copia de seguridad del fichero original, por si acaso algo sale mal por algún motivo, aunque no debería.

Fuente: Redes Zone

Identifican APT Crouching Yeti, conocido por sus ataques a compañías industriales

Kaspersky Lab ha descubierto la infraestructura utilizada por el conocido grupo APT de habla rusa Crouching Yeti, también conocido como Energetic Bear.

Numerosos servidores en diferentes países se han visto afectados desde 2016, a veces solo con el fin de obtener acceso a otros recursos. Otros muchos, incluidos aquellos que alojan sitios web rusos, se utilizaron para ataques "watering hole".

Crouching Yeti es un grupo de habla rusa de amenazas persistentes avanzadas (APT) al que Kaspersky Lab lleva siguiendo desde 2010. Es muy conocido por dirigirse contra industrias de todo el mundo, con un interés prioritario por las instalaciones de energía, con el objetivo de robar datos valiosos de los sistemas. Una de las técnicas que el grupo utiliza es la de los ataques "watering hole" (los atacantes inyectan en una web un enlace que redirige a los visitantes a un servidor malicioso).
Kaspersky descubrió recientemente una serie de servidores, comprometidos por el grupo, que pertenecen a diversas organizaciones con sede en Rusia, EE.UU., Turquía y varios países europeos, no limitándose exclusivamente a empresas industriales. Según los analistas, estos servidores fueron comprometidos en 2016 y 2017 con objetivos diferentes. Así, además de los ataques "watering hole", estos servidores también se utilizaron en algunos casos como intermediarios para lanzar ataques contra otros recursos.

Durante el análisis de los servidores infectados, los analistas identificaron numerosos servidores y webs utilizados por organizaciones de Rusia, EE. UU., Europa, Asia y Latinoamérica, que los atacantes habrían escaneado con varias herramientas, posiblemente para encontrar un servidor que pudiera usarse como host para alojar sus herramientas y, más adelante, lanzar un ataque. Algunas de las webs escaneadas podrían considerarse como candidatas para usarse en un "watering hole". La gama de webs y servidores que atrajeron a los intrusos es bastante amplia. Los analistas descubrieron que los ciberdelincuentes habían escaneado sitios web muy variados, desde tiendas y servicios online, organizaciones públicas, ONGs, fabricantes, etc…

Los analistas también encontraron que el grupo usó herramientas maliciosas de dominio público diseñadas para analizar servidores y para la búsqueda y recopilación de información. Además, durante su análisis encontraron un archivo sshd modificado con una puerta trasera. Este archivo se utilizó para sustituir el archivo original y la puerta podía abrirse mediante una “contraseña maestra”

"Crouching Yeti es un famoso grupo de habla rusa que lleva activo muchos años activo y que todavía tiene éxito en sus ataques contra grupos industriales utilizando ataques tipo "watering hole", entre otras técnicas. Nuestros análisis muestran cómo el grupo comprometió servidores no solo con la intención de crear ataques de "watering hole", sino también para otros análisis, y que activamente utilizaron herramientas de código abierto que posteriormente dificultaron bastante su identificación" dijo Vladimir Dashchenko, jefe del grupo de análisis de vulnerabilidades en Kaspersky Lab ICS CERT.

"Las actividades del grupo, como la recopilación inicial de datos, el robo de datos de autenticación y el escaneo de recursos, se utilizan para lanzar más ataques posteriores. La variedad y diversidad de servidores infectados y el tipo de recursos escaneados, sugiere que el grupo puede estar operando a cuenta de terceros", añadió.

Fuente: DiarioTI

Un año después de WannaCry, el exploit EternalBlue es más grande que nunca

El pasado 12 de mayo fue el primer aniversario del brote de ransomware WannaCry. Un año después de uno de los mayores incidente de seguridad cibernética de la historia, el ataque WannaCry ahora es más popular que nunca, según datos de telemetría recopilados por ESET.

Llamado EternalBlue, el exploit fue supuestamente desarrollado por la división cibernética de la Agencia de Seguridad Nacional de los Estados Unidos. EternalBlue fue parte de un gran caché de herramientas que un grupo de hackers conocido como The Shadow Brokers robó de los servidores de la NSA en 2016 y luego se filtró en línea desde agosto de 2016 hasta abril de 2017.

Muchos sospechan que la NSA podría haber notificado a Microsoft sobre lo que robaron Shadow Brokers, porque en marzo de 2017, un mes antes de que EternalBlue fuera lanzado, Microsoft lanzó MS17-010, un boletín de seguridad que contiene parches para los muchos exploits de SMB incluidos en Shadow Broker.

Lo que sucedió a continuación está bien documentado, con EternalBlue siendo utilizado para crear un mecanismo de autoexpansión para el ransomware WannaCry, y más tarde para los siguientes brotes de ransomware como NotPetya y Bad Rabbit.

El impacto de EternalBlue fue devastador, ya que las compañías informaron daños totales de más de 8 mil millones de dólares en 150 países solo por el incidente de WannaCry, según IBM X-Force.
WannaCry-impacto
Pero la versión inicial de EternalBlue no era perfecta. Solo funcionó en Windows 7 y Windows Server 2008 y se bloqueaba en Windows XP.

EternalBlue hizo mucho daño, pero había muy pocos autores de malware que supieran cómo usarlo. Esta es la razón por la cual, según ESET, poco después de WannaCry, el uso de EternalBlue se redujo enormemente.

"EternalBlue tuvo un período más tranquilo inmediatamente después de la campaña WannaCryptor 2017", explica Ondrej Kubovič de ESET. "En los meses siguientes, los intentos de usar el exploit EternalBlue se redujeron a 'solo' cientos de detecciones diarias".
EternalBlue2017-Mayo2018

EternalBlue crece más allá de WannaCry a nivel de malware

Pero las cosas cambiaron durante los incidentes post-WannaCry y post-NotPetya. Para empezar, los investigadores de seguridad transfirieron EternalBlue a más plataformas, como Windows 8 y Server 2012, y más tarde incluso Windows 10.

Esto amplió la capacidad del exploit para infectar a más víctimas de lo habitual y lo convirtió en un producto básico entre los creadores de malware.

En los meses siguientes, EternalBlue se extendió para realizar desde la minería de criptomonedas hasta para crear un arsenal para los grupos de ciberespionaje a nivel estatal.

EternalBlue sigue vivo gracias a los sistemas sin parches

Incluso si EternalBlue ya no se usa para ayudar al ransomware a convertirse en una pesadilla virulenta a nivel global (solo a nivel de red), la mayoría de los usuarios habituales no saben que sigue siendo una de las mayores amenazas de la actualidad.

Esta amenaza no solo proviene de los autores de malware que continúan armamentándola para un conjunto diverso de operaciones. Los autores de malware nunca se molestarían con un exploit ineficiente. ExploitBlue sigue siendo una amenaza debido a las máquinas vulnerables que todavía están disponibles en línea.

De acuerdo con Nate Warfield del Microsoft Security Response Center, todavía hay muchos sistemas vulnerables de Windows que exponen su servicio SMB disponible en línea.

También es probable que EternalBlue sea una de las razones por las que Microsoft reaccionó enviando nuevas versiones del sistema operativo Windows con SMBv1 deshabilitado, ya que era el protocolo al que apunta EternalBlue.

EternalBlue seguirá siendo una amenaza en los próximos años

Kryptos Logic, la compañía detrás del sumidero WannaCry también reveló lo mismo hace unas semanas. La compañía señaló que las infecciones residuales de WannaCry siguen usando EternalBlue para infectar a nuevas víctimas, incluso hasta el día de hoy, con "millones" de dispositivos escaneando Internet en busca de sistemas sin parches y desplegando EternalBlue en intentos de infectarlos con WannaCry.

El sumidero evita que WannaCry encripte los archivos, pero el exploit de EternalBlue utilizado para el sistema de autoexpansión de WannaCry todavía funciona perfectamente, incluso hasta el día de hoy.

El punto clave es que las organizaciones que no aplican el parche MS17-010 han contribuido al éxito reciente de EternalBlue, y sus sistemas vulnerables mantendrán activa esta amenaza en los próximos años, al igual que todavía vemos gusanos de principios de la década de 2000 que aún existen.

Fuente: TecnoNucleous

20 may. 2018

Ciberdelincuetes roban U$S15 millones en México (#SPEI)

A finales de Abril, diversos bancos mexicanos registraron que estaban sufriendo fallas en sus sistemas de pagos y transferencias interbancarios. En este caso, el SPEI (Sistema de Pagos Electrónicos Interbancarios), que es administrado por el Banco de México(Banxico) por ser la institución financiera central del país, fue lo que presentó problemas.

El sistema SPEI de México es una red doméstica similar al sistema de mensajería global SWIFT que mueve miles de millones de dólares diariamente.

El 27 de abril las transferencias electrónicas de los bancos se volvieron lentas. Siendo viernes y fin de mes, varios mexicanos esperaban el pago de sus salarios por lo que algunos usuarios comenzaron a denunciar las irregularidades. El Banco de México fue el primero en notar que existían varios movimientos extraños en las transferencias bancarias a través de SPEI. En México, el banco central ha utilizado y ha desarrollado esta plataforma para homogeneizar las transacciones electrónicas con todas las instituciones bancarias del país. Al notar las irregularidades, el Banco de México ordenó el cierre del sistema.

Aunque se cree que fue un intento de ciberataque o una vulnerabilidad en el SPEI lo que causó que miles de trabajadores no recibieran sus pagos, Banxico rechazó la posibilidad. En su lugar acusó a los bancos afectados de ser los responsables del problema, y les ordenó trabajar en un protocolo de contingencia que provocaría retrasos en los movimientos realizados.

Este protocolo de contingencia pone las transacciones en manos humanas, por lo que aunque han sido capaces de realizar algunos pagos y de retornar dinero a las cuentas originales de aquellos movimientos que no se completaron, toma una considerable cantidad de tiempo el realizar todo esto.

Luego se confirmaron más problemas. En una reunión de emergencia, Banxico decidió desconectar a más bancos del SPEI tras encontrar una nueva vulnerabilidad en los servicios de un proveedor. Todos los bancos que tienen a Apesa como proveedor han sido desconectados del SPEI, y se les ha obligado a operar por medio del COAS (Cliente de Operación Alterno SPEI), el mismo protocolo de contingencia que ya está en utilización por los otros afectados.

Los problemas ya se veían venir; y ahora parecen confirmarse. El hackeo a diferentes entidades bancarias dejó un saldo de entre 300 y 400 millones de pesos (U$S15 a 20 millones) desaparecidos.

Sin embargo, una vez más se rehusaron a compartir ni explicar las razones, la vulnerabilidad encontrada, o incluso cuáles serían las instituciones que han sido afectadas. Solo rechazan, una vez más, que haya sido un ciberataque el origen del problema.

Entre los afectados se encuentran los bancos Afirme, Banco del Bajío, Ve por Más, Inbursa, JPMorgan, Zurich y otros que no han sido mencionados.

Aunque ya van 3 semanas de problemas, a los clientes se les ha dejado a ciegas en cuanto a una razón o solución de los problemas y el Banco de México minimizando este hackeo; pero el día de hoy la bomba millonaria ha estallado. Según Reuters, son alrededor de 300 millones de pesos los que han sido robados por ciberdelincuentes. Y el problema afectó a todo el mundo: desde hace semanas, miles de personas recibieron tarde su nómina (incluso días después).

Uno de los bancos más afectados fue Banorte con alrededor de 150 millones de pesos faltantes.

Así pasó...

Los delincuentes crearon órdenes fantasmas en banca online para transferir fondos a cuentas falsas. El dinero fue retirado inmediatamente. No, no fue una gran operación maestra.
Los montos de estas órdenes fantasmas iban de decenas de miles de pesos hasta cientos de miles. Y sí, Banorte fue el más golpeado. Pero los delincuentes no actuaron solos. El dinero fue enviado, sí, a cuentas falsas; pero fueron sus cómplices dentro de casi todos los bancos los que retiraron el dinero en efectivo.

Por ahora, los bancos investigan a su propio personal: las sospechas de cómplices internos son fuertes. Las cantidades de dinero que se retiraron eran demasiado grandes como para pasar desapercibidas de esa forma.

"Estas transferencias no autorizadas se originaron en el sistema que conecta las instituciones con el sistema de pagos", dijo Lorenza Martínez, directora del SPEI en una entrevista, señalando que los bancos habrían migrado a una tecnología alternativa y más lenta para procesar los pagos. Martínez dijo que el sistema de transferencia interbancaria SPEI del banco central no se vio comprometido, pero que el problema tenía que ver con el software desarrollado por instituciones o proveedores externos para conectarse al sistema de pagos.

Hasta ahora ningún cliente se ha visto afectado, según declaraciones del Banco Central y diferentes entidades bancarias. Las transferencias fueron directo desde las cuentas de los bancos dentro del Banco Central.

¿Otro robo tipo SWIFT?

Las incidencias relacionadas con el sistema SPEI muestran similitudes con el robo de 87 millones de dólares al Banco Central de Bangladesh ocurrido en 2016.

Mientras que SPEI comunica a alrededor de 100 entidades, entre bancos, casas de bolsa, casas de cambio, afores y otras, dentro de territorio mexicano y bajo la supervisión del Banxico, SWIFT conecta a más de 11.000 instituciones bancarias y de valores que operan en 200 países a través de un sistema controlado por 3.000 instituciones financieras agrupadas en un esquema de cooperativa.

Ambos sistemas requieren de otros sistemas intermedios (middleware) que conectan a las entidades financieras con la red de transferencias. Dichos sistemas intermedios pueden ser desarrollados por la propia entidad o por un proveedor externo. En el caso de SWIFT, el middleware que fue vulnerado para llevar a cabo el fraude al Banco de Bangladesh fue el programa para servidores SWIFT’s Alliance Access, de acuerdo con BAE Systems citado por Reuters.

En México, aunque se ha dado a conocer que el proveedor del software que funciona en la plataforma de conexión entre la banca mexicana y el SPEI es LGEC, Sistemas de Integración y Enlace, Fernando Gutiérrez, su director general, dijo en una entrevista con El Economista que "el fallo reportado no necesariamente proviene de su software" y que no son el único proveedor de este tipo de aplicativos dentro del mercado mexicano.

Continuará...

Fuente: FayerWayer

19 may. 2018

Actualizaciones de seguridad en Adobe Acrobat

Adobe ha publicado actualizaciones de seguridad para Adobe Acrobat y Reader. Entre los fallos corregidos, hay una ejecución remota de código arbitrario.

Hace poco los investigadores de ESET descubrieron dos vulnerabilidades zero-day, una en la mencionada aplicación y otra en el sistema operativo Windows, que combinadas puede terminar siendo un arma peligrosa en manos de los atacantes. 23 de estos fallos permitirían ejecutar código arbitrario, por lo que han sido categorizados como críticos.

La vulnerabilidad que afecta a Adobe Reader (CVE-2018-4990) es una ejecución de código en remoto, mientras que la de Windows (CVE-2018-8120) es una escalada de privilegios que se ejecuta en el espacio del Kernel. Esto abre la puerta a ejecutar código arbitrario con altos privilegios sobre un sistema vulnerable, sin que se requiera de un elevado nivel del interacción por parte del usuario. Las Ameanzas Persistentes Avanzadas suelen apoyarse bastante en este tipo de combinaciones para llevar a cabo campañas que llegan a tener un gran impacto.

Para explotarlas solo se necesita de un fichero PDF malicioso con JavaScript embebido, aunque este también tiene que saltarse un mecanismo de aislamiento (sandbox) incorporado en Adobe Reader llamado Protected Mode. Esta medida de protección dificulta la explotación de vulnerabilidad en la propia aplicación, y la forma más efectiva de saltársela es apoyándose en otro fallo de seguridad localizando en el sistema operativo que está ejecutando Adobe Reader.

Nada más abrir el PDF malicioso, el JavaScript que contiene entra en ejecución para manipular el objeto Button1, que contiene una imagen JPEG2000 específicamente diseñada para explotar las dos vulnerabilidades. Los atacantes han implementado técnicas de pulverización para corromper las estructuras internas de datos y así poder leer y escribir en el acceso a la memoria. Luego los atacantes localizan la dirección de memoria en la que se encuentra en plugin Escrip.api, que es el motor de JavaScript propio de Adobe Reader. El JavaScript malicioso establece una cadena de instrucciones de ensamblaje que podría llevar a la ejecución código de shell nativo.

La vulnerabilidad de Windows es utilizada para romper el aislamiento de Adobe Reader. Concretamente, se encuentra en la función NtUserSetImeInfoEx de Win32k, que es un componte del Kernel de Windows. Lo que hay que hacer para llevar a cabo el ataque es que la subrutina SetImeInfoEx de NtUserSetImeInfoEx no valide ningún puntero de datos, permitiendo así punteros de desreferencia NULL. Por lo tanto mapeando una página NULL y estableciendo un puntero a offset 0x2C, un atacante puede apoyarse en la vulnerabilidad para escribir en una dirección de memoria arbitraria en el espacio del kernel. Sin embargo, es importante tener en cuenta que desde Windows 8 los usuarios no pueden mapear una página NULL.

Con un total de 47 vulnerabilidades corregidas, Adobe ha publicado parches que dan solución a un variado espectro de errores de programación: desbordamiento de memoria heap, double free (liberación reiterada del mismo recurso), uso de recursos ya liberados, escritura y lectura fuera de límites o evasión de restricciones de seguridad entre otras.

Adobe ha puesto ha disposición de sus usuarios las actualizaciones pertinentes para las versiones de sus programas en los sistemas operativos Microsoft Windows y Apple MacOS.

Fuente: Hispasec | Muy Seguridad

18 may. 2018

Detenido creador de Phishing

Hace unos días fue detenido en Sao Paulo un joven llamado Douglas Arrial. Esta persona comercializaba en la deep web su herramienta [A]pache Next Generation Advanced Phishing Kit.

Este es un conjunto de aplicaciones para hacer phishing, es decir, herramientas para que alguien sin conocimientos mínimos de informática pueda sustraer todos los datos de una o más personas: contraseñas de redes sociales, correos electrónicos, dirección, número de identidad, acceso a cuentas bancarias y tarjetas de crédito. La mayoría de sus clientes eran hackers que se dedican a vender estos datos en la Dark Web a cambios de Bitcoins u otra criptomoneda que sea imposible de rastrear.

Los precios de los datos robados varían, desde algunos centavos de Euro por lo más barato, como el acceso al email, hasta el paquete completo, como se muestra a continuación:

Es posible leer toda la investigación de identificación del hacker en el documento proporcionado por Checkpoint [PDF].

Fuente: Pauta

Malware de minería realiza medio millón de ataques en tres días

La instalación de un software de minería desde la web, a espaldas de los usuarios, es una tendencia muy en boga. Pero esta semana tomó un giro más agresivo, con un malware denominado WinstarNssmMiner, del cual se han detectado 500.000 ataques en tres días y habría dejado hasta 30.000 dólares en ganancias para los delincuentes en la criptomoneda monero.

Dentro de las criptomonedas que pueden ser minadas con computadores convencionales, monero es de las preferidas, ya que ofrece buenos rendimientos cuando se logra acumular la capacidad de minería de muchos usuarios, aún si cada PC es ocupada pocos segundos, a través de los denominados scripts de minería. Estas rutinas instaladas subrepticiamente en un servidor –o de manera deliberada–, usan parte del poder de cómputo de los usuarios que se conectan al sitio web para minar criptomonedas.

La técnica conocida como cryptojacking, que se define como el uso no autorizado de computadoras o smartphones para minar criptomonedas mediante la instalación de un programa en los dispositivos, sin que el usuario lo advierta. Al momento de publicar este análisis (el miércoles) ha recibido 133 moneros, lo cual es aproximadamente el equivalente de 28 mil dólares estadounidenses. 360 Total Security
Cuando el sistema está infectado, el minador ejecuta dos procesos: uno para minar monero y el otro, que se ejecuta en el background, se encarga de detectar los antivirus, para tratar de evitarlos, dice 360TS. "WinstarNssmMiner, a pesar de que tiene la habilidad de burlar algunos antivirus, es efectivamente un criptominero, y su implementación se basa en el proyecto de código abierto XMRig", señala la firma de seguridad.

Cabe destacar que XMRig (WaterMiner) es el minero de alto rendimiento de Monero compatible con el sistema operativo Windows. 360TS ofrece, como la mayoría de las firmas desarrolladoras de software de seguridad, una herramienta de protección gratuita, que tiene la capacidad de detectar y remover el software WinstarNssmMiner.

Los mineros web han tenido un extraordinario auge este año; el incremento de los sitios web que usan el poder de cómputo de los equipos de sus visitantes supera el 4.000% [PDF], según un reporte de Malwarebytes. El gran crecimiento del mercado de criptomonedas en 2017 fue el principal factor de este aumento acelerado de los mineros web, especialmente en el caso de las altcoins cuyo proceso de minería requiere un poder de cómputo mucho menor que bitcoin o ether.

De acuerdo a Microsoft Secure, desde septiembre de 2017 hasta enero de 2018 ha ocurrido un incremento en ataques "troyanizados" de minería que coincide con una disminución del volumen de ataques de ransomware. Hecho que, consideran, puede relacionarse a un cambio de enfoque por parte de los hackers para monetizar sus actividades con criptomonedas.
Fuente: Criptonoticias

Delincuentes publican dos graves vulnerabilidades por error

Un grupo de delincuentes desconocido ha destapado sus armas por error. Cuando se va a desarrollar algún tipo de malware, lo primero que necesita es encontrar una vulnerabilidad informática que poder explotar, y después sí puede ponerse manos a la obra con la herramienta que vaya a utilizar para el ataque. De una forma muy simplificada, este es su flujo de trabajo. Y en el mismo, algunos de los pasos han fallado porque han desvelado por error la vulnerabilidad que iban a utilizar. Eran dos, y ya están resueltas.

Anton Cherepanov, investigador de la compañía de seguridad informática ESET, descubrió estas dos vulnerabilidades. Las encontró en muestras de malware sobre las que estaban trabajando estos delincuentes, y que en ese momento no estaban todavía finalizadas. Es decir, que a esas alturas el grupo no podía aún llevar a cabo el ataque informático que estaban planeando. Sin embargo, estas muestras de malware ya contenían referencias a las dos vulnerabilidades de seguridad. Una de ellas relacionada con Adobe Acrobat Reader PDF (APSB18-09); y la otra, con el componente Win32k de Windows (CVE-2018-8120).


La exposición de las dos vulnerabilidades (PDF samples [1, 2]), que los hackers llevaron a cabo sin intención de ello, se produjo al cargar un archivo PDF a un motor público de análisis de malware. Este investigador de seguridad, de la compañía ESET, fue el que detectó la amenaza e informó de forma privada a Adobe y Microsoft. Tanto una como la otra compañía, en un plazo de dos meses aproximadamente, han resuelto los problemas de seguridad antes de que ningún malware haya llegado a afectar a ningún usuario aprovechando estas dos vulnerabilidades. En los archivos PDF era donde se encontraban una amplia cantidad de muestras de malware, entre ellas algunas sobre las que se estaba trabajando.

La vulnerabilidad de Adobe habría permitido ejecutar código malicioso a través del programa. La de Windows, sin embargo, habría permitido "escapar" de la carga del código limitada únicamente al programa de Adobe, y de esta manera atacar al sistema operativo al completo. La idea, básicamente, era atacar ordenadores –de diversas formas- utilizando el programa Adobe Acrobat Reader como puerta de acceso al ordenador.

Fuente: Bleeping Computer