Autor: Dgeldres

Cibercriminales están explotando activamente una vulnerabilidad Drupal

Una vulnerabilidad descubierta recientemente en Drupal esta siendo explotada activamente por cibercriminales

El pasado 19 de Febrero se hizo pública una nueva vulnerabilidad (CVE-2019-6340) para el sistema de gestión de contenidos Drupal, justo después de que sus desarrolladores publicasen una nueva versión que la resuelve.
El fallo de seguridad es del tipo RCE (Remote Code Execution), es decir, que la explotación de la vulnerabilidad permite la ejecución remota de código en el servidor en el que se aloja Drupal.
El fallo se trata de un ‘Object Injection’, una vulnerabilidad típica en aplicaciones desarrolladas en PHP, y que consiste en proporcionar un objeto PHP serializado a través de una petición HTTP que será posteriormente deserializado en el servidor. Dicha deserialización transformará el objeto serializado en un objeto real PHP que podrá ejecutar código.
Aunque haya sido corregida, aún muchos usuarios de este popular gestor de contenidos no han tenido la oportunidad de actualizar a la nueva versión para estar protegidos. Por ello, los cibercriminales están aprovechando la situación explotando este fallo de seguridad para comprometer el sistema e inyectar en las webs código JavaScript para minar criptomonedas. Este código JavaScript pertenece a CoinIMP, un servicio de minado de criptomonedas para navegadores similar a CoinHive.
Desde Hispasec, como siempre, os recomendamos actualizar lo antes posible vuestro Drupal para estar protegidos frente a estos ataques.

Miles de servidores C&C de malware expuestos por una vulnerabilidad

Una vulnerabilidad en un software utilizado por los cibercriminales ha permitido revelar la ubicación de miles de servidores de mando y control o C&C (del inglés ‘command and control’) de malware.

Imagen de cobaltstrike.com

Cobalt Strike es una herramienta legítima de prueba de penetración con una arquitectura cliente-servidor, utilizada por los investigadores de seguridad para probar la resistencia de una organización contra ataques dirigidos. En los últimos años, Cobalt Strike se ha convertido en parte del kit de herramientas utilizado por desarrolladores de malware y grupos cibercriminales como FIN6 y FIN7 (Carbanak) o APT29 (Cozy Bear). Los atacantes aprovechan Cobalt Strike para alojar sus servidores de C&C de malware que se comunican con los equipos infectados a través de ‘beacons’.

Sin embargo una vulnerabilidad en este software ha resultado clave para descubrir las ubicaciones de miles de servidores de comando y control de malware (C&C). El fallo se encontraba en el código de NanoHTTPD, un servidor web de código abierto basado en Java, al agregar un espacio en blanco adicional después del código de estado de las respuestas HTTP. Dicha particularidad en las respuestas del servidor ha sido utilizada por investigadores de la empresa de seguridad Fox-IT para detectar las comunicaciones entre los ‘beacons’ y sus servidores C&C desde 2015.

Espacio en blanco adicional en la respuesta HTTP

Desde ese año hasta el pasado mes de enero de 2019, cuando los desarrolladores de Cobalt Strike corrigieron el error, los investigadores de Fox-IT han observado un total de 7718 servidores de Cobalt Strike. Aunque, como cabe esperar, muchos de ellos son legítimos también se incluyen servidores C&C de malware vinculados a la unidad de piratería gubernamental APT10 de China, del troyano bancario Bokbot, y Carbanak.

Los investigadores de seguridad han revelado una lista de direcciones IP que alojaban o siguen alojando servidores C&C de Cobalt Strike.

KnownSec 404 Team, una empresa china de seguridad IT ha confirmado el descubrimiento de Fox-IT al identificar 3643 servidores basados ​​de Cobalt Strike operativos (un 86% de los cuales se corresponden con la lista suministrada por Fox-IT).

