Nueva forma de concebir la seguridad en las dependencias

Hola a todos, buenos días, buenas tardes, buenas noches, dondequiera que estén. Hoy voy a hablar sobre una nueva forma de concebir los problemas de security|seguridad y dependencias. Estoy seguro de que algunos de ustedes lo conocen, otros no lo conocen. Así que hoy compartiré mi experiencia y comprensión sobre esos problemas.

Mi nombre es Vandana Verma Sahgal, y en cuanto a mí, en cuanto a mi experiencia, actualmente soy líder de relaciones de security|seguridad en Snyk, que es una empresa de security|seguridad de software. Cuando no estoy trabajando en Snyk, generalmente contribuyo a proyectos de código abierto en ciber security|seguridad y formo parte de ciertas conferencias como BlackHat. Actualmente soy la presidenta de OWASP, que es el Proyecto de Aplicaciones Web de Security|Seguridad Abierta, una comunidad impulsada para motivar a las personas a comprender la security|seguridad de las aplicaciones. También dirijo InfoSec Girls, InfoSec Diversity and Kids, para que todos puedan comprender la ciberseguridad. Eso es sobre mí.

Ahora, mientras hablo sobre qué son los problemas de security|seguridad, ¿qué ves exactamente en esta imagen? Esto es algo más bien una imagen futurista de lo que realmente queremos. Queremos que todo sea automatizado. Queremos que todo sea súper genial. Queremos que todo sea diferente y útil para nosotros. Yo lo quiero. Quiero que las smart TVs, los dispositivos inteligentes, los usuarios inteligentes, todo sea inteligente en casa. Así que solo necesito presionar un botón y todo está bien. Pero hay una cosa que está ahí. ¿Qué sucede cuando los data|datos se están cargando en algún lugar? Y eso es natural. Hemos escuchado e incluso hemos visto que los data|datos se están cargando en algún lugar. ¿Por qué decimos eso? Porque el punto es que todo lo que le hablas a estos dispositivos inteligentes realmente se entrena. Porque quieres que todo sea lo más rápido posible. Se están entrenando para entregar el contenido lo más rápido posible. Entonces, los data|datos se están almacenando en algún lugar. Ahora, estoy seguro de que estos dispositivos se están actualizando en algún lugar. Entonces, habrá un parche que se descargará. Ahora, cuando se descarga ese parche, a veces puedes sentir que algo sospechoso está sucediendo. O a veces ni siquiera te das cuenta de que hay cosas maliciosas que se descargan en tu sistema. Entonces, ¿qué haces y qué sucede entonces? Es posible que te estén rastreando. Todo lo que dices podría estar siendo rastreado. ¿Es genial? No, no lo es.

Es algo aterrador. Pero surge la pregunta de cómo debemos lidiar realmente con ellos. Entonces, los desarrolladores desempeñan un papel muy, muy crucial en los incidentes de ciberseguridad. Y especialmente cuando hablamos de estos nuevos problemas de cadena de suministro que existen, todo el panorama que está cambiando, y la forma en que hemos comenzado a preocuparnos por la seguridad del software.

Ahora, este incidente de flujo de eventos, que no parece ser nuevo, pero se remonta a muchos, muchos años. Cuando alguien dijo que quería ayudarte y contratar a los mantenedores, pero en cambio agregaron un minero de criptomonedas y nadie siquiera lo sabía. Así que estás trabajando y algo se está ejecutando en segundo plano. Entonces, ¿cuánto sabes exactamente sobre lo que hay en tu sistema?

Ahora, te contaré sobre mí. Todos mis sitios web están en contenido de código abierto. Estoy usando lo que está disponible en Internet. Ahora bien, ¿existen problemas en esas dependencias? Tal vez, esta es la imagen que tengo en mente. Esto es toda mi aplicación. Pero, lo real es que este es el único código, el punto rojo en el medio, que es el código, que es desarrollado por mí o tal vez mis amigos, tal vez la propia empresa. Pero, ¿qué hay del resto? Todo el resto es código de código abierto, dependencias de terceros, bibliotecas de terceros y demás. ¿Cómo te vas a encargar de eso exactamente? ¿Qué sucede cuando las personas comienzan a atacar las herramientas de desarrollo?

