En resumen, la respuesta es sí al uso de caracteres UTF-8 en una cadena de ataque. Hay algunos casos que se han cruzado en mi camino. Lo que he leído sobre este método de ataque, es que este es el último paso para "soltar shell" en una cadena de ataque en un sistema nativo. Con un rápido "Google", surgió este artículo.
" Uso de la codificación UTF-8 para omitir la lógica de validación "
El artículo continúa explicando exactamente cómo se usa este método en particular. Aquí está el resumen ejecutivo.
"Este ataque es una variación específica en el aprovechamiento de codificaciones alternativas para eludir la lógica de validación. Este ataque aprovecha la posibilidad de codificar entradas potencialmente dañinas en UTF-8 y enviarlas a aplicaciones que no esperan o son efectivas para validar este estándar de codificación que realiza el filtrado de entradas difícil. UTF-8 (formato de transformación UCS / Unicode de 8 bits) es una codificación de caracteres de longitud variable para Unicode. Los caracteres UTF-8 legales tienen una longitud de uno a cuatro bytes. Sin embargo, la versión anterior de la especificación UTF-8 obtuvo algunas entradas incorrecto (en algunos casos permitió caracteres demasiado largos). Se supone que los codificadores UTF-8 usan la codificación "más corta posible", pero los decodificadores ingenuos pueden aceptar codificaciones que son más largas de lo necesario. Según el RFC 3629, una forma particularmente sutil de esto el ataque puede llevarse a cabo contra un analizador que realiza verificaciones de validez crítica de seguridad contra la forma codificada en UTF-8 de su entrada, pero interpreta ciertas secuencias de octetos ilegales como caracteres ".
Este tema ha surgido antes, aunque el caso de uso no está disponible durante este escrito. Si se encuentra más tarde, se agregará como un comentario.
Lo que se recuerda, era un método de cadena de ataque que había ganado la entrada a un sistema nativo y estaba inactivo. Cuando se ganó la entrada a través del firewall, se denegó el acceso. Luego, el programa se transformó en un archivo UTF-8 hasta un momento en que podía obtener acceso más allá del software de seguridad. Una vez que se abrió el agujero, debido a la codificación de bits de caracteres, el programa python pudo abrir un indicador de comandos o "descartar shell". El atacante entonces tenía acceso completo a la raíz. Luego abrió una puerta de entrada para otra parte del programa que estaba en espera.
Es muy similar al estudio "Uso de la codificación UTF-8 para omitir la lógica de validación" en la forma en que se enmascara y se vuelve ilegible para el software de seguridad. Los métodos de ataque son muy similares.
Métodos de ataque
1. inyección
2. Protocolo de manipulación
3. Abuso de API
En el caso que había leído antes, el objetivo del programa era penetrar lo más profundo posible. Si está bloqueado, si no, se transforma en un UTF-8 y realiza ataques en la materia prescrita. Si tiene éxito, abra una puerta de enlace a otra parte del malware que se encuentra más abajo en la cadena de ataque.
Tengo que decirlo, es interesante pensar en ello. A mi modo de ver, si puede escribir código que pueda superar el alcance limitado de otro sistema, tendrá éxito en el ataque. Si el código de defensa tiene restricciones y el código de ataque tiene opciones y opciones que nunca fueron programadas en el alcance del defensor, entonces es una pérdida obvia. Especialmente, cuando puedes tener una IA o un atacante de aprendizaje automático.
Atributo para el equipo de contenido de CAPEC, The MITRE Corporation 2014-06-23 Internal_CAPEC_Team para el artículo.