Según aventuran los investigadores de Fox-IT, el truco de la exploración del espacio en blanco cada vez redundará en un menor número de resultados debido a que los servidores legítimos se están actualizando a la versión 3.13, con la vulnerabilidad corregida. Sin embargo también opinan que, debido a que los delincuentes cibernéticos tienden a utilizar versiones no legítimas de software, estas se quedarán sin recibir la actualización y por tanto los servidores de C&C de malware podrán seguir siendo rastreados. Al menos durante un tiempo.

Más información:

Identifying Cobalt Strike team servers in the wild
https://blog.fox-it.com/2019/02/26/identifying-cobalt-strike-team-servers-in-the-wild/

Historical list of {Cobalt Strike,NanoHTTPD} servers
https://github.com/fox-it/cobaltstrike-extraneous-space/

Arrestado el líder detrás de Cobalt y Carbanak
https://unaaldia.hispasec.com/2018/03/arrestado-el-lider-detras-de-cobalt-y-carbanak.html

La mayor plataforma de Bug Bounty confirma el tópico. Jóvenes, americanos y sin estudios superiores

HackerOne ha publicado un informe donde son encuestados más de mil investigadores de seguridad para obtener las últimas estadísticas, tendencias y perspectivas de la comunidad.

El informe comparte distintas estadísticas, como las edades, ubicación, estudios y preferencias de sus usuarios, en las que, como citamos en el título de la noticia, se confirman algunos de los tópicos que rodean la figura del hacker.

En él también se da a conocer como dos de los usuarios, Mark Litchfield y Santiago López, han alcanzado el millón de euros en recompensas a través de su plataforma.

Para los que no lo sepan, una plataforma de Bug Bounty, es la encargada de la mediación entre las empresas y los investigadores de seguridad. Por un lado las empresas ofrecen recompensas para que los investigadores hagan una publicación responsable de las vulnerabilidades encontradas y los investigadores reconocimiento y una compensación económica.

Entre otros datos llamativos, cabe destacar la herramienta Burp Suite, como la favorita entre los investigadores de seguridad.

A través del siguiente enlace podéis descargar el informe completo.

Google revela un error de “alta severidad” sin parchear en el núcleo de Apple macOS

Investigadores de Google Project Zero han hecho pública una vulnerabilidad en macOS, después de que Apple no haya liberado un parche en los 90 días previos a la publicación.

Descubierto por el investigador Jann Horn y demostrada por Ian Beer. La vulnerabilidad reside en la forma que el kernel de macOS, XNU, permite a un atacante manipular el sistema de ficheros sin informar al Sistema Operativo.

Esta vulnerabilidad podría permitir a un programa malicioso saltarse la funcionalidad Copy-on-Write (COW) y modificar la memoria compartida entre procesos, llegando a corromperla.

Copy-On-Write o COW es una optimización en la administración de recursos usada en computación. En este caso, se da cuando un proceso necesita un fichero o dato que ya se encuentra en la memoria de otro proceso. Ambos procesos pueden compartir dicho recurso en lugar de crear una nueva copia, reduciendo de esta forma recursos.

Sin embargo, si uno de estos procesos necesita realizar algún cambio sobre el recurso, la función COW aparece y crea una nueva copia en la memoria, de forma que el otro proceso pueda también tener acceso al recurso.

Los investigadores vieron que cuando la imagen de un sistema de ficheros montado es modificada directamente (con la llamada pwrite() ), esta información no es propagada en el sistema de ficheros montado.

Por tanto, un programa malicioso puede hacer cambios en la memoria liberada almacenada en el disco sin informar al subsistema de administración virtual (virtual management subsystem), engañando al proceso destino para que cargue contenido malicioso en la memoria.

La vulnerabilidad fue notificada a Apple en noviembre de 2018 y ésta reconoció la existencia del fallo. Pero a día de hoy aun no se ha solucionado a pesar del aviso. De modo que los investigadores han publicado la falla con criticidad alta y también han liberado una prueba de concepto.