Ahora bien, estando en seguridad, es posible que no use Visual Studio Code o cualquier IDE con frecuencia. Pero, ¿puede suceder? Si soy un desarrollador, no lo usaría todos los días. Lo usaría, y en ese sentido, estando en seguridad, quiero aprender muchas cosas nuevas, así que aprendo estas cosas. Eso es lo que sucedió. En enero de 2021, alguien intentó atacar Visual Studio Code y logró acceder a GitHub. De muchas cuentas, pero informaron diligentemente eso. Podría haber tomado un rumbo equivocado. Cuando alguien obtiene la llave de la casa, puede hacer cualquier cosa. Por ejemplo, tienes cuatro puertas en la casa, luego hay cuatro ventanas. Ahora, te vas de vacaciones, has cerrado todas las puertas, pero ¿qué sucedió con las ventanas? Tal vez haya una ventana abierta, que no te diste cuenta y alguien entra a tu casa y se lleva todas las cosas. Es una locura, y eso le puede suceder a cualquiera, y es entonces cuando necesitamos comprender qué hay dentro de nuestro código.

Ahora, hay ciertas lecciones que aprendimos de la violación de Equifax que ocurrió hace unos años. Ahora, ¿por qué seguimos hablando de eso, porque realmente vislumbra un aspecto muy importante, que cuando se informa de una cierta vulnerabilidad, después de eso, lo que realmente necesitamos hacer es comprender de qué se trata la vulnerabilidad. ¿Podemos solucionarlo o no? Y si es crítico, ¿cuánto tiempo tardaremos en abordarlo? ¿Qué sucedió con Equifax? El 14 de febrero, Apache notificó que había ciertos problemas. Hubo una versión de corrección, las personas comenzaron a explotar la vulnerabilidad. Y aunque algunas empresas ya lo actualizaron, hay algunas empresas que no pudieron hacerlo. Una de ellas fue Equifax.

Ahora, fue una gran violación de datos y especialmente preocupante en las bibliotecas. Lo que nos dice es que necesitamos detectar estos problemas lo antes posible. Necesitamos responder a ellos. Y cuando respondemos, debemos hacerlo con toda la organización, dentro de toda la organización. Créeme, nos llevó buenos dos o tres días entender dónde estamos, en qué posición nos encontramos. Todos se volvieron locos. ¿Tenemos esta versión? ¿Usamos Apache en esta aplicación? Y muchas veces, ¿qué sucede? Ni siquiera sabes que estás usando Apache o tal vez esta versión de terceros, que es vulnerable en tu ecosistema. ¿Por qué? Porque a veces tendemos a olvidarnos de actualizar los CMDB.

Ahora, cuando decimos eso, el aspecto más importante es que, ¿somos capaces de mantenerlo regularmente? Tal vez sí, tal vez no. Entonces, ¿qué debemos hacer al respecto? Necesitamos asegurarnos de entender estos problemas y, además, estos riesgos de la cadena de suministro. ¿Son nuevos? No creo que sean nuevos, porque han estado ahí durante mucho, mucho tiempo. Y comenzó a llamar la atención después del ataque de SolarWinds, donde había una biblioteca de terceros que se agregó como parte de nuestro DLL, que se agregó como parte del paquete, que se envió el paquete a todos y todos lo estaban usando.

Ahora, esto es una gran preocupación, lo que significa que hay una biblioteca, una dependencia, que está presente en tu código que puede llevar a grandes problemas. Y además, surge la pregunta, ¿cómo estamos tratando de abordar eso? Seguimos viendo estos problemas cada año. Las empresas, organizaciones están gastando cada vez más dinero en esto.

Ahora, déjame contarte algo muy interesante. Hay momentos en los que los mantenedores, ellos mismos eliminan las bibliotecas. Estos son algunos de los casos en los que alguien eliminó el paquete y todo el paquete comenzó a romperse y todos se volvieron locos. Ahora, esto también hace una cosa importante cuando estamos usando dependencias de terceros para contenido de código abierto, es importante que lo rastreemos y entendamos si algo les sucede, ¿cómo vamos a lidiar con eso? Y no vamos a retroceder mucho, hasta 2016. Hace apenas dos o tres meses, hubo un problema con Collar y Faker. Estas son dos bibliotecas importantes como parte del ecosistema de Node.js. El mantenedor era el mismo para ambas. Ahora, este mantenedor eliminó todo el paquete de una de las bibliotecas para uno de los ecosistemas y para la otra dependencia, la persona agregó una condición de bucle. Ahora, ¿qué haces en ese caso en el que tengo un paquete porque quiero una nueva actualización y ahora tiene una condición de bucle y está rompiendo todo mi código? ¿No da miedo? Y eso nos lleva a que incluso estos problemas pueden presentarse en cualquier forma, en cualquier parte como parte de los registros. Entonces, ¿qué contienen estos registros? Podrían ser problemas maliciosos, podrían ser vulnerabilidades, podrían ser cualquier cosa. Y estos problemas no solo afectan a los ecosistemas más pequeños, sino que también impactan a las empresas. Unidades de negocios medianas y a todos.

Esto nos lleva al punto en el que está este Lock for Shake. Te contaré mi propia historia. En diciembre, estaba de vacaciones en la primera semana. Pensé: `Oh, no he tomado vacaciones desde hace mucho tiempo. Hemos estado en casa, así que vamos a tomar unas vacaciones`. Así que fuimos a viajar. Ahora, durante ese mismo tiempo, ocurrió Lock for Shake. ¿Qué es eso? Ni siquiera lo sabía, pero luego empecé a ver mensajes y todos empezaron a hablar de eso. Así que quería entender qué era. Entonces, Lock for Shake es básicamente una plataforma de registro muy popular. Una plataforma de registro basada en Apache escrita en Java.

Y las personas utilizan estas plataformas muy fácilmente porque son fáciles de usar. Pero, ¿qué sucede cuando impacta a una gran cantidad de organizaciones, desde Cesar hasta Amazon hasta IBM y cualquier empresa, incluso Sneak, de la que estaremos hablando.

Ahora, cuando eso sucede, ¿cómo se maneja eso? ¿Y cuál fue la parte, cuál fue el problema allí? Entonces, cualquiera que estuviera usando un servidor de laboratorio y estuviera usando JNDEI, era vulnerable porque era un marco muy útil o muy utilizado que muchas organizaciones estaban usando. Y estaban tratando de averiguar si eran vulnerables o no.

Ahora, las organizaciones, entonces las personas, todos estaban hablando de ello, compartiendo sus opiniones en las redes sociales, Twitter, LinkedIn en sus propios blogs. Y este ataque completo nos hizo darnos cuenta de que si este pequeño, pequeño problema, que está ahí en el código, puede ser una gran preocupación, incluso si es una biblioteca. Había personas, había organizaciones que en realidad no eran vulnerables, pero estaban usando componentes de terceros que los estaban volviendo vulnerables. ¿Te gustaría eso? A mí no me gustaría eso. Así que me gustaría saber qué tengo y qué no tengo. Lo que tengo, ¿cuál es la lista de eso? ¿Estoy usando proveedores de terceros o no? Lo cual es muy, muy importante.

Además, te contaré algo interesante sobre OWASP. OWASP publica la lista de los 10 principales riesgos cada tres años. Así que presentó la lista de los 10 principales riesgos y la inyección, que se supone que es un 10, bajó al tercer lugar, y de repente vi estos problemas de inyección y se están volviendo cada vez más frecuentes. Esto es Lock4Shell, luego vinieron muchas otras vulnerabilidades y simplemente no se detiene ahí. ¿Por qué? Porque en realidad fue la indicación de que hay fallas en el cumplimiento normativo. Estamos hablando de cloud. Entonces hay fallas en el control de seguridad de cloud. A veces intencionales. A veces ni siquiera nos enteramos. Y estas aplicaciones SaaS de terceros tienen fallas de seguridad porque dependemos demasiado de ellas, lo que también nos lleva a que si algo sucede, cualquiera puede implementar malware y ransomware, lo que puede llevar a la exfiltración de data, a problemas de integridad, a problemas de disponibilidad y mucho más. Yo no querría eso.

Ahora déjame mostrarte algo muy interesante. Así que aquí he creado una demostración. Ahora, lo que dice, lo tengo en mi sistema local. No he instalado esta versión vulnerable de Java en mi sistema, pero está en un sistema, ¿es una carpeta diferente? Ahora, lo que tengo es que he creado un grupo de Java donde tengo esta vulnerabilidad. En la vulnerabilidad, para que lo veas, necesito tener un servidor en ejecución. Si no hay un servidor vulnerable, ¿cómo te atacarían? ¿Cómo obtendrías una vulnerabilidad? Así que tengo un servidor Lock4Shell en ejecución. Ahora, este servidor se está ejecutando en localhost, que es el servidor HTTP 8000. Y hay un servidor LDAP, un servidor Jindi vulnerable, que se está ejecutando en el puerto 9999. Ahora todo esto está en ejecución.

Ahora, necesito un cliente para poder hacerlo vulnerable. Aquí está el cliente. Y simplemente lo que haré es, intentar conectarlo con el servidor. Así que ejecutaré esto en Java. Ahora, cuando me conecto desde el cliente al servidor, hay un archivo que no existe, temporary pawn. Pero cuando lo ejecuté y lo conecté al servidor, en realidad descargó un archivo malicioso y lo hizo vulnerable, veamos si este archivo existe o no. Así que veamos.

Si ves, este archivo existe, ahora debes estar pensando, ¿cómo puede ser eso? Así que haré esto. Eliminaré completamente este archivo. Así que veamos si este archivo existe o no ahora. Oh, lo siento, déjame continuar. Si ves, oh, primero necesito eliminar. Ahora voy a mostrarte si existe o no. Así que no existe. Ahora el archivo no existe. Ahora lo conectaré al servidor vulnerable. Aquí voy a ejecutar Java, y se conectará al servidor. Mientras se está ejecutando, intenta conectarse a ese servidor Djinni, y ahora este archivo existe aquí, que dice que es solo un archivo pequeño que he descargado en una carpeta temporal. Si soy una persona malintencionada, sé que este servidor es vulnerable. Por ejemplo, ahora estamos hablando de la Cumbre de React.js. Estoy seguro de que deben tener un sitio web. Ahora, cuando hay un sitio web y es vulnerable, sé que es vulnerable, lo que haré es conectarme y subir ciertos archivos. Así que cualquier persona que se conecte a ese servidor descargará estos archivos maliciosos. Podría ser un ransomware. Oh, no debería suceder nada porque las personas están más conscientes, especialmente los equipos de desarrollo que están cada vez más conscientes de los problemas de security, al menos más que nosotros. Lo que puedo ver, tengo muchos amigos que trabajan en equipos de desarrollo y son personas pro-security, porque entienden mejor la security que yo porque conocen bien el ecosystem, día tras día.

Ahora, los problemas simples. Me tomó unos segundos explotarlo. ¿Qué sucede cuando un hacker intenta exfiltrar los data, que es muy, muy confidencial y nadie debería saberlo? Eso puede ser aterrador para una organización.

Ahora, lo que nos lleva es que, aunque estos frameworks populares están ahí, hay ciertos problemas que necesitan entenderse. Necesitamos tener una lista de todos estos problemas. Y además de eso, debemos saber qué tenemos en nuestra casa. Así que intentamos hackear la aplicación. Generalmente lo hago después de esto, pero lo hice temprano para establecer el contexto. Y además, lo que solíamos ver es que esta es la vida de un analista de seguridad. Los jueves por la noche, los viernes por la noche, tendrías estos problemas. Bueno, déjame decirte, eso ya no es así. Cuando la tasa de cero cae, afecta a todos, desde un analista de seguridad hasta cualquier persona. Y eso también nos dice que estos problemas de seguridad son reales. Hay muchos, muchos problemas que están ahí como parte del ecosistema de ReactJS, que las personas están tratando de solucionar. Así que lo que realmente pediría a todos es que, si ven algún problema en alguna de las dependencias, por favor informen. Si eres un mantenedor y necesitas ayuda de las personas, por favor pide ayuda. Hay muchas personas que quieren ayudar, pero no saben cómo hacerlo. Hay problemas que van a estar ahí para quedarse. Y cuando hablamos de código abierto, el código abierto está aquí para quedarse, pero usemoslo de manera responsable. Un aspecto importante, según una de las investigaciones, el 70 al 80% e incluso más del código en Internet es código abierto. El resto lo desarrollamos nosotros. Cuando tanto código es de código abierto, se convierte en nuestra responsabilidad asegurarnos de abordar cualquier problema. Cuando mi sitio web está construido completamente en código abierto, ¿puedo decir que todo está bien con él? Tal vez no si no lo he actualizado. Cuando comienzo a usarlo, no significa que todo sea perfecto. Tengo que asegurarme de trabajar para mejorarlo. Y además, al tratar con estas nuevas vulnerabilidades, debemos pensar de manera más amplia, mapeando todo. Y puedes comenzar cualquier día. Si hablamos de código abierto, OWASP Dependency Check es una herramienta gratuita, una herramienta de código abierto. Puedes aprovecharla, puedes escanear tu código y comprender lo que tienes en el código mismo. Hay muchas herramientas de código abierto maravillosas que están ahí para ayudarte. Y cuando te sientas cómodo con estas herramientas, puedes optar por una herramienta comercial según tus necesidades y lo que realmente deseas en una organización. Tengo amigos que compraron las herramientas, pero no las usan porque no les sirven de nada, simplemente las compraron porque todos las estaban usando. Ahora, un aspecto importante es comenzar a obtener esas cosas que realmente se necesitan. Además, tengamos campeones y equipos de seguridad para que entendamos bien la seguridad, aboguemos por la seguridad. Y no nos quedemos solo ahí, sino que capacitemos a las personas, capacitemos a las personas en diferentes áreas, lo que nos ayudará a evitar estos problemas. Estoy seguro de que todos trabajaremos en eso y será un lugar mejor y seguro para vivir. Muchas gracias por escucharme. Fue maravilloso ser parte de Reactors. Gracias.