Investigador piratea Microsoft, Apple y más en una cadena de suministro novedosa


Un investigador logró piratear sistemas de más de 35 importantes empresas tecnológicas, incluidas Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, Tesla y Uber en un novedoso ataque a la cadena de suministro de software. Por sus esfuerzos de investigación de piratería ética, el investigador ha recibido más de 130.000 dólares en recompensas por errores.

Un investigador logró violar los sistemas internos de más de 35 empresas importantes, incluidos Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Teslay Uber, en un novedoso ataque a la cadena de suministro de software.

El ataque consistió en cargar malware en repositorios de código abierto, incluidos PyPI, npm y RubyGems, que luego se distribuyeron automáticamente en las aplicaciones internas de la empresa.

Los ataques tradicionales de typosquatting que se basan en tácticas de ingeniería social o que la víctima escribe mal el nombre de un paquete, este ataque de cadena de suministro en particular es más sofisticado ya que no necesitó ninguna acción por parte de la víctima, que automáticamente recibió los paquetes maliciosos.

Esto se debe a que el ataque aprovechó una falla de diseño única de los ecosistemas de código abierto llamada confusión de dependencia.

Por sus esfuerzos de investigación ética, el investigador ha ganado más de 130.000 dólares en recompensas por errores.

El malware se distribuye en sentido descendente automáticamente

El año pasado, el investigador de seguridad Alex Birsan se le ocurrió una idea cuando trabajaba con otro investigador, Justin Gardner.

Gardner había compartido con Birsan un archivo de manifiesto, package.json, de un paquete npm utilizado internamente por PayPal.

Dependencias públicas y privadas (creadas internamente) para un paquete de PayPal

Birsan notó que algunos de los paquetes de archivos de manifiesto no estaban presentes en el repositorio público de npm, sino que eran paquetes npm creados de forma privada por PayPal, utilizados y almacenados internamente por la empresa.

Al ver esto, el investigador se preguntó, ¿debería existir un paquete con el mismo nombre en el repositorio público de npm, además de un repositorio privado de NodeJS, cuál tendría prioridad?

Para probar esta hipótesis, Birsan comenzó a buscar nombres de paquetes internos privados que pudiera encontrar en archivos de manifiesto en repositorios de GitHub o en CDN de empresas destacadas, pero que no existían en un repositorio público de código abierto.

Luego, el investigador comenzó a crear proyectos falsificados con los mismos nombres en repositorios de código abierto como npm, PyPI y RubyGems.

Cada paquete publicado por Birsan se hizo bajo su cuenta real y claramente tenía un descargo de responsabilidad en su lugar, que decía “Este paquete está destinado a fines de investigación de seguridad y no contiene ningún código útil”.

Paquetes publicados con divulgación de investigación de seguridad

Birsan pronto se dio cuenta de que si un paquete de dependencia utilizado por una aplicación existiera tanto en un repositorio público de código abierto como en su compilación privada, el paquete público tendría prioridad y se eliminaría en su lugar, sin necesidad de ninguna acción por parte del desarrollador.

En algunos casos, como con los paquetes PyPI, el investigador notó que se priorizaría el paquete con la versión superior independientemente de dónde se ubicara.

Usando esta técnica, Birsan ejecutó un exitoso ataque a la cadena de suministro contra Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp y Uber simplemente publicando paquetes públicos con el mismo nombre que los internos de la empresa.

“Creo que la confusión de dependencia es bastante diferente de la errata o el robo de marca, ya que no necesariamente requiere ningún tipo de entrada manual de la víctima”.

“Más bien, las vulnerabilidades o fallas de diseño en las herramientas de instalación o construcción automatizadas pueden hacer que las dependencias públicas se confundan con dependencias internas con el mismo nombre exacto”, dijo Birsan a BleepingComputer en una entrevista por correo electrónico.

Reconocimiento y exfiltración de datos sobre DNS

Los paquetes tenían scripts de preinstalación que lanzaban automáticamente un script para filtrar la información de identificación de la máquina tan pronto como el proceso de compilación extraía los paquetes.

Sabiendo que sus scripts harían conexiones desde redes corporativas, Birsan decidió usar DNS para exfiltrar los datos y evitar la detección.

“Sabiendo que la mayoría de los posibles objetivos estarían en el interior de redes corporativas bien protegidas, consideré que la exfiltración de DNS era el camino a seguir”, dice Birsan en su publicación de blog.

DNS utilizado para reconocimiento y exfiltración de datos

Un fragmento del código que se muestra a continuación es del paquete npm en cuclillas “analytics-paypal” que ahora se eliminó de npm. Sin embargo, como investigador de seguridad en Sonatype, pude recuperarlo de nuestros archivos de detección de malware automatizados.

Este script se iniciaría automáticamente tan pronto como se extrajera la dependencia “analytics-paypal” y tuviera un código para realizar solicitudes de DNS a dns.alexbirsan-hacks-paypal.com.

La devolución de llamada recibida de los sistemas de PayPal habría alertado al investigador de que la IP que realizaba la solicitud pertenecía a PayPal, junto con el nombre de usuario y el directorio de inicio del sistema infectado.