Más información:

https://thehackernews.com/2019/03/cybersecurity-macos-hacking.html

Análisis preliminar de Ghidra, el framework de reversing de la NSA.

Análisis preliminar de Ghidra, el framework de reversing de la NSA.

En la noche de ayer (del 5 al 6 de marzo) fue liberado el nuevo framework de ingeniería inversa de la NSA denominado “Ghidra”. Hoy os contamos nuestras primeras impresiones tras haber realizado algunas pruebas.

URL de descarga: https://www.ghidra-sre.org/

Instalación:

Ghidra funciona sobre Windows, Mac y Linux. Instalar este framework es tan simple como descomprimir el archivo ZIP de la descarga en nuestro equipo. El único requisito para el correcto funcionamiento del software es tener instalada la versión 11 de Java Development Kit o superior.

Si aún así tenéis alguna duda, en la web proporcionada hay un pequeño vídeo explicativo.

Primeras impresiones:

Lo primero que podemos ver al abrirla es que se trata de la versión 9.0 del programa, por lo que puede inferirse que lleva muchos años siendo utilizada y que ha pasado por numerosas etapas para la mejora de su código, lo que, en principio, nos lleva a pensar que estamos ante una herramienta madura y a prueba de errores.

Al crear un nuevo proyecto, nos muestra un baúl de herramientas con dos opciones: “CodeBrowser” y “Version Tracking”. Analizaremos en esta ocasión la herramienta “CodeBrowser”.

Si abrimos un binario, la herramienta nos lo analiza y nos muestra el desensamblaje del código en una interfaz que nos parece bastante amigable, en comparación con otros frameworks similares.

Aunque los tiempos de carga son casi mínimos, la optimización del consumo de recursos no es su punto fuerte, ya que consume bastante más que otras herramientas que tienen el mismo objetivo.

Como punto a favor de su usabilidad, existe una cheatsheet oficial con los shortcuts más importantes del programa. Puede accederse a la plantilla a través de este enlace.

Fallos reconocidos en las primeras 12 horas:

Apenas unas horas después de la salida del producto, varios expertos en ciberseguridad se han hecho eco de un fallo en la apertura del puertoJDWP (18001) en el modo debugque se pone a la escucha en todas las interfaces y permite ejecución de código remoto. A continuación vemos un ejemplo del fallo que describimos:

Here is a screen shot that proves RCE in the JDWP service when running Ghidra in debug mode. The issue is that the NSA left an asterisk * instead of something sane like “127.0.0.1” – exposing JDWP to all interfaces and allowing exploitation. It’s not default, but a bugdoor. pic.twitter.com/YYTU8Qdx8T

— Hacker Fantastic (@hackerfantastic) March 6, 2019

Usando un motor de búsqueda de dispositivos conectados a internet como shodan.io podemos ver ya algunos equipos que ahora mismo podrían ser vulnerados.

La solución más simple sería modificar el código que hace referencia a la interfaz y ponerlo solo a la escucha en localhost.

El issue se encuentra abierto en Github ahora mismo. URL: https://github.com/NationalSecurityAgency/ghidra/issues/6.

Opiniones publicadas:

Varios expertos en reversing ya se han pronunciado sobre la herramienta, manteniendo diferentes opiniones sobre la utilidad del producto:

The same capabilities with IDA Pro would cost you ~$13,000 (and it supports less architectures). As much as I love IDA, their monopoly is the bane of my existence.

— MalwareTech (@MalwareTechBlog) March 6, 2019

After playing with ghidra for an hour pic.twitter.com/EW5PEBLdDU

— Malware Unicorn (@malwareunicorn) March 6, 2019

Para estar al tanto de la opinión de la comunidad acerca de Ghidra, existe un post anclado en Reddithttps://www.reddit.com/r/ReverseEngineering/comments/ax2gma/ghidra_stickied_thread/

