Tengo algunos servidores Linux, que por lo que puedo decir no son vulnerables al vector de ataque de shellshock, pero tengo curiosidad por el aspecto del ataque en los registros. ¿Cómo se ve un ataque exitoso en los registros de appache2? ¿Cómo se vería un ataque exitoso en el registro del sistema?
¿Cómo se ven los intentos fallidos? Me gustaría ampliar mi lista negra para los ataques tipo shell-shock.
Esta es una entrada de mi access_log de lo que mi compañero de trabajo hizo a mi máquina de prueba ...:
10.11.12.13 - - [25/Sep/2014:16:00:00 -0400] "GET /cgi-bin/testing.cgi HTTP/1.0" 200 1 "-" "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/rm -rf /var/www/"
En mi registro de errores vi mucho de esto:
[Thu Sep 25 16:00:00 2014] [error] [client 10.11.12.13] /bin/rm: cannot remove '/var/www/icons/pie0.png': Permission denied
Bastardo :-)
Un servidor web bien configurado no podrá sobrescribir sus registros, y en todos los entornos, excepto en los más pequeños, debería usar el registro centralizado para evitar que pierda este tipo de entradas de registro.
Si es explotado con éxito, puede ver muchos errores en el error_log que muestra intentos fallidos de acceder a recursos, ejecutar programas o eliminar archivos. Si aumentan los privilegios con éxito y no tiene un registro externo, es posible que no vea ninguna evidencia.
Si tiene un servidor web Apache con una configuración estándar y un script cgi que utiliza bash, la entrada de registro para una solicitud puede parecer idéntica en los siguientes tres casos:
bash que deshabilita la función vulnerable. La única diferencia necesaria para convertir una solicitud legítima en un ataque es la modificación de uno de los encabezados de solicitud, que se coloca en una variable de entorno.
Si el encabezado User-agent se usa para realizar el ataque, será bastante visible en el registro de acceso de registro, ya que ese encabezado se registra. Pero hay otros encabezados que se pueden usar para realizar el ataque, que no se registran de forma predeterminada.
Si un intento de ataque falló debido a que bash se actualizó a la versión intermedia que corrigió el error pero aún permitía que las funciones se especificaran a través del entorno, vería advertencias en el registro de errores. Pueden verse así:
[Thu Sep 25 20:46:51.483207 2014] [cgi:error] [pid 26424] [client 10.82.90.125:55631] AH01215: /bin/bash: warning: HTTP_ACCEPT_LANGUAGE: ignoring function definition attempt
[Thu Sep 25 20:46:51.483316 2014] [cgi:error] [pid 26424] [client 10.82.90.125:55631] AH01215: /bin/bash: error importing function definition for 'HTTP_ACCEPT_LANGUAGE'
La mayoría de las cosas que podrías notar en este momento son las sondas, el escaneo de servidores aleatorios en busca de posibles vectores de ataque, por lo que se recomienda parchear.
Un posible "ataque" o, al menos, una comprobación podría verse un poco así:
egrep "};|}\s*;" /var/www/logs/access* xxx.xxx.xxx.xxx - -
[25/Sep/2014:12:12:12 +0100] "GET /cgi-sys/defaultwebpage.cgi
HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 xxx.xxx.xxx.xxx"
Donde xxx.xxx.xxx.xxx es la dirección IP.
Hace poco vi el CISO de Mandiant, dijo que cuando se le pregunta si siempre hay un patrón de comportamiento que distingue a un atacante (malware) de una actividad válida, responde que si el atacante se comportó exactamente igual que un trabajador válido Debemos agradecerles por hacer un trabajo gratis para nosotros. Claramente, el atacante se comportará de manera diferente de un trabajador válido. Esto implica que si supervisamos el comportamiento / actividad en un sistema, deberíamos poder detectar si se ha producido alguna actividad maliciosa. Desafortunadamente, los registros del sistema pueden ser manipulados por un atacante avanzado, así como el envío a syslog y todos los métodos habituales, debe controlar todo el comportamiento del sistema de alguna manera para buscar anomolías en lugar de solo raspar un registro. Disculpe si esta es una respuesta inconveniente, pero las APT son algo inconvenientes ... Aprecio que esta publicación no responda realmente a la pregunta original publicada y, por lo tanto, no sea 100% útil, pero quiero que la gente recuerde que no se centre demasiado en un tema específico. registre la entrada y no olvide monitorear / analizar el comportamiento general también
Lea otras preguntas en las etiquetas vulnerability bash shellshock logging