1. Descripción general
En los últimos dos años, los expertos en seguridad deberían prestar más atención a los ataques en la capa de aplicación de red. Porque no importa cuán fuertes sean sus reglas de firewall o cuán diligente sea para parchearlas, si los desarrolladores de su aplicación web no siguen el código seguro, los atacantes ingresarán a su sistema a través del puerto 80. Las dos técnicas de ataque principales que se utilizan ampliamente son los ataques de inyección SQL [ref1] y CSS [ref2]. La inyección SQL se refiere a la técnica de insertar metacaracteres SQL (caracteres especiales que representan algunos datos) e instrucciones a través del área de entrada de Internet para manipular la ejecución de consultas SQL de back-end. Estos ataques se dirigen principalmente a servidores WEB de otras organizaciones. Los ataques CSS garantizan que el código Javascript malicioso se ejecute en la máquina de la víctima insertando etiquetas de script en las URL y luego convenciendo a los usuarios que confían en ellas para que hagan clic en ellas. Estos ataques se aprovechan de la relación de confianza entre el usuario y el servidor. De hecho, el servidor no detecta la entrada ni la salida y, por tanto, no rechaza el código JavaScript.
Este artículo analiza técnicas de detección de vulnerabilidades de inyección SQL y ataques CSS. Ha habido mucha discusión en Internet sobre estos dos tipos de ataques basados en WEB, como cómo implementar los ataques, su impacto y cómo preparar y diseñar mejor programas para prevenir estos ataques. Sin embargo, no hay suficiente discusión sobre cómo detectar estos ataques. Usamos el popular IDS Snort de código abierto [ref 3] para formular expresiones regulares basadas en reglas para detectar estos ataques. Por cierto, la configuración de reglas predeterminada de Snort incluye métodos para detectar CSS, pero estos se pueden evitar fácilmente. Por ejemplo, la mayoría usa codificación hexadecimal, como %3C%73%63%72%69%70% 74%3E en lugar de <script> para evitar la detección.
Dependiendo de las capacidades de la organización a nivel de paranoia, hemos escrito múltiples reglas para detectar el mismo ataque. Si desea detectar todos los posibles ataques de inyección SQL, simplemente debe prestar atención a los metacaracteres SQL existentes, como comillas simples, punto y coma y guiones dobles. Otra forma extrema de detectar ataques CSS es simplemente tener cuidado con los corchetes angulares en las etiquetas HTML. Pero esto detectará muchos errores. Para evitarlo, es necesario modificar las reglas para hacer más precisa su detección, sin evitar errores.
Utilice la palabra clave pcre (Expresiones regulares compatibles con Perl) [ref4] en las reglas de Snort, y cada regla se puede aplicar con o sin otras acciones de regla. Estas reglas también pueden ser utilizadas por software público como grep (una herramienta de búsqueda de documentos) para revisar los registros del servidor de red. Sin embargo, debe tener cuidado de que el servidor WEB registrará la entrada del usuario en el diario solo cuando la solicitud se envíe como GET. Si la solicitud se envía como POST, no se registrará en el diario.
2. Expresiones regulares para inyección SQL
Cuando elige una expresión regular para un ataque de inyección SQL, es importante recordar que un atacante puede realizar una inyección SQL enviando un formulario o mediante el campo Cookie. Su lógica de detección de entradas debe considerar varios tipos de entradas organizadas por el usuario (como información de formularios o cookies). Y si encuentra muchas advertencias provenientes de una regla, esté atento a las comillas simples o el punto y coma, ya que estos caracteres pueden ser entradas válidas en las cookies creadas por su aplicación web. Por lo tanto, debe evaluar cada regla con respecto a su aplicación web particular.
Como se mencionó anteriormente, una expresión regular detallada para detectar ataques de inyección SQL debe prestar atención a los metacaracteres especiales de SQL, como las comillas simples (') y los signos de doble expansión (--), para poder descubrir estos caracteres y sus número de equivalentes hexadecimales, se aplican las siguientes expresiones regulares:
2.1 Expresiones regulares para detectar metacaracteres SQL
/(%27)|(')|(--)|(%23)|(#)/ix
explicación:
Primero verificamos el hexadecimal de la comilla simple equivalente, la comilla simple en sí o la doble signo de expansión. Estos son caracteres de MS SQL Server u Oracle, lo que indica que los siguientes son comentarios y todos los siguientes se ignorarán. Además, si utiliza MySQL, debe prestar atención a la aparición de '#' y su equivalente hexadecimal. Tenga en cuenta que no necesitamos verificar el hexadecimal para el equivalente de doble guión, ya que este no es un metacarácter HTML y el navegador no lo codificará. Además, si un atacante logra modificar manualmente el doble guión a su valor hexadecimal de %2D (usando un proxy como Achilles [ref 5]), la inyección SQL fallará.
La nueva regla de Snort agregada a la expresión regular anterior es la siguiente:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"Inyección SQL - Paranoid"; flow:to_server,establecido;uricontent:".pl";pcre: "/ (%27)|(')|(--)|(%23)|(#)/i"; tipo de clase: ataque-aplicación-web
; En la discusión de este artículo, el valor de la palabra clave uricontent es ".pl" porque en nuestro entorno de prueba, el programa CGI está escrito en Perl. El valor de la palabra clave uricontent depende de su aplicación particular. Este valor puede ser ".php", ".asp", o ".jsp", etc. Desde este punto de vista, no mostramos las reglas de Snort correspondientes, pero daremos las expresiones regulares que crean estas reglas. Puede crear fácilmente muchas reglas de Snort a través de estas expresiones regulares. En las expresiones regulares anteriores, detectamos guiones dobles porque puede haber puntos de inyección SQL incluso si no hay comillas simples [ref 6]. Por ejemplo, una entrada de consulta SQL contiene solo valores numéricos, como sigue:
seleccione valor1, valor2, num_valor3 de la base de datos
donde num_value3=some_user_supplied_number
En este caso, el atacante puede ejecutar consultas SQL adicionales. La demostración envía la siguiente entrada:
3; insertar valores en some_other_table.
Finalmente, los modificadores pcre 'i' y 'x' se utilizan para hacer coincidir mayúsculas y minúsculas. ignorar respectivamente el espacio en blanco. Las reglas anteriores también se pueden ampliar para comprobar la presencia de punto y coma. Sin embargo, el punto y coma bien puede ser parte de una respuesta HTTP normal. Para reducir este error y evitar cualquier aparición normal de comillas simples y signos de doble expansión, las reglas anteriores deben modificarse para detectar primero la presencia de los signos =. La entrada del usuario responderá a una solicitud GET o POST. Generalmente, la entrada se envía de la siguiente manera:
nombre de usuario=algún_valor_suministrado_del_usuario&contraseña=algún_valor_suministrado_del_usuario
Por lo tanto, los intentos de inyección SQL harán que la entrada del usuario aparezca después del signo a = o su valor hexadecimal equivalente.
2.2 Corregir la expresión regular para detectar metacaracteres SQL
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Explicación:
Esta regla primero presta atención al signo = o su valor hexadecimal (%3D), luego considera cero o más caracteres, excepto nuevas líneas, y finalmente detecta comillas simples y guiones dobles o. punto y coma.
Una inyección SQL típica intentará manipular la consulta original mediante el uso de comillas simples para obtener un valor útil. Este ataque generalmente se analiza utilizando la cadena 1'or'1'='1. Sin embargo, la detección de esta cadena se puede evadir fácilmente, como por ejemplo usando 1'or2>1 --. el carácter inicial, siga una comilla simple y agregue 'o'. La lógica booleana que sigue puede variar en una variedad de estilos, desde ordinario hasta muy complejo. Estos ataques se pueden detectar con bastante precisión utilizando la siguiente expresión regular. El Capítulo 2.3 lo explica.
2.3 Expresión regular típica de ataque de inyección SQL
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (% 52))/ix
explicación:
w*: cero o más caracteres o guiones bajos.
(%27)|' - una comilla simple o su equivalente hexadecimal.
(%6 F)|o|(%4 F))((%72)|r|-(%52) - El caso de 'o' y su equivalente hexadecimal.
consulta union'SQL en inyección SQL Los ataques también son muy comunes en varias bases de datos. Si la expresión regular anterior solo detecta comillas simples u otros metacaracteres de SQL, deberá modificar aún más la consulta para detectar comillas simples y claves. también se puede ampliar aún más con otras palabras clave SQL, como 'seleccionar', 'insertar', 'actualizar', 'eliminar', etc.
2.4 Detección de inyección SQL, expresión regular de palabra clave de consulta UNION
/ ((%27)|(') )union/ix
(%27)|(') - comilla simple y su equivalente hexadecimal
union: la palabra clave union
también se puede utilizar para personalizar expresiones para otras consultas SQL, como >seleccionar, insertar, actualizar, eliminar, descartar, etc.
Si, en esta etapa, el atacante ha descubierto que la aplicación web tiene una inyección SQL vulnerabilidad, intentará aprovecharla. Si se da cuenta de que el servidor backend es un servidor MS SQL, normalmente intentará ejecutar algún almacenamiento peligroso y procedimientos almacenados extendidos. Estos procedimientos generalmente comienzan con las letras 'sp' o 'xp'. Normalmente, podría intentar ejecutar el procedimiento almacenado extendido 'xp_cmdshell' (que ejecuta comandos de Windows a través de SQL Server). La autoridad SA del servidor SQL tiene la autoridad para ejecutar estos comandos. De manera similar, pueden modificar el registro mediante xp_regread, xp_regwrite y otros procedimientos almacenados.
2.5 Explicación de la expresión regular
/exec(s|+)+(s|x)pw+/ix
para detectar ataques de inyección SQL de MS SQL Server:
exec: palabra clave que solicita la ejecución de un procedimiento almacenado almacenado o extendido
(s|+)+ - uno o más espacios en blanco o sus equivalentes http
(s|x) p- Las letras 'sp' o 'xp' se utilizan para identificar procedimientos de almacenamiento o almacenamiento extendido
w+: uno o más caracteres o guiones bajos para que coincidan con el nombre de un procedimiento
3. Expresión regular para secuencias de comandos entre sitios (CSS)
Al lanzar un ataque CSS o detectar una vulnerabilidad en un sitio web, un atacante puede crear primero una etiqueta HTML simple como < b> (negrita), <i> (cursiva) o <u> (subrayado), o podría probar con una etiqueta de script simple como <script>alerta("OK")</script> porque la mayoría de las publicaciones y Esto es. Se utiliza como ejemplo para detectar si un sitio web tiene vulnerabilidades CSS propagadas a través de Internet. Estos intentos se pueden detectar fácilmente. Sin embargo, un atacante inteligente podría reemplazar toda la cadena con su valor hexadecimal. De esta forma, la etiqueta <script> aparecerá como %3C%73%63%72%69%70%74%3E. Por otro lado, un atacante puede utilizar un servidor proxy web como Achilles para convertir automáticamente algunos caracteres especiales como < a %3C, > a %3E. Cuando se produce un ataque de este tipo, los corchetes angulares generalmente se reemplazan con valores hexadecimales. en la URL.
La siguiente expresión regular detectará cualquier texto que contenga <,> en html. Detectará intentos de utilizar <b>, <u> o <script>. Esta expresión regular debería ignorar mayúsculas y minúsculas. Necesitamos detectar tanto el corchete angular como su equivalente hexadecimal (% 3C|<). Para detectar toda la cadena convertida a hexadecimal, debemos detectar los números y signos % ingresados por el usuario, es decir, usar [a-z0-9%]. Esto puede provocar la aparición de algunos errores, pero no la mayoría detectará ataques reales.
3.1 Expresión regular para ataques CSS generales
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
explicar :
((%3C)|<) - comprueba < y su equivalente hexadecimal
((%2F)|/)* - etiqueta de cierre/ o su equivalente hexadecimal
[a-z0-9%]+ - Verifica la letra en la etiqueta o su equivalente hexadecimal
((%3E)|>) - Comprueba > o su
regla de Snort equivalente hexadecimal:
alerta tcp $EXTERNAL_NET cualquiera -> $HTTP_SERVERS $HTTP_PORTS (msg:"Intento de secuencias de comandos entre sitios NII"; flujo:al_servidor,establecido; pcre:"/((%3C)|<)((%2F)| /)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Las secuencias de comandos entre sitios también se pueden usado< img src=>Tecnología. Las actuales reglas predeterminadas sobre el snort se pueden eludir fácilmente.
La sección 3.2 proporciona métodos para prevenir esta técnica.
3.2 Expresión regular de ataque CSS "<img src"
/((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D) ) ((%67)|g|(%47))[^n]+((%3E)|>)/I
explicación:
(%3 C)|<) -<o su equivalente hexadecimal
(%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47) -'img' letra o it Combinaciones de variación de equivalentes hexadecimales en mayúsculas y minúsculas
[^n]+ - cualquier carácter después de <img excepto nueva línea
(%3E)|>) -> o su equivalente hexadecimal
3.3 Ataque CSS Expresión regular extrema
/((%3C)|<)[^n]+((%3E)|>) /I
Explicación:
Esto La regla simplemente busca <+cualquier carácter excepto un carácter de nueva línea+>. Dependiendo de la arquitectura de su servidor web y aplicación web, esta regla puede producir algunos errores. Pero está garantizado que detectará cualquier ataque tipo CCS o CSS.
Resumen:
en este artículo, propusimos diferentes tipos de reglas de expresión regular para detectar ataques de inyección SQL y secuencias de comandos entre sitios. Algunas reglas son simples y extremas, y un posible ataque hará sonar tu alarma. Pero estas reglas extremas pueden conducir a algunos errores proactivos. Con esto en mente, modificamos estas reglas simples para usar estilos adicionales para que puedan verificarse con mayor precisión. Al detectar ataques a estas aplicaciones de red, recomendamos utilizarlas como punto de partida para depurar su IDS o métodos de análisis de registros. Después de algunas revisiones más, debería estar listo para detectar esos ataques después de haber evaluado las respuestas no maliciosas a la parte de transacción normal de la red.
Referencia
1. Inyección SQL
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. Preguntas frecuentes sobre secuencias de comandos entre sitios http://www.cgisecurity.com/articles/xss -
faq.shtml
3. El Snort IDS http://www.snort.org
4. Expresiones regulares compatibles con Perl (pcre) http://www.pcre.org
5. Proxy de aplicación web, Achilles http://achilles.mavensecurity.com
3. Inyección SQL avanzada
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
7. CÓMO de programación segura, David Wheeler www.dwheeler.com
8. Amenazas y contramedidas, MSDN, Microsoft