Inmersión profunda: Conozca de cerca y de manera personal la vulnerabilidad de día cero de MOVEit
Los ciberataques a la cadena de suministro de software son cada vez más comunes, lo que ha provocado una serie de cambios legislativos a nivel gubernamental de EE. UU., mientras las empresas se esfuerzan por mitigar su amplio perfil de riesgo y mejorar rápidamente la calidad del software. Solo este año se han registrado tres vulnerabilidades de día cero relacionadas con los servicios de intercambio de archivos, y la mayor y más destructiva es la del exploit masivo de MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias sobre ciberseguridad durante algún tiempo, con más de 1000 organizaciones afectadas. Se prevé que este número siga creciendo, lo que lo convierte en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta violación generalizada fue un grupo de vulnerabilidades de inyección de SQL que, en última instancia, recibieron una puntuación de gravedad de 9.8 de 10 desde MITRE. La inyección de SQL ha sido el problema de los profesionales de la seguridad desde finales de la década de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporcionando una alfombra roja a los datos confidenciales para los actores de amenazas.
El escenario de MOVEit es un poco diferente al que muchos desarrolladores y profesionales de AppSec pueden haber experimentado anteriormente, y puede poner a prueba sus habilidades de destrucción de SQL en una simulación en vivo aquí mismo:
>>> JUEGA A LA MISIÓN MOVEit
La vulnerabilidad: inyección SQL
¿Cómo se usó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P pudo aprovechar la vulnerabilidad de inyección de SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. Desde allí, pudieron instalar LEMURLOOT, un shell web que, en última instancia, les permitiría ejecutar varios procesos críticos y 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.
No hace falta decir que este vector de ataque puede ser el resultado de un error relativamente simple, que podría atribuirse al uso perpetuo de patrones de codificación deficientes, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Al igual que el exploit MOVEit, echemos un vistazo a esta explicación de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena y variable de consulta:
cadena EmailAddress =»contact@scw.com«;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
dará como resultado la siguiente consulta:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'»;
... y con entradas creadas con fines malintencionados:
string emailAddress = "contact@scw.com '; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --»;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
se convertirá en:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --'»;
¿Cómo se ve eso 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 que esté en su lugar, se agrega una instrucción DELETE válida, seguida de dos guiones para comentar los caracteres finales (las comillas simples). Una sentencia UPDATE podría añadirse con la misma facilidad, por ejemplo, si el SQL malintencionado tuviera que actualizar las funciones o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Si bien es relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque y muy común. En el caso de MOVEit, este exploit dio paso a una dañina instalación de puerta trasera y a un grupo de ataques adicionales de gravedad similar.
¿Cómo se puede mitigar el riesgo de inyección de SQL?
Para cualquier empresa que utilice MOVEit como parte de sus operaciones comerciales, es imprescindible que siga los consejos de remediación recomendados por Software Progress. Esto incluye, entre otros, la aplicación de parches de seguridad como prioridad de nivel de emergencia.
Para la inyección de SQL en general, consulte nuestra guía completa.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos? Pruebe nuestro Desafío de inyección de SQL gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
El escenario de MOVEit es un poco diferente al que muchos desarrolladores y profesionales de AppSec pueden haber experimentado anteriormente, y puede poner a prueba sus habilidades de destrucción de SQL en una simulación en vivo aquí mismo.
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
Los ciberataques a la cadena de suministro de software son cada vez más comunes, lo que ha provocado una serie de cambios legislativos a nivel gubernamental de EE. UU., mientras las empresas se esfuerzan por mitigar su amplio perfil de riesgo y mejorar rápidamente la calidad del software. Solo este año se han registrado tres vulnerabilidades de día cero relacionadas con los servicios de intercambio de archivos, y la mayor y más destructiva es la del exploit masivo de MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias sobre ciberseguridad durante algún tiempo, con más de 1000 organizaciones afectadas. Se prevé que este número siga creciendo, lo que lo convierte en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta violación generalizada fue un grupo de vulnerabilidades de inyección de SQL que, en última instancia, recibieron una puntuación de gravedad de 9.8 de 10 desde MITRE. La inyección de SQL ha sido el problema de los profesionales de la seguridad desde finales de la década de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporcionando una alfombra roja a los datos confidenciales para los actores de amenazas.
El escenario de MOVEit es un poco diferente al que muchos desarrolladores y profesionales de AppSec pueden haber experimentado anteriormente, y puede poner a prueba sus habilidades de destrucción de SQL en una simulación en vivo aquí mismo:
>>> JUEGA A LA MISIÓN MOVEit
La vulnerabilidad: inyección SQL
¿Cómo se usó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P pudo aprovechar la vulnerabilidad de inyección de SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. Desde allí, pudieron instalar LEMURLOOT, un shell web que, en última instancia, les permitiría ejecutar varios procesos críticos y 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.
No hace falta decir que este vector de ataque puede ser el resultado de un error relativamente simple, que podría atribuirse al uso perpetuo de patrones de codificación deficientes, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Al igual que el exploit MOVEit, echemos un vistazo a esta explicación de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena y variable de consulta:
cadena EmailAddress =»contact@scw.com«;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
dará como resultado la siguiente consulta:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'»;
... y con entradas creadas con fines malintencionados:
string emailAddress = "contact@scw.com '; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --»;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
se convertirá en:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --'»;
¿Cómo se ve eso 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 que esté en su lugar, se agrega una instrucción DELETE válida, seguida de dos guiones para comentar los caracteres finales (las comillas simples). Una sentencia UPDATE podría añadirse con la misma facilidad, por ejemplo, si el SQL malintencionado tuviera que actualizar las funciones o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Si bien es relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque y muy común. En el caso de MOVEit, este exploit dio paso a una dañina instalación de puerta trasera y a un grupo de ataques adicionales de gravedad similar.
¿Cómo se puede mitigar el riesgo de inyección de SQL?
Para cualquier empresa que utilice MOVEit como parte de sus operaciones comerciales, es imprescindible que siga los consejos de remediación recomendados por Software Progress. Esto incluye, entre otros, la aplicación de parches de seguridad como prioridad de nivel de emergencia.
Para la inyección de SQL en general, consulte nuestra guía completa.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos? Pruebe nuestro Desafío de inyección de SQL gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
Los ciberataques a la cadena de suministro de software son cada vez más comunes, lo que ha provocado una serie de cambios legislativos a nivel gubernamental de EE. UU., mientras las empresas se esfuerzan por mitigar su amplio perfil de riesgo y mejorar rápidamente la calidad del software. Solo este año se han registrado tres vulnerabilidades de día cero relacionadas con los servicios de intercambio de archivos, y la mayor y más destructiva es la del exploit masivo de MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias sobre ciberseguridad durante algún tiempo, con más de 1000 organizaciones afectadas. Se prevé que este número siga creciendo, lo que lo convierte en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta violación generalizada fue un grupo de vulnerabilidades de inyección de SQL que, en última instancia, recibieron una puntuación de gravedad de 9.8 de 10 desde MITRE. La inyección de SQL ha sido el problema de los profesionales de la seguridad desde finales de la década de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporcionando una alfombra roja a los datos confidenciales para los actores de amenazas.
El escenario de MOVEit es un poco diferente al que muchos desarrolladores y profesionales de AppSec pueden haber experimentado anteriormente, y puede poner a prueba sus habilidades de destrucción de SQL en una simulación en vivo aquí mismo:
>>> JUEGA A LA MISIÓN MOVEit
La vulnerabilidad: inyección SQL
¿Cómo se usó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P pudo aprovechar la vulnerabilidad de inyección de SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. Desde allí, pudieron instalar LEMURLOOT, un shell web que, en última instancia, les permitiría ejecutar varios procesos críticos y 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.
No hace falta decir que este vector de ataque puede ser el resultado de un error relativamente simple, que podría atribuirse al uso perpetuo de patrones de codificación deficientes, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Al igual que el exploit MOVEit, echemos un vistazo a esta explicación de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena y variable de consulta:
cadena EmailAddress =»contact@scw.com«;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
dará como resultado la siguiente consulta:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'»;
... y con entradas creadas con fines malintencionados:
string emailAddress = "contact@scw.com '; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --»;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
se convertirá en:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --'»;
¿Cómo se ve eso 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 que esté en su lugar, se agrega una instrucción DELETE válida, seguida de dos guiones para comentar los caracteres finales (las comillas simples). Una sentencia UPDATE podría añadirse con la misma facilidad, por ejemplo, si el SQL malintencionado tuviera que actualizar las funciones o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Si bien es relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque y muy común. En el caso de MOVEit, este exploit dio paso a una dañina instalación de puerta trasera y a un grupo de ataques adicionales de gravedad similar.
¿Cómo se puede mitigar el riesgo de inyección de SQL?
Para cualquier empresa que utilice MOVEit como parte de sus operaciones comerciales, es imprescindible que siga los consejos de remediación recomendados por Software Progress. Esto incluye, entre otros, la aplicación de parches de seguridad como prioridad de nivel de emergencia.
Para la inyección de SQL en general, consulte nuestra guía completa.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos? Pruebe nuestro Desafío de inyección de SQL gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
報告書を見るデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
Los ciberataques a la cadena de suministro de software son cada vez más comunes, lo que ha provocado una serie de cambios legislativos a nivel gubernamental de EE. UU., mientras las empresas se esfuerzan por mitigar su amplio perfil de riesgo y mejorar rápidamente la calidad del software. Solo este año se han registrado tres vulnerabilidades de día cero relacionadas con los servicios de intercambio de archivos, y la mayor y más destructiva es la del exploit masivo de MOVEit.
Encabezado por el grupo de ransomware CL0P, el incidente MOVEit ha dominado las noticias sobre ciberseguridad durante algún tiempo, con más de 1000 organizaciones afectadas. Se prevé que este número siga creciendo, lo que lo convierte en uno de los ataques a la cadena de suministro de software más potentes desde Solarwinds en 2021.
El catalizador de esta violación generalizada fue un grupo de vulnerabilidades de inyección de SQL que, en última instancia, recibieron una puntuación de gravedad de 9.8 de 10 desde MITRE. La inyección de SQL ha sido el problema de los profesionales de la seguridad desde finales de la década de los 90 y, a pesar de ser una solución bastante sencilla, sigue encontrando su camino en el software moderno y proporcionando una alfombra roja a los datos confidenciales para los actores de amenazas.
El escenario de MOVEit es un poco diferente al que muchos desarrolladores y profesionales de AppSec pueden haber experimentado anteriormente, y puede poner a prueba sus habilidades de destrucción de SQL en una simulación en vivo aquí mismo:
>>> JUEGA A LA MISIÓN MOVEit
La vulnerabilidad: inyección SQL
¿Cómo se usó exactamente la inyección SQL para explotar la aplicación de transferencia de archivos MOVEit de Progress Software?
El grupo de ransomware CL0P pudo aprovechar la vulnerabilidad de inyección de SQL CVE-2023-34362, lo que les permitió acceder sin restricciones y sin autorización a la base de datos de MOVEit. Desde allí, pudieron instalar LEMURLOOT, un shell web que, en última instancia, les permitiría ejecutar varios procesos críticos y 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.
No hace falta decir que este vector de ataque puede ser el resultado de un error relativamente simple, que podría atribuirse al uso perpetuo de patrones de codificación deficientes, pero su potencial para causar problemas continuos a nivel empresarial es inmenso.
Al igual que el exploit MOVEit, echemos un vistazo a esta explicación de SQLi, que simula el método de inyección y ejecución de SQL malicioso:
Esta cadena y variable de consulta:
cadena EmailAddress =»contact@scw.com«;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
dará como resultado la siguiente consulta:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'»;
... y con entradas creadas con fines malintencionados:
string emailAddress = "contact@scw.com '; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --»;
var query = $"SELECT u.Username de los usuarios como u WHERE u.Email = '{emailAddress}'»;
se convertirá en:
var query = $"SELECT u.Nombre de usuario de usuarios como u WHERE u.Email = 'contact@scw.com'; ELIMINAR DE LAS FACTURAS DONDE ID = 2; --'»;
¿Cómo se ve eso 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 que esté en su lugar, se agrega una instrucción DELETE válida, seguida de dos guiones para comentar los caracteres finales (las comillas simples). Una sentencia UPDATE podría añadirse con la misma facilidad, por ejemplo, si el SQL malintencionado tuviera que actualizar las funciones o contraseñas de los usuarios.
Pruébalo tú mismo en esta misión jugable:
Si bien es relativamente sencillo, SQLi sigue siendo un poderoso vector de ataque y muy común. En el caso de MOVEit, este exploit dio paso a una dañina instalación de puerta trasera y a un grupo de ataques adicionales de gravedad similar.
¿Cómo se puede mitigar el riesgo de inyección de SQL?
Para cualquier empresa que utilice MOVEit como parte de sus operaciones comerciales, es imprescindible que siga los consejos de remediación recomendados por Software Progress. Esto incluye, entre otros, la aplicación de parches de seguridad como prioridad de nivel de emergencia.
Para la inyección de SQL en general, consulte nuestra guía completa.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos? Pruebe nuestro Desafío de inyección de SQL gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
%20(1).avif)
.avif)
