¿Qué es un ataque RCE (Ejecución remota de código)?
La ejecución remota de código se utiliza para exponer una forma de vulnerabilidad que se puede explotar cuando la entrada del usuario se inyecta en un archivo o cadena y todo el paquete se ejecuta en el analizador del lenguaje de programación. Este no es el tipo de comportamiento que muestra el desarrollador de la aplicación web. Un Ataque de Ejecución de Código Remoto puede llevar a un ataque a gran escala que pondría en peligro toda una aplicación web y el servidor web. También debe tener en cuenta que prácticamente todos los lenguajes de programación tienen diferentes funciones de evaluación de código.
También puede producirse una evaluación de código si permite que las entradas del usuario obtengan acceso a funciones que evalúan código en el mismo lenguaje de programación. Este tipo de medida puede implementarse a propósito para obtener acceso a las funciones matemáticas del lenguaje de programación o por accidente porque la entrada controlada por el usuario está diseñada por el desarrollador para estar dentro de cualquiera de estas funciones. No es aconsejable llevar a cabo esta línea de acción. A muchas personas les resulta malicioso incluso usar la evaluación de código.
Ejemplo de código
Echemos un vistazo a un ejemplo de ataque de evaluación de código.
Puede parecer una mejor idea tener nombres de variables generados dinámicamente para cada usuario y almacenar su fecha de registro. Este es un ejemplo de cómo puedes hacerlo en PHP
eval("$$user = '$regdate');As long as the username is controlled by the user's input, an attacker may create a name like this:x = 'y';phpinfo();//El código PHP que se genera se asemejaría a este:
$x = 'y';phpinfo();// = 2016';Ahora puede ver que la variable se conoce como x pero tiene el valor de y. Cuando el atacante puede asignar otro valor a la variable, podrá crear un nuevo comando usando un punto y coma (;). Ahora puede rellenar el resto de la cadena. De esta manera, no obtendrá ningún error de sintaxis en su trabajo. Tan pronto como ejecute este código, la salida de phpinfo se mostrará en la página. Siempre debe recordar que es posible en PHP y otros lenguajes con características que pueden evaluar la entrada.
Organizar la Ejecución Remota de Código por Origen
La mayoría de las debilidades de RCE distinguidas se deben a ciertas causas básicas que se pueden seguir hasta su punto de partida. La agrupación de la Ejecución Remota de Código por principio se examina de la siguiente manera.
Ejecución dinámica de código
La ejecución dinámica de código es, según todas las cuentas, la razón básica más ampliamente reconocida que provoca un ataque de ejecución de código. Muchos dialectos de programación están planificados de tal manera que pueden producir código con otro código y ejecutarlo de inmediato. Esta idea es increíble y se ocupa de varios problemas complejos. Sea como fuere, un atacante malévolo puede controlar esta idea para adquirir acceso y capacidades de RCE.
Normalmente, el código producido rápidamente depende de cierta entrada del cliente. Habitualmente, el código incorpora la información que se ha recordado para una estructura específica. Cuando un agresor maligno entiende que el poderoso code age utilizará cierta información, podría crear un código sustancial como un tipo de acceso para separar la aplicación. Si no se examinan las contribuciones de los clientes, el código se ejecutará según su objetivo.
En el momento en que elige mirar con cuidado, la ejecución dinámica de código es responsable de dos tipos de ataques basados en RCE; inmediatos y tortuosos.
Directo
Al administrar una ilustración de ejecución de tributo único directo, el agresor se da cuenta de que su retroalimentación se utilizaría para producir código.
Indirecto
De una manera aberrante, está preocupado por la poderosa edad del código con las entradas del cliente. La entrada del cliente suele estar sujeta a al menos una capa. Una parte de las capas podría ser responsable de cambiar la contribución antes de que termine con la edad del código dinámico. Además, la antigüedad dinámica del código puede ser un impacto posterior y no la utilización inmediata de la información. Esa es la razón por la que puede no estar claro para el cliente que está dando la información que se completará como un bloque de estructura en un fragmento de código que se ejecutaría a distancia.
Deserialización
Deserialización es una guía increíble para representar la circunstancia actual. No debería ocurrir una edad de código poderosa durante la deserialización. Intermitentemente, esta es la situación que ocurre cuando el objeto serializado contiene campos de información crudos u objetos de un tipo comparable. Las cosas se confunden más cuando los elementos del artículo son serializados. La deserialización también incorporaría algún grado de antigüedad dinámica del código.
Puede parecer que los dialectos poderosos son los únicos influenciados por la serialización del trabajo. Siempre que esto sea cierto, la cuestión sería muy restringida. Sea como fuere, esta situación también es muy útil en dialectos estáticos. Es más difícil de lograr con el lenguaje estático, pero ciertamente no es factible.
De forma intermitente, la ejecución de esta idea gestiona las capacidades intermedias producidas por la deserialización. Los objetos de antigüedad en tiempo de ejecución son concebibles con la antigüedad del código dinámico. Esto implica que si la información que será deserializada se hace en una solicitud hecha a distancia, un atacante malévolo podría requisarla y ajustarla. Todos los bits de código planificados también podrían familiarizarse con stunt the powerful code age para ejecutar la capacidad cuando se incorpora como una pieza de la deserialización.
Seguridad de la memoria
Una razón básica más para los ataques de RCE se identifica con la seguridad de la memoria o la seguridad de la API. El bienestar de la memoria alude a la contraacción del código de llegar a piezas fundamentales de memoria que no instaló. Es normal esperar que la falta de seguridad de la memoria dé lugar a un acceso no autorizado a la información. En cualquier caso, el marco de trabajo y el equipo dependen de la memoria para almacenar el código ejecutable. Los metadatos que se identifican con la ejecución de código se guardan en la memoria. Acceder a esta parte de la memoria podría provocar ACE y RCE. De esta manera, ¿cuáles son una parte de las razones de los problemas de bienestar de la memoria?
Las imperfecciones del plan del producto
Las imperfecciones en la configuración del producto son un tipo de debilidad de bienestar de memoria que ocurre cuando hay un error de planificación en una parte oculta específica. De forma intermitente, la parte defectuosa podría ser un compilador, un traductor, una máquina virtual o incluso la parte del marco de trabajo o la biblioteca. Hay varias imperfecciones en esta clase. Una parte de la incorporación;
Desbordamiento de búfer
Desbordamiento de búfer aludido además como exceso de búfer, se puede utilizar para aludir a un método básico y famoso que se utiliza para romper el bienestar de la memoria. Este asalto aprovecha una mancha de plan específica o un error para mantenerse en contacto con las células de memoria que están situadas hacia el final del cojín de memoria. El soporte se recuperaría de una llamada auténtica a la API pública. Sin embargo, cradle solo alude a un lugar de inicio la amenaza se utiliza para registrar las ubicaciones de memoria reales de un artículo o contador de programa específico. Su separación de la cuna es notable o, sin duda, puede especularse. Investigar el código cada vez que se hace accesible o solucionar la ejecución de todo el programa en tiempo de ejecución puede resultar útil para un agresor que necesita mirar en posiciones relativas.
Esto implica que una inundación de cuna permitiría alterar la memoria hasta cierto punto no disponible. La base puede encontrarse en el espacio de ubicación de una máquina más y se cambiará llamando a una API distante. Esto hará que la entrada a la memoria de la máquina remota. Existen numerosos enfoques para utilizar este tipo de acceso al hacer un doble trato de RCE. Hay una sospecha general de que suponiendo que haya una debilidad de inundación amortiguada, un asalto basado en RCE no está fuera de juego. Esto implica que se confía en los propietarios del código para reparar rápidamente sus inundaciones de soporte antes de que ocurra un asalto de RCE.
Defectos de diseño del equipo
Los ataques de bienestar de memoria también pueden deberse a defectos de configuración del equipo. No son tan normales como los ataques de programación y son mucho más difíciles de reconocer. Sin embargo, este tipo de asalto afecta enormemente el marco.
Impactos de la Vulnerabilidad de Evaluación Remota de Código
Un atacante que puede ejecutar un ataque Remoto basado en código en un sistema con éxito podría ejecutar otros comandos aprovechando el lenguaje de programación o el servidor web. En muchos lenguajes de programación, el atacante podría ordenar al sistema que escribiera, leyera o eliminara archivos. Incluso puede ser posible conectarse a diferentes bases de datos con el sistema atacado.
¿Por qué los atacantes lanzan ataques RCE?
Si bien no hay ninguna razón en particular por la que los atacantes opten por utilizar la explotación de RCE para atacar una aplicación web, no hay ninguna razón en particular. Es solo que a algunos maliciosos les resulta fácil aprovechar esta ejecución de código para obtener acceso a sus sistemas.
¿Cómo Se Evitan Los Ataques De Ejecución Remota De Código?
Para empezar, debe evitar el uso de la entrada del usuario dentro del código evaluado. La mejor opción en esta situación sería evitar por completo el uso de funciones como eval. Se considera una forma de mala práctica y se puede evitar fácilmente. También se recomienda que nunca deje que un usuario edite el contenido de archivos que puedan haber sido analizados por el lenguaje de programación en cuestión. A menudo, esto incluye permitir que un usuario cree el nombre y las extensiones de archivo que desea cargar o crear en la aplicación web.
Estas son algunas de las cosas que no debe hacer para evitar ataques basados en RCE. Incluyen::
- Desinfectar la entrada del usuario. A menudo, esto es difícil de lograr porque hay una gran cantidad de derivaciones y restricciones preinstaladas.
- Deje que un usuario decida o cree la extensión o el contenido de los archivos que se utilizarán en el servidor web. Él / ella tiene que usar muchas prácticas seguras cuando maneja cargas de archivos o corre el riesgo de que información vital caiga en manos equivocadas.
- Pase cualquier entrada controlada por el usuario a las devoluciones de llamada del sistema o a las funciones de evaluación
- Incluya activamente en la lista negra cualquier carácter especial o nombre de función. Esto debe evitarse al igual que desinfectar la entrada del usuario. Pero es increíblemente difícil de implementar.