Ethereum Classic sufre un ataque 51%

La popular serie de atresmedia “La casa de papel” en la que una banda organizada entra en la casa de moneda y timbre con el objetivo de robar millones de euros parece cobrar vida en la red. A grandes rasgos, un supuesto grupo organizado ha robado 1,5 millones de dólares haciéndose con el 63% de la tasa total de hash de la red de Ethereum.

El ataque

¿Qué es un ataque 51%?
Las criptomonedas están basadas en redes distribuidas y descentralizadas con la intención de que cualquiera pueda acceder a ellas de manera más o menos sencilla, o lo que es lo mismo, una democracia digital en la que 100 hipotéticos usuarios controlan las transacciones. Si alguien pudiese controlar 51 de esos 100 usuarios con derecho a voto, tendría el control total de la red, lo que daría lugar a la posibilidad de crear una bifurcación de la red o incluso bloques falsos.

Ethereum Classic ha sido, supuestamente, víctima de este tipo de ataque. El pasado día 6 de enero la empresa china SlowMist hacía pitar las alarmas, al poco tiempo, un analista de CoinNess que investigaba el suceso descubrió que un grupo privado había logrado aumentar su poder de hash a 3.263GH/s (300GH/s de tasa normal), logrando ser el grupo minero más poderoso durante un breve período de tiempo en el que podría haberles dado tiempo a robar 88.500 Ethereum Classic (ETC), el equivalente a 460.000 dólares. Pero no acabó ahí, unas 10 horas más tarde volvía a aumentar su tasa de hash.

Coinbaseuna de las webs más reconocida para el intercambio, compra y venta de criptomonedas, detuvo todas las transacciones de Ethereum Classic. El exchange descubrió otros 12 ataques que tenían relación con Ethereum y los gastos dobles, ascendiendo la cantidad a 219.500 ETC o 1,1 millones de dólares al cambio.

La empresa

Para la sorpresa de muchos, los desarrolladores de la criptomoneda afirman que el blockchain no ha sido objetivo de ningún ataque, además de negar la noticia del doble gasto. Todo el revuelo lo achacan a una “reorganización profunda de la cadena de bloques”, tal y como dicen en su twitter.

On 1/5/2019, Coinbase detected a deep chain reorganization of the Ethereum Classic blockchain that included a double spend. In order to protect customer funds, we immediately paused movements of these funds on the ETC blockchain. Read more here: https://t.co/vCx89dz44m

— Coinbase (@coinbase) 7 de enero de 2019

Los desarrolladores de ETC respondieron rápidamente a las acusaciones afirmando que un grupo de mineros estaban siendo “poco honestos” ejerciendo una minería egoísta. Además explicaron que el fabricante linzhi estaba en proceso de probar nuevas máquinas Ethash, lo que resultó en una subida de más del 50% en la tasa de hash, no teniendo nada que ver esto con un ataque 51%. También dieron respuesta al tema de los gastos dobles alegando no haberlos detectado.

A pesar de la respuesta por parte del equipo de Ethereum Classics, Coinbase sigue bloqueando las transacciones de ETC y está monitorizando la moneda para determinar la actividad en el futuro.

Contramedidas de las casas de cambio

Pocas son las casa de cambio que han emitido algún tipo de comunicado que tenga relación al supuesto ataque 51%, pero alguna de ellas han detenido el retiro y depósito de la criptomoneda.

Coinbase comunicó que sus fondos no fueron afectados ya que detuvieron las transacciones a tiempo

Poloniex tiene bloqueadas las transacciones hasta el día 9 o nuevo aviso a la espera de que la red de Ethereum se estabilice, tal y como dijo por twitter, y aseguran que los fondos de los usuarios se encuentran a salvo.

Due to a potential 51% attack, ETC wallets have been disabled and will not be re-enabled until tomorrow (at the very earliest). We will update this thread when we have a firmer timeline for re-enabling deposits and withdrawals. Poloniex was not affected, and your fund are safe.