Los paquetes de PoC extrajeron datos

Al recibir tales devoluciones de llamada y verificar suficientemente que el componente falsificado del investigador se había infiltrado con éxito en la red corporativa, Birsan informaría sus hallazgos a la empresa correspondiente y obtendría una recompensa por errores.

Ganó más de $ 130,000 en recompensas

En general, el investigador logró ganar más de $ 130,000 en recompensas a través de programas de recompensas por errores y acuerdos de pruebas de penetración aprobados previamente.

“Creo que es importante dejar en claro que todas las organizaciones seleccionadas durante esta investigación han otorgado permiso para que se pruebe su seguridad, ya sea a través de programas públicos de recompensas de errores o mediante acuerdos privados. No intente este tipo de prueba sin autorización, “advierte Birsan.

Por la divulgación de Birsan, Microsoft le otorgó la cantidad más alta de recompensa por errores de $ 40,000 y publicó un documento técnico sobre este problema de seguridad. Identifican este problema como CVE-2021-24105 para su producto Azure Artifactory.

Sin embargo, Microsoft le dijo a Birsan en un correo electrónico que consideran que esto es un defecto de diseño en los administradores de paquetes.

“Si bien tratamos esto como un problema de seguridad grave, en última instancia debe solucionarse reconfigurando las herramientas de instalación y los flujos de trabajo, y no corrigiendo nada en los repositorios de paquetes”.

“Para solucionar este problema, Microsoft ha realizado pequeñas mejoras en Azure Artifacts para garantizar que se pueda utilizar como una solución alternativa confiable”.

“Dicho esto, consideramos que la causa raíz de este problema es una falla de diseño (en lugar de un error) en los administradores de paquetes que solo se puede solucionar mediante la reconfiguración”, dijo un portavoz de Microsoft en el correo electrónico.

En una declaración a BleepingComputer, Yelp confirmó el informe del investigador y lo recompensó después de solucionar el problema en un día.

“A través del programa de recompensas por errores de Yelp, Alex Birsan nos ayudó a identificar una vulnerabilidad, que inmediatamente reparamos en un día”.

“Estamos comprometidos a trabajar con expertos en seguridad para mantenernos actualizados con las últimas técnicas de seguridad y confiamos en nuestro programa de recompensas por errores para recompensar a los investigadores de seguridad capacitados que ayudan a mejorar los sistemas y servicios de Yelp”, dijo un portavoz de Yelp a BleepingComputer.

Apple le ha dicho a BleepingComputer que Birsan recibirá una recompensa a través del programa Apple Security Bounty por revelar responsablemente este problema.

Considerando que, PayPal ahora ha revelado públicamente el informe HackerOne de Birsan que menciona el monto de la recompensa de $ 30,000.

Sin embargo, los esfuerzos de investigación ética del investigador no han sido aceptados por todos.

“Pienso esto [is] probablemente razón suficiente para no tener estos proyectos en PyPI “, argumentó Dustin Ingram, Directory of Python Software Foundation y un defensor de los desarrolladores de Google, quien investigó y eliminó algunos de los paquetes de Birsan de PyPI.

Después de pasar una hora eliminando estos paquetes, Ingram enfatizó que cargar paquetes ilícitos en PyPI supone una carga indebida para los voluntarios que mantienen PyPI.

“En última instancia, si está interesado en proteger a los usuarios de este tipo de ataque, hay mejores formas de hacerlo que protegen todo el ecosistema, no solo un conjunto específico de organizaciones con recompensas de errores”, agregó Ingram, habiendo tratado con estos paquetes por aproximadamente una hora.

Se espera que los ataques crezcan, un problema difícil de solucionar

A través de esta investigación que abarca las principales organizaciones, Birsan dice que ya ha informado a las empresas de tecnología más importantes de este tipo de ataque que ahora han implementado algún tipo de mitigación en su infraestructura. Sin embargo, el investigador cree que hay más por descubrir.

Queda la posibilidad de que tales ataques resurjan y crezcan, especialmente en plataformas de código abierto sin una solución fácil para la confusión de dependencias.

“Específicamente, creo que encontrar formas nuevas e inteligentes de filtrar nombres de paquetes internos expondrá sistemas aún más vulnerables, y buscar lenguajes de programación alternativos y repositorios para apuntar revelará alguna superficie de ataque adicional para errores de confusión de dependencia”, concluyó el investigador en su entrada en el blog.

Sonatype ha lanzado un script en GitHub que los usuarios de Nexus Repository Manager pueden ejecutar para verificar si alguna de sus dependencias privadas lleva el nombre de los paquetes existentes presentes en los repositorios públicos de npm, RubyGems y PyPI. Las empresas de otros administradores de repositorios de artefactos pueden adoptar implementaciones idénticas.

BleepingComputer se ha puesto en contacto con las empresas mencionadas en este informe con mucha antelación, incluidas Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, Teslay Uber. Hemos publicado las declaraciones de las empresas que respondieron antes del cierre de esta edición.

.



Source link