Una familia se muda a la casa de sus sueños, solo para verse plagada de cartas siniestras, un inquilino extraño y amenazas siniestras. ¿Suena familiar?

Debería. Esta es la historia detrás El Vigía, una serie de crímenes reales que se estrenó en Netflix el 13 de octubre de 2022. También es la historia de la vulnerabilidad Text4Shell, que se anunció ese mismo día, provocando en muchas personas en todo el mundo el horror de que atacantes desconocidos accedieran a sus entornos privados y amenazaran sus aplicaciones. .

Text4Shell es una vulnerabilidad de ejecución remota de código (RCE) que permite a los atacantes acceder de forma remota a un servidor y ejecutar código malicioso en él. Los ataques RCE se han vuelto muy populares últimamente, con vulnerabilidades como Log4Shell y WannaCry, debido al crecimiento de las aplicaciones en la nube que exponen las API (REST, GraphQL, LDAP, etc.) en entornos públicos.

Estos ataques son fáciles de intentar para los piratas informáticos. Todo lo que tienen que hacer es escanear Internet en busca de aplicaciones que ejecuten una pila de tecnología vulnerable conocida y buscar el punto final externo correcto que les permita inyectar su código malicioso.

¿Cómo funciona Text4Shell?

La biblioteca Apache Common Text es una biblioteca Java ampliamente utilizada para la manipulación de texto y otros algoritmos de cadenas. Es una dependencia común en la cadena de suministro para muchas bibliotecas OSS, y también es utilizada directamente por muchas aplicaciones Java.

Una de las funciones de la biblioteca, para crear interpoladores para sustituir variables de una cadena, tiene una lógica defectuosa ya que ejecuta parte de una cadena dada sin usar aislamiento. Esta supervisión hace que la cadena sea accesible para todo el entorno. En palabras prácticas, si tiene una API REST con un parámetro de solicitud como 'https://your.app/user/{userID}', manipularía esta variable 'userID', con la función 'createInterpolation(userID)' .

En el caso de una API pública, cualquier atacante puede reemplazar el parámetro 'userID' con código malicioso y hacer que lo ejecute en su entorno. El peor de los casos de un ataque de este tipo es tomar el control remoto de shell de su entorno (es por eso que esta clase de vulnerabilidades se denominan *4Shell).

Para futuras lecturas, este Publicación de redes de Palo Alto tiene un ejemplo de código práctico que puede ejecutar localmente y ver esta falla en acción.

¿Podemos prevenir proactivamente las RCE?

Si bien no hay forma de que las empresas prometan que nunca serán pirateadas, la aplicación de la metodología proactiva DevSecOps en organizaciones de desarrollo progresivo puede ahorrarle mucho dolor en futuros RCE y ataques * 4Shell.

Los enfoques progresivos de DevSecOps hacen un esfuerzo concertado para evaluar todos los riesgos potenciales en todo el ciclo de vida del desarrollo de software, desde la cadena de suministro de su aplicación hasta el tiempo de ejecución en producción. Sin embargo, no se detiene ahí. La parte más crítica es entonces hacer posible crear fácilmente canalizaciones automatizadas continuas para detectar, estimar y remediar dichas vulnerabilidades de seguridad.

La siguiente lista de mejores prácticas lo guiará paso a paso en la creación de organizaciones de ingeniería de autodefensa, que mantienen la seguridad de manera autónoma en función de la experiencia en el dominio de seguridad disponible para defenderse contra los vectores de piratería conocidos.

1. Ejecute continuamente las herramientas SCA en su base de código

Las herramientas de análisis de composición de software han estado disponibles durante muchos años, con innumerables herramientas gratuitas y comerciales que aprovechan las fuentes en línea para detectar versiones vulnerables de bibliotecas y herramientas utilizadas en el software. Múltiples herramientas difieren en su nivel de inspección y la calidad y cobertura de su base de datos de vulnerabilidad. Para Java, puede usar herramientas de código abierto como Verificación de dependencia de OWASP (o herramientas comerciales como Snyk y Mend). Independientemente de cuál elija, debe encontrar la herramienta SCA disponible para su pila tecnológica y ejecutarla regularmente. Algo de defensa es mejor que ninguna defensa.

Al ejecutar esas herramientas periódicamente en la base de código, puede detectar cualquier versión vulnerable de herramientas y bibliotecas que esté utilizando en su cadena de suministro, justo a tiempo. Recomendamos ejecutarlo al menos una vez al día, al mismo tiempo que se monitorea continuamente el nuevo código que se envía en busca de actualizaciones que puedan incluir versiones vulnerables.

Otro punto es garantizar una estrategia bien definida para actualizar versiones de bibliotecas y herramientas de terceros vulnerables. Puede obtener ayuda a través de API como https://osv.dev, que recopila datos sobre vulnerabilidades y las versiones en las que se resuelven, y también crea procesos automatizados que comprometen la versión corregida, como Dependabot o la función de corrección automática de jit.io.

2. Usa herramientas SAST

Las vulnerabilidades encontradas en bibliotecas de terceros no siempre deben recibir la prioridad más alta para la corrección. En el ejemplo de Text4Shell, si no usa la función 'createInterpolator()' en el código, realmente no hay razón para priorizar la actualización, ya que no es posible explotar la vulnerabilidad en la práctica. (Este hilo de Twitter por Simon Bennetts, creador de OWASP ZAP, puede enseñar mucho sobre priorizar el riesgo real basado en el ejemplo de Log4Shell que todavía tiene a muchos enloquecidos).

Entonces, ¿cómo puede saber si esto se está utilizando en alguna parte de su código? Al ejecutar herramientas SAST. Las herramientas de prueba de seguridad de análisis estático (SAST), como su nombre lo sugiere, escanean estáticamente su código con herramientas como Abstract Source Tree (AST) u otros métodos de escaneo de cadenas para encontrar si hay lugares en el código que son vulnerables. a problemas conocidos. Las versiones actualizadas de tales herramientas detectarán el código vulnerable y lo alertarán. Algunas de las herramientas incluso ofrecerán una solución práctica para las vulnerabilidades, por lo que solo deberá reemplazar el código con el parche que sugieren.

Puede encontrar herramientas SAST que son específicas para idiomas como Bandit para Python y GoSec para Golang, pero también hay herramientas multilingües como SonarQube y SemGrep.

También puede definir esas herramientas para que se ejecuten como parte de las canalizaciones de CI/CD automatizadas, de modo que cualquier problema nuevo relevante se detecte a tiempo para evitar su propagación a producción.

3. Evite errores predeterminados

La explosión en la cantidad de ataques RCE mencionados anteriormente es el subproducto de la existencia de API públicas que brindan a los atacantes una manera fácil de explorar la Internet pública en busca de servidores vulnerables. El método típico es crear scripts automatizados que busquen respuestas de error que utilicen mensajes y páginas de error predeterminados, lo que facilita la identificación de la tecnología subyacente. (Por ejemplo, la página predeterminada de Apache Java 404, el servidor web más utilizado, sigue siendo una mina de oro para los posibles atacantes). Al envolver cualquiera de los errores devueltos a los usuarios con un error personalizado, dificulta que atacantes para identificar qué tecnología de servidor usó, por ejemplo.

Además de servir como práctica recomendada para revisiones de código y estilo de código, muchas de las herramientas SAST y lint también brindan el beneficio adicional de monitorear cada árbol estático de solicitud HTTP y alertar sobre cualquier error sin procesar que se devuelve al usuario final.

4. Configurar todo como código

Al configurar todo como código, toda la configuración se protocoliza, monitorea y administra de una manera confiable y con capacidad de búsqueda que hace que los cambios y reversiones sean rápidos y silenciosos. No solo eso, puede usar herramientas automatizadas como KICS y Checkov para escanear los archivos de configuración en busca de configuraciones vulnerables incluso antes de implementarlo en un entorno real. Al ejecutar estas herramientas, puede verificar problemas de configuración críticos como:

• Contenedores excesivamente privilegiados, para garantizar que el contenedor solo pueda ejecutar el código particular que debería y también verificar el conjunto de permisos más limitado (también llamado privilegio mínimo).
• Configuraciones de API y acceso a puntos finales, para garantizar que todas las solicitudes se validen para cualquier posible inyección de código.
• Escaneo de ejecutores de código para garantizar que los contenedores no tengan acceso de llamada de salida a una lista blanca de direcciones.

Al igual que otras herramientas de análisis estático, esas herramientas facilitan la creación de canalizaciones de CI/CD automatizadas que garantizan que cada configuración implementada sea la más segura, que los cambios se controlen y que el factor de error humano se minimice lo más cerca posible de cero.

5. No ejecute código en máquinas nativas y use privilegios mínimos

El mayor daño que pueden causar las vulnerabilidades de *4Shell es cuando ejecuta estos procesos como procesos estándar en una máquina (virtual). La ejecución de código en contenedores minimiza el daño al entorno de ejecución actual y le permite mantener un conjunto muy limitado de permisos y privilegios para el contenedor.

Al monitorear los contenedores para que se ejecuten solo en los procesos necesarios, además de limitar a los usuarios que ejecutan las aplicaciones solo a los permisos requeridos, puede asegurarse de que no habrá ningún impacto en las áreas sensibles en las que los atacantes querrán infiltrarse.

Ejecutar todas sus aplicaciones en contenedores y otros métodos estándar nativos de la nube también ayuda a definir una red centralizada y una configuración de privilegios que envuelve todas las aplicaciones en ejecución, evitando cualquier configuración manual que pueda fallar fácilmente.

Cuando su arquitectura escala, puede usar herramientas como Wiz, Orca y otras herramientas de observabilidad de seguridad nativas de la nube para asegurarse de que todo esté definido correctamente en tiempo real.

6. Emplear escaneo dinámico de API

Usando herramientas DAST como ZAP, puede averiguar cuáles de sus aplicaciones son realmente vulnerables a Text4Shell. Esto puede ser útil si tiene una gran cantidad de aplicaciones que son vulnerables, lo que permite priorizar su reparación, o si necesita acceder al código fuente. El ZAP Regla de exploración de Text4Shell se encuentra actualmente en el Alfa opcional Complemento de reglas de exploración activa y requiere un servicio OAST para que funcione.

Seguridad más rápida == Velocidad de desarrollo

No podemos esperar que los exploits desaparezcan, y no debería sorprendernos cuando aparezcan nuevos *4Shell o cualquier otro día cero. Lo que podemos hacer es tener las medidas de protección y los controles correctos, de modo que podamos descubrirlos y remediarlos rápidamente sin causar demasiados estragos en nuestros procesos de desarrollo ya atascados.

Al tomar medidas hoy, esencialmente evita que lo tomen con la guardia baja mañana y que interrumpa la entrega de ingeniería. Tenemos el privilegio de estar en una época con excelentes herramientas de seguridad de código abierto que se integran bien con nuestras pilas y CI/CD, y debemos esforzarnos por emplearlas con la mayor frecuencia posible. Además, esto ya ni siquiera requiere experiencia en el dominio; hay muchas herramientas DevSecOps (y, como se indicó anteriormente, herramientas de código abierto) que harán esto por usted, e incluso ofertas basadas en SaaS para aquellos que estén dispuestos a pagar por ellas que orquestarán esto de principio a fin. No dejes tu casa abierta a extraños. Comience con las cosas fáciles: cierre la puerta principal.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.Haga clic aquí
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.darkreading.com/dr-tech/how-development-teams-should-respond-to-text4shell