😎 60% Descuento:  Curso de Hacking Redes Inalámbricas >> Ver Más

Investigador hackeó reconocidas empresas tecnológicas en un ataque a la cadena de suministro

Un investigador logró vulnerar los sistemas internos de más de 35 importantes empresas, incluidas Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla y Uber. Esto ocurrió en un novedoso ataque a la cadena de suministro de software.

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

Este ataque se diferenció de los ataques tradicionales de typosquatting que se basan en tácticas de ingeniería social o en 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. Es decir, esta recibió automáticamente 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 dependency confusión (confusión de dependencia).

Por sus esfuerzos de investigación ética, el investigador ganó más de 130,000 dólares en recompensas por errores.

El malware se distribuía automáticamente

El año pasado, al 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, al investigador le surgieron algunas dudas. ¿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. Él los buscó en repositorios de GitHub o en CDN de empresas conocidas, 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. Este decía “Este paquete está destinado a fines de investigación de seguridad y no contiene ningún código útil”.

Paquetes

Birsan pronto se dio cuenta de algo peculiar. 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 había “problemas”. 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. Él logró su objetivo simplemente publicando paquetes públicos con el mismo nombre que los internos de la compañía.

“Creo que la confusión de dependencia es bastante diferente del typosquatting o el brandjacking. Esto 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 compilación automatizadas generan el problema. Estas pueden hacer que las dependencias públicas se confundan con dependencias internas con el mismo nombre exacto”, dijo Birsan en una entrevista por correo electrónico.

Reconocimiento y exfiltración de datos sobre DNS

Los paquetes tenían   scripts de preinstalación que iniciaban automáticamente un script. Esto 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, tomé una decisión. Consideré que la exfiltración de DNS era el camino a seguir”.

DNS utilizado para reconocimiento y exfiltración de datos

Un fragmento del código que se muestra a continuación es del paquete npm alterado “analytics-paypal” que ya fue eliminado de npm. Sin embargo, se ha podido recuperar de los 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 respuesta recibida de los sistemas de PayPal habría alertado al investigador de que la IP que realizaba la solicitud pertenecía a PayPal. Esto junto con el nombre de usuario y el directorio de inicio del sistema infectado.

Al recibir tales respuestas y verificar suficientemente que el componente falsificado del investigador se había infiltrado con éxito en la red corporativa. Birsan informó sus hallazgos a la empresa correspondiente y obtuvo 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. También por acuerdos de pruebas de penetración aprobados previamente.

“Creo que es importante dejar en claro que todas las organizaciones seleccionadas durante esta investigación otorgaron permiso para probar su seguridad. Lo hice 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. Además, publicó un documento técnico sobre este problema de seguridad. La empresa identificó la vulnerabilidad 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 una vulnerabilidad de diseño en los administradores de paquetes.

Yelp también confirmó el informe del investigador y lo recompensó después de solucionar el problema en un día.

Apple también ha dicho que Birsan recibirá una recompensa a través del programa Apple Security Bounty por revelar responsablemente esta vulnerabilidad

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

Un problema difícil de solucionar 

A través de esta investigación, Birsan dice que ya ha informado a las empresas de tecnología más importantes de este tipo de ataque. Ahora, las empresas 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. 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.

Sonatype ha lanzado un  script  en GitHub que los usuarios de Nexus Repository Manager pueden utilizar. El script sirve 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 pueden adoptar implementaciones idénticas.

Cómo hemos visto Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla y Uber han reconocido la vulnerabilidad y la han parcheado.

Deja un comentario

Adquiere tu Membresía Anual Wiser

Adquiere tu Membresía Anual Wiser y adquiere grandes beneficios

Más información