— Poloniex Exchange (@Poloniex) 7 de enero de 2019

Kraken han detenido las transacciones hasta nuevo aviso, aquí podemos consultar el estado y las noticias.

OKEx, casa de cambio china, aseguran que sus clientes no se ven afectados y mantienen el depósito y retirada de ETC habilitado. Para el depósito de ETC será necesario un mínimo de 100 confirmaciones, y para la retirada serán necesarias 400. Además continúan monitorizando la situación por si hubiera que tomar otro tipo de medidas.

Binance y Bitfly también han aumentado el número de confirmaciones.

Gate.io confirmó que el doble gasto afectó a sus fondos, la plataforma detectó 7 transacciones relativas al ataque. El atacante transfirió un total de 54.200 ETC a través de 4 direcciones. La casa de cambio bloqueó el ataque al poco de producirse pero generó una pérdida total de 40.000 ETC para la plataforma, unos 199.600 dólares.

El ataque de 51% a Ethereum Classic sigue en desarrollo y sus representantes no han brindado mayores detalles desde el pasado lunes. Por esta razón, es posible que otras casas de cambio tomen medidas o reporten pérdidas de fondos en ETC.

Más información
Definición de blockchain
Blog coinbase

Fuentes
https://www.criptonoticias.com/seguridad/casas-cambio-toman-medidas-ataque-51-porciento-ethereum-classic/
https://bitcoin.es/actualidad/los-hackers-de-ethereum-classic-roban-1-5-millones-con-un-ataque-51/
https://criptoinforme.com/los-desarrolladores-de-ethereum-classic-etc-niegan-un-ataque-del-51/

La NSA lanzará su herramienta de ingeniería inversa GHIDRA

La Agencia de Seguridad Nacional de los Estados Unidos (NSA) planea lanzar gratuitamente su herramienta de ingeniería inversa (de aquí en adelante reversing) desarrollada internamente en la próxima conferencia de seguridad RSA 2019, que tendrá lugar en San Francisco durante el mes de marzo.

La existencia de este software fue revelada públicamente por primera vez en las filtraciones de la CIA Vault 7, pero ha pasado desapercibida hasta que Robert Joyce anunció su lanzamiento público en su descripción de la sesión de la conferencia RSA.

¿Qué es GHIDRA?

GHIDRA es un marco de trabajo de reversing desarrollado por NSA y utilizado por la misma durante más de una década.

La herramienta está escrita en Java y desde que salió a la luz se han hecho numerosas comparaciones con el conocido software IDA. Incluso hay varios hilos de Reddit como este en el que aparecen ex-empleados de la agencia que dan su opinión junto con algunos detalles del funcionamiento del programa.

¿Va a ser de código abierto?

Se está hablando mucho de la posibilidad de que la herramienta sea de código abierto. De ser así, el mantenimiento y mejora de la misma sería más cómodo, pero la NSA no suele ser partidaria de compartir su conocimiento (como bien sabemos…).

día de hoy no hay comunicado oficial de si será publicado el código o no, pero nos mantendremos a la espera para comprobar que ocurre el día 5 de marzo y si veremos el código publicado en el Github de la NSA.

Más información:

Enlace a Vault 7:
https://wikileaks.org/ciav7p1/cms/page_9536070.htm

Enlace a descripción de Robert Joyce:
https://www.rsaconference.com/events/us19/agenda/sessions/16608-come-get-your-free-nsa-reverse-engineering-tool

Adobe parchea dos vulnerabilidades graves en Acrobat y Reader

Los investigadores de Trend Micro’s Zero Day Initiative Abdul-Aziz Hariri y Sebastian Apelt, han reportado a Adobe dos importantes vulnerabilidades en Adobe Acrobat y Adobe Readerpara Windows y MacOS que permiten el compromiso total del sistema con tan solo abrir un fichero PDF.

adobe-bug-exploits-vulnerability

Adobe no hay dado de momento más detalles acerca de las vulnerabilidades a pesar de estar clasificadas con criticidad alta, ya que se permite la escalada de privilegios y la ejecución arbitraria de código.

La primera vulnerabilidad, reportada por Apelt, es un use-after-free que puede conducir a la ejecución remota de código. Ésta tiene el identificador CVE-2018-16011.

La segunda falla, descubierta por Hariri y con identificador CVE-2018-19725, permite la escalada de privilegios

Las versiones afectadas son Acrobat and Reader DC 2015 version 2015.006.30461 y anteriores, 2017 version 2017.011.30110 y anteriores, versión Continuous 2019.010.20064 y anteriores, tanto para Mac como para Windows.

 

Más información:

https://thehackernews.com/2019/01/adobe-reader-vulnerabilities.html

https://helpx.adobe.com/security/products/acrobat/apsb19-02.html

¿Podría WhatsApp estar exponiendo tus mensajes?

Saltan las alarmas cuando leemos que una empresa puede estar tratando nuestros datos de manera irregular, y como no, WhatsApp siempre está en el punto de mira.

Las muchas noticias sobre fallos en Whatsapp y Facebook (su comprador) han conseguido generar desconfianza en la aplicación, tal es así que muchos de vosotros habéis optado por aplicaciones de mensajería alternativas.


WhatsApp no parece tener un error que exponga los mensajes de sus usuarios, simplemente, así es como fnciona el servicio.


Todo el revuelo sobre la exposición de mensajes empezó a raíz del siguiente tweet:

logged into whatsapp with a new phone number today and the message history from the previous number’s owner was right there?! this doesn’t seem right.

— Abby Fuller (@abbyfuller) 11 de enero de 2019

A partir de aquí se empezó a sugerir que la conocida aplicación de mensajería podría tener un error de privacidad enorme y podría estar exponiendo, bajo ciertas circunstancias, algunos de nuestros mensajes a otros usuarios.

Si leemos el Tweet de Abby Fuller comenta que, cuando instaló WhatsApp en su nuevo teléfono, con su nuevo número, encontró lo que sería el historial de mensajes del propietario anterior del mismo número.

Ya que para WhatsApp nuestro número de teléfono es nuestro nombre de usuario y la contraseña es la OTP (One-Time Password o contraseña de un solo uso) que envían a ese mismo número, no es una vulnerabilidad, así es como funciona el servicio.

WhatsApp mencionó en su blog que “common practice for mobile providers to recycle numbers, you should expect that your former number will be reassigned”


“Es una práctica común que los proveedores de servicios móviles reciclen números, es de esperar que su anterior número sea reasignado.”


En sus tweets, Fuller dijo que el historial de mensajes “no era completo, pero eran conversaciones reales” Queda por confirmar si esos mensajes incluían algún mensaje enviado por el anterior propietario del número.

A pesar de todo, la configuración de WhatsApp en un nuevo dispositivio con un número de teléfono nuevo no permite restaurar el archivo de mensajes del propietario anterior porque la empresa nunca realiza copias de seguridad de las conversaciones cifradas en sus servidores, actualmente las copias de seguridad de WhatsApp son almacenadas en nuestro Google Drive o localmente en el dispositivo.

Sin embargo, la empresa de mensajería mantiene los mensajes pendientes 45 días en su servidor hasta que el destinatario está en línea y los puede entregar. Después de esos 45 días los mensajes son eliminados.

Esto sugiere que los mensajes que Fuller encontró en su nueva cuenta de WhatsApp fueron, probablemente, mensajes no entregados que enviaron los contactos del antiguo propietario antes de que éste dejara de usar el número.

Para evitar que sus mensajes anteriores lleguen a otros dispositivos, WhatsApp recomienda a los usuarios eliminar su cuenta antes de dejar de usar unatarjeta SIM o cambiar de cuenta con la función “cambiar de número” que está disponible en la configuración de la APP.

Esto es lo que podría haber pasado

Algunos usuarios de sitios web como Reddit o Twitter sugieren que el mecanismo de eliminación de mensajes tras los 45 días en los servidores de WhatsApp contiene un error que, eventualmente, mantiene los mensaje sin entregar almacenados en el servidor de la compañía durante más tiempo. Pero todavía queda un detalle importante por mencionar, El antiguo usuario del número no necesitaba su tarjeta SIM para seguir usando su cuenta de WhatsApp, una vez que esté configurada en el teléfono. Eso significa que es probable que el antiguo propietario del número aún estuviera usando su cuenta después de deshacerse de su SIM hasta que Fuller configuró el mismo número y verificó la cuenta usando el OPT recibido.

Fuentes

https://faq.whatsapp.com/en/s40/28030001/
https://thehackernews.com/2019/01/whatsapp-privacy-chats.html

Vulnerabilidades en SCP permiten escritura de ficheros arbitrarios en el cliente

scp

La vulnerabilidad principal, que data de hace 35 años, afecta a OpenSSH SCP, PuTTY PSCP y WinSCP. El fallo permite alservidor escribir ficheros en el cliente sin que se dé cuenta.

SCP es una herramienta para transferir ficheros a través de SSH empleada por administradores de todo el mundo, y que cuenta con múltiples implementaciones para diferentes sistemas, como OpenSSH, PuTTY o WinSCP. El fallo descubierto, permitiría a un servidor malicioso copiar ficheros no solicitados en el equipo del cliente sin informarse de ello.

Un posible caso de explotación, tal y como detalla sintonen.fi, sería un ataque MitM (Man in the Middle) entre un administrador y un servidor que administre, para que al utilizar scp se copie a su máquina un fichero ‘.bash_aliases’ en su directorio de usuario que permita al atacante ejecutar cualquier comando en la máquina del sysadmin. Este tipo de ataque requiere que la víctima acepte el cambio de fingerprint en el servidor.

El problema principal, que se encuentra desde 1983 (hace 35 años), tiene como origen el protocolo RCP del proyecto BSD, que es en el que se basa SCP. Debido al error la mayoría de clientes SCP no validan correctamente que los ficheros devueltos por el servidor son aquellos que se solicitó. Las vulnerabilidades en concreto son:

  • CWE-20 (CVE-2018-20685):  validación incorrecta del nombre de directorio. El servidor puede cambiar permisos de la carpeta utilizando un nombre de carpeta vacío (“D0777 0 \n”) o con punto (“D0777 0 .\n”).
  • CWE-20 (CVE-2019-6111 y CVE-2018-20684 en WinSCP): debido al estándar derivado de rcp de 1983, es el servidor el que establece los ficheros que se copian al cliente sin que se valide. Si se utiliza el parámetro “-r”, también pueden copiarse carpetas sin validación.
  • CWE-451 (CVE-2019-6109): spoofing en el cliente utilizando el nombre del objeto. Mediante dicho nombre, pueden escribirse caracteres ANSI que modifiquen la salida, para por ejemplo ocultar archivos transferidos.
  • CWE-451 (CVE-2019-6110): spoofing en el cliente utilizando stderr. Similar al anterior, pero aprovechando que el servidor puede escribir una salida de error en el cliente.

Algunos de los clientes afectados son OpenSSH scp (versiones anteriores a 7.9), PuTTY PSCP (todavía sin parche), y WinSCP scp (hasta la versión 5.13). Una posible solución si el cliente lo permite (como OpenSSH) es cambiar el protocolo a SFTP, aunque los servidores utilizados deben de soportar dicho protocolo. Otros clientes o programas que empleen SCP pueden encontrarse afectados.

Fuente:

scp client multiple vulnerabilities:
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt