En profundidad: Conoce de cerca la vulnerabilidad de día cero de MOVEit
Los ciberataques a la cadena de suministro de software son cada vez más frecuentes, lo que ha provocado una oleada de cambios legislativos en el gobierno estadounidense, mientras las empresas se esfuerzan por mitigar su perfil de riesgo expansivo y mejorar rápidamente la calidad del software. Sólo este año se han producido tres vulnerabilidades de día cero relacionadas con servicios de intercambio de archivos, la mayor y más destructiva de las cuales es el exploit masivo MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias de ciberseguridad durante algún tiempo, con más de 1.000 organizaciones afectadas. Se prevé que esta cifra siga creciendo, convirtiéndose en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta brecha generalizada fue un grupo de vulnerabilidades de inyección SQL, que recibió una puntuación de gravedad de 9,8 sobre 10 por parte de MITRE. La inyección SQL ha sido la pesadilla de los profesionales de la seguridad desde finales de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporciona una alfombra roja a los datos sensibles para los actores de amenazas.
El escenario MOVEit es un poco diferente de lo que muchos desarrolladores y profesionales de AppSec pueden haber experimentado previamente, y usted puede probar sus habilidades SQLi-slaying en una simulación en vivo aquí:
>>> JUGAR LA MISIÓN MOVEit
La vulnerabilidad: Inyección SQL
¿Cómo se utilizó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P fue capaz de explotar la vulnerabilidad de inyección SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. A partir de ahí, pudieron instalar LEMURLOOT, una shell web que les permitiría ejecutar varios procesos críticos de alto riesgo, como la recuperación de la configuración del sistema, la enumeración de la base de datos SQL, la recuperación de archivos del sistema MOVEit Transfer y la creación de una nueva cuenta con todos los privilegios de administración.
Huelga decir que este vector de ataque puede ser el resultado de un error relativamente simple -que podría achacarse al uso perpetuo de patrones de codificación deficientes-, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Comparable al exploit MOVEit, echemos un vistazo a este explicador de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena de consulta y variable:
string emailAddress ="contact@scw.com";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
dará como resultado la siguiente consulta:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'";
... y con entrada maliciosa:
string emailAddress = "contact@scw.com'; DELETE FROM Facturas WHERE Id = 2;--";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
se convertirá en:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'; DELETE FROM Invoices WHERE Id = 2;--'";
¿Cómo se ve en vuelo?
Tenga en cuenta que, debido a la concatenación de cadenas, la entrada se interpreta como sintaxis SQL. En primer lugar, se añade una comilla simple para asegurarse de que la sentencia SELECT es una sintaxis SQL válida. A continuación, se añade un punto y coma para terminar la primera sentencia.
Una vez hecho esto, se añade una sentencia DELETE válida, seguida de dos guiones para comentar los caracteres finales (la comilla simple). También se podría añadir una sentencia UPDATE, por ejemplo, si el SQL malicioso fuera para actualizar los roles o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Aunque relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque, y uno demasiado común. En el caso de MOVEit, este exploit dio paso a la instalación de una puerta trasera dañina y a un grupo de ataques adicionales de gravedad similar.
¿Cómo mitigar el riesgo de inyección SQL?
Para cualquier compañía que utilice MOVEit como parte de sus operaciones de negocio, es imperativo que sigan los consejos de remediación recomendados por Progress Software. Esto incluye, entre otras cosas, la aplicación de parches de seguridad como prioridad de emergencia.
Para la inyección SQL en general, echa un vistazo a nuestra guía completa.
¿Quieres aprender más acerca de cómo escribir código seguro y mitigar el riesgo? Pruebe nuestro desafío de inyección SQL de forma gratuita.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Secure Code Coach para ayudarle a mantenerse al día de las mejores prácticas de codificación segura.
El escenario MOVEit es un poco diferente de lo que muchos desarrolladores y profesionales de AppSec pueden haber experimentado previamente, y usted puede probar sus habilidades SQLi-slaying en una simulación en vivo aquí mismo.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Los ciberataques a la cadena de suministro de software son cada vez más frecuentes, lo que ha provocado una oleada de cambios legislativos en el gobierno estadounidense, mientras las empresas se esfuerzan por mitigar su perfil de riesgo expansivo y mejorar rápidamente la calidad del software. Sólo este año se han producido tres vulnerabilidades de día cero relacionadas con servicios de intercambio de archivos, la mayor y más destructiva de las cuales es el exploit masivo MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias de ciberseguridad durante algún tiempo, con más de 1.000 organizaciones afectadas. Se prevé que esta cifra siga creciendo, convirtiéndose en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta brecha generalizada fue un grupo de vulnerabilidades de inyección SQL, que recibió una puntuación de gravedad de 9,8 sobre 10 por parte de MITRE. La inyección SQL ha sido la pesadilla de los profesionales de la seguridad desde finales de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporciona una alfombra roja a los datos sensibles para los actores de amenazas.
El escenario MOVEit es un poco diferente de lo que muchos desarrolladores y profesionales de AppSec pueden haber experimentado previamente, y usted puede probar sus habilidades SQLi-slaying en una simulación en vivo aquí:
>>> JUGAR LA MISIÓN MOVEit
La vulnerabilidad: Inyección SQL
¿Cómo se utilizó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P fue capaz de explotar la vulnerabilidad de inyección SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. A partir de ahí, pudieron instalar LEMURLOOT, una shell web que les permitiría ejecutar varios procesos críticos de alto riesgo, como la recuperación de la configuración del sistema, la enumeración de la base de datos SQL, la recuperación de archivos del sistema MOVEit Transfer y la creación de una nueva cuenta con todos los privilegios de administración.
Huelga decir que este vector de ataque puede ser el resultado de un error relativamente simple -que podría achacarse al uso perpetuo de patrones de codificación deficientes-, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Comparable al exploit MOVEit, echemos un vistazo a este explicador de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena de consulta y variable:
string emailAddress ="contact@scw.com";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
dará como resultado la siguiente consulta:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'";
... y con entrada maliciosa:
string emailAddress = "contact@scw.com'; DELETE FROM Facturas WHERE Id = 2;--";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
se convertirá en:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'; DELETE FROM Invoices WHERE Id = 2;--'";
¿Cómo se ve en vuelo?
Tenga en cuenta que, debido a la concatenación de cadenas, la entrada se interpreta como sintaxis SQL. En primer lugar, se añade una comilla simple para asegurarse de que la sentencia SELECT es una sintaxis SQL válida. A continuación, se añade un punto y coma para terminar la primera sentencia.
Una vez hecho esto, se añade una sentencia DELETE válida, seguida de dos guiones para comentar los caracteres finales (la comilla simple). También se podría añadir una sentencia UPDATE, por ejemplo, si el SQL malicioso fuera para actualizar los roles o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Aunque relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque, y uno demasiado común. En el caso de MOVEit, este exploit dio paso a la instalación de una puerta trasera dañina y a un grupo de ataques adicionales de gravedad similar.
¿Cómo mitigar el riesgo de inyección SQL?
Para cualquier compañía que utilice MOVEit como parte de sus operaciones de negocio, es imperativo que sigan los consejos de remediación recomendados por Progress Software. Esto incluye, entre otras cosas, la aplicación de parches de seguridad como prioridad de emergencia.
Para la inyección SQL en general, echa un vistazo a nuestra guía completa.
¿Quieres aprender más acerca de cómo escribir código seguro y mitigar el riesgo? Pruebe nuestro desafío de inyección SQL de forma gratuita.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Secure Code Coach para ayudarle a mantenerse al día de las mejores prácticas de codificación segura.
Los ciberataques a la cadena de suministro de software son cada vez más frecuentes, lo que ha provocado una oleada de cambios legislativos en el gobierno estadounidense, mientras las empresas se esfuerzan por mitigar su perfil de riesgo expansivo y mejorar rápidamente la calidad del software. Sólo este año se han producido tres vulnerabilidades de día cero relacionadas con servicios de intercambio de archivos, la mayor y más destructiva de las cuales es el exploit masivo MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias de ciberseguridad durante algún tiempo, con más de 1.000 organizaciones afectadas. Se prevé que esta cifra siga creciendo, convirtiéndose en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta brecha generalizada fue un grupo de vulnerabilidades de inyección SQL, que recibió una puntuación de gravedad de 9,8 sobre 10 por parte de MITRE. La inyección SQL ha sido la pesadilla de los profesionales de la seguridad desde finales de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporciona una alfombra roja a los datos sensibles para los actores de amenazas.
El escenario MOVEit es un poco diferente de lo que muchos desarrolladores y profesionales de AppSec pueden haber experimentado previamente, y usted puede probar sus habilidades SQLi-slaying en una simulación en vivo aquí:
>>> JUGAR LA MISIÓN MOVEit
La vulnerabilidad: Inyección SQL
¿Cómo se utilizó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P fue capaz de explotar la vulnerabilidad de inyección SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. A partir de ahí, pudieron instalar LEMURLOOT, una shell web que les permitiría ejecutar varios procesos críticos de alto riesgo, como la recuperación de la configuración del sistema, la enumeración de la base de datos SQL, la recuperación de archivos del sistema MOVEit Transfer y la creación de una nueva cuenta con todos los privilegios de administración.
Huelga decir que este vector de ataque puede ser el resultado de un error relativamente simple -que podría achacarse al uso perpetuo de patrones de codificación deficientes-, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Comparable al exploit MOVEit, echemos un vistazo a este explicador de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena de consulta y variable:
string emailAddress ="contact@scw.com";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
dará como resultado la siguiente consulta:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'";
... y con entrada maliciosa:
string emailAddress = "contact@scw.com'; DELETE FROM Facturas WHERE Id = 2;--";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
se convertirá en:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'; DELETE FROM Invoices WHERE Id = 2;--'";
¿Cómo se ve en vuelo?
Tenga en cuenta que, debido a la concatenación de cadenas, la entrada se interpreta como sintaxis SQL. En primer lugar, se añade una comilla simple para asegurarse de que la sentencia SELECT es una sintaxis SQL válida. A continuación, se añade un punto y coma para terminar la primera sentencia.
Una vez hecho esto, se añade una sentencia DELETE válida, seguida de dos guiones para comentar los caracteres finales (la comilla simple). También se podría añadir una sentencia UPDATE, por ejemplo, si el SQL malicioso fuera para actualizar los roles o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Aunque relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque, y uno demasiado común. En el caso de MOVEit, este exploit dio paso a la instalación de una puerta trasera dañina y a un grupo de ataques adicionales de gravedad similar.
¿Cómo mitigar el riesgo de inyección SQL?
Para cualquier compañía que utilice MOVEit como parte de sus operaciones de negocio, es imperativo que sigan los consejos de remediación recomendados por Progress Software. Esto incluye, entre otras cosas, la aplicación de parches de seguridad como prioridad de emergencia.
Para la inyección SQL en general, echa un vistazo a nuestra guía completa.
¿Quieres aprender más acerca de cómo escribir código seguro y mitigar el riesgo? Pruebe nuestro desafío de inyección SQL de forma gratuita.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Secure Code Coach para ayudarle a mantenerse al día de las mejores prácticas de codificación segura.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Los ciberataques a la cadena de suministro de software son cada vez más frecuentes, lo que ha provocado una oleada de cambios legislativos en el gobierno estadounidense, mientras las empresas se esfuerzan por mitigar su perfil de riesgo expansivo y mejorar rápidamente la calidad del software. Sólo este año se han producido tres vulnerabilidades de día cero relacionadas con servicios de intercambio de archivos, la mayor y más destructiva de las cuales es el exploit masivo MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias de ciberseguridad durante algún tiempo, con más de 1.000 organizaciones afectadas. Se prevé que esta cifra siga creciendo, convirtiéndose en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta brecha generalizada fue un grupo de vulnerabilidades de inyección SQL, que recibió una puntuación de gravedad de 9,8 sobre 10 por parte de MITRE. La inyección SQL ha sido la pesadilla de los profesionales de la seguridad desde finales de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporciona una alfombra roja a los datos sensibles para los actores de amenazas.
El escenario MOVEit es un poco diferente de lo que muchos desarrolladores y profesionales de AppSec pueden haber experimentado previamente, y usted puede probar sus habilidades SQLi-slaying en una simulación en vivo aquí:
>>> JUGAR LA MISIÓN MOVEit
La vulnerabilidad: Inyección SQL
¿Cómo se utilizó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P fue capaz de explotar la vulnerabilidad de inyección SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. A partir de ahí, pudieron instalar LEMURLOOT, una shell web que les permitiría ejecutar varios procesos críticos de alto riesgo, como la recuperación de la configuración del sistema, la enumeración de la base de datos SQL, la recuperación de archivos del sistema MOVEit Transfer y la creación de una nueva cuenta con todos los privilegios de administración.
Huelga decir que este vector de ataque puede ser el resultado de un error relativamente simple -que podría achacarse al uso perpetuo de patrones de codificación deficientes-, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Comparable al exploit MOVEit, echemos un vistazo a este explicador de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena de consulta y variable:
string emailAddress ="contact@scw.com";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
dará como resultado la siguiente consulta:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'";
... y con entrada maliciosa:
string emailAddress = "contact@scw.com'; DELETE FROM Facturas WHERE Id = 2;--";
var query = $"SELECT u.UserName From Users as u WHERE u.Email = '{emailAddress}'";
se convertirá en:
var query = $"SELECT u.UserName From Users as u WHERE u.Email = 'contact@scw.com'; DELETE FROM Invoices WHERE Id = 2;--'";
¿Cómo se ve en vuelo?
Tenga en cuenta que, debido a la concatenación de cadenas, la entrada se interpreta como sintaxis SQL. En primer lugar, se añade una comilla simple para asegurarse de que la sentencia SELECT es una sintaxis SQL válida. A continuación, se añade un punto y coma para terminar la primera sentencia.
Una vez hecho esto, se añade una sentencia DELETE válida, seguida de dos guiones para comentar los caracteres finales (la comilla simple). También se podría añadir una sentencia UPDATE, por ejemplo, si el SQL malicioso fuera para actualizar los roles o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Aunque relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque, y uno demasiado común. En el caso de MOVEit, este exploit dio paso a la instalación de una puerta trasera dañina y a un grupo de ataques adicionales de gravedad similar.
¿Cómo mitigar el riesgo de inyección SQL?
Para cualquier compañía que utilice MOVEit como parte de sus operaciones de negocio, es imperativo que sigan los consejos de remediación recomendados por Progress Software. Esto incluye, entre otras cosas, la aplicación de parches de seguridad como prioridad de emergencia.
Para la inyección SQL en general, echa un vistazo a nuestra guía completa.
¿Quieres aprender más acerca de cómo escribir código seguro y mitigar el riesgo? Pruebe nuestro desafío de inyección SQL de forma gratuita.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Secure Code Coach para ayudarle a mantenerse al día de las mejores prácticas de codificación segura.
Índice
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
