Saturday 8 August 2015

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/importantes/5377/
TAGS: seguridad del sitio web, WordPress

Con la proliferación de Infraestructuras y Plataformas como proveedores de Servicios, no se extraña que, en la actualidad, la mayoría de los sitios web están alojados en lanube. Esto es muy bueno porque permite a organizaciones e a individuos instalar sus sitios web de forma rápida, con relativamente poca sobrecarga en sus propias infraestructuras/sistemas. Hay muchos atributos positivos asociados con el hospedaje en la nube, pero también hay limitaciones sobre todo cuando se trata de seguridad y lo que usted, como propietario de un sitio web, está autorizado a realizar (eso depende de su host y de las características que se las ha habilitado, aprenda más sobre cómo los hosts gestionan la seguridad de su sitio web).


Por ejemplo, eso se percibe a través de la retención y recogida de información vital en el formato de logs, específicamente los logs de auditoría/seguridad.


En los últimos meses, hemos compartido una serie de artículos sobre ¿cómo se hackean los sitios web? y sobre los impactos de estos hacks. El año pasado, pasamos algún tiempo diseccionando otro hack de WordPress, utilizando nuestro plugin de seguridad para WordPress gratuito. Hoy, quiero ahondar más en el mundo de Respuesta a Incidentes, específicamente en el análisis forense – o el arte de averiguar lo que pasó.


Con toda mi experiencia, puedo contar con una mano el número de sitios web/ambientes que se basan en una auditoría eficaz para sus diversas herramientas preventivas, tales como firewalls, sistemas de detección de intrusiones (Intrusion Detection Systems – IDS) y otros. En muchos casos, las herramientas están configuradas, pero los logs: a) no están siendo recogidos o b) se recogieron, pero no están siendo estudiados o analizados… En cualquier caso, se trata de una situación muy triste porque el impacto de la respuesta a incidentes es muy grande.


Afortunadamente, a menudo podemos contar con logs de acceso web. Utilizamos la expresión contar con de manera muy informal, ya que en la mayoría de los casos, no tenemos más de 24 horas en el mejor de los casos 7 días. Algunos dirían que esto es bueno, sin embargo, por lo que hacemos es simplemente correcto y, a menudo, no es suficiente para obtener todos los hechos del caso, pero es, sin duda, un buen comienzo. Si hay una cosa que usted debe saber acerca de mí es que me encantan los logs; de hecho, es por eso que he empezado el proyecto OSSEC hace muchos años y por eso os animo a todos a utilizarlo en sus redes como un sistema de detección de intrusiones en un Host (Host Intrusion Detection System – HIDS).



Acceso a Sitios Web, Logs y Forense – Entenda Cómo su Sitio Web fue Pirateado


A continuación se muestra una guía que espero que lo ayudará a entender y apreciar el impacto y la importancia de sus logs de acceso además, lo más importante, lo ayudará a comprender el significado de lo que está viendo.



Paso 1: Encuentre los logs de su sitio web


Antes de empezar, es necesario encontrar sus logs de acceso. Desafortunadamente, esto puede ser diferente para cada host, sin embargo, se supone que es la parte más fácil del proceso. Si no está seguro dónde se almacenan sus registros, por favor póngase en contacto con su host y ellos se los identificarán de forma rápida y le dirigirán a la dirección correcta. Las preguntas más importantes que debe hacer son:



  1. ¿Ustedes están recogiendo los logs de acceso para el tráfico que va a mi sitio web?

  2. ¿Si no,   pueden hacerlo?

  3. ¿Hace cuánto tiempo están recogiendo logs?

  4. ¿No tengo acceso a ellos?

  5. ¿Dónde encuéntrolos ?

Puesto que usted ya está hablando con su host, también pregúntaselo acerca de sus logs de FTP/SFTP.



Hosts Compartidos

Hosts compartidos pueden ser extremamente difíciles. Servidores basados en cPanel almacenan los logs dentro del directorio ~/access-log en su carpeta de inicio, sin embargo, algunos proveedores sólo almacenan los logs por 24 horas.


Si visita el directorio ~/access-log, verá los archivos access-log y error-log. Si hay sólo un archivo allá, es probable que su host guarda logs sólo por 1 día.


Si hay muchos archivos compactados (gzip), eso significa que usted tiene más días de logs disponibles.



VPS o Servidores Dedicados

A menudo es mucho más facil trabajar com ellos, ya que sus configuraciones Linux por defecto guardan los logs por más tiempo, sin embargo, ni todos los hosts son iguales. Si usted va para /var/log/httpd (o /var/log/nginx o /var/log/apache), puede encontrar logs de por lo menos 7-10 días.


Espero que esos datos sean suficientes para entender lo que pasó.



Paso 2: Comprenda los logs


Ahora ya tiene sus registros y ya los ha descargado, ¡esa es una gran noticia! Ahora tenemos que averiguar lo que ellos significan. Les recomiendo almacenarlos en un lugar separado para que pueda hacer su análisis sin molestar a su servidor, ya que incluso los administradores de sistemas más experimentados pueden cometer errores.


El paso siguiente es entender cómo se ven sus logs. La mayoría de los servidores web, incluyendo Apache y Nginx almacenan sus logs en formato de log común, también conocido como el formato de log común NCSA que se divide en pocas partes:



IP_ADDRESS - - [Date_Time Timezone] "HTTPMETHOD /URL HTTP_VERSION" HTTP_RESPONSE_CODE HTTP_LENGHT "REFERER" "USER AGENT"

Eso le dará casi todas las informaciones que usted necesita sobre los pedidos para su sitio web, incluyendo, la procedencia (IP_ADDRESS), la hora e data, la URL, el tamaño, el navegador y cómo su servidor ha respondido (HTTP_RESPONSE_CODE).


Es un tipo de log muy usual y muy facil de comprender y sintetizar.


Vamos a ver el ejemplo a seguir:



66.249.75.219 - - [30/Jun/2015:09:17:42 -0400] "GET / HTTP/1.1" 200 255 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Podemos ver que la dirección IP 66.249.75.219 de Google visitó la URL “/” a las 9 de la mañana en 30 de junio de 2015. El servidor devolvió un “200” (éxito), es decir, la página existe y no hay errores se generaron en el petición.


Si usted no está familiarizado con este formato de logs, le recomiendo pasar algún tiempo leyendo esta gran introducción sobre los diferentes formatos de logs. También recomiendo mirar sus logs más a menudo, ya que pueden proporcionar una gran cantidad de visibilidad a lo que está sucediendo con su sitio web.



Paso 3: Analice sus Logs


¿Ha encontrado sus logs y comprendido cómo ellos se parecen, perfecto!


La pregunta ahora es, ¿cómo entender todos los datos? Esto es especialmente preocupante porque, a diferencia del ejemplo anterior donde teníamos una línea de logs, si abre el archivo de logs es probable que encontre miles de ellos e incluso millones de solicitudes en un archivo. Esto es suficiente para disuadir incluso los más poderosos analistas forenses. Por lo tanto, tenemos que aprender a analizar los datos para encontrar la información que necesitamos de forma procesable.


Tenemos que mirar para el caso, eliminar el ruido y tratar de identificar los parceros que nos darán una pista sobre lo que pasó.


Restrinja


Debido al ruido, tenemos que filtrar todas las cosas que no se aplican. Independientemente de lo que pensamos, casi todos sitios web tienen un patrón similar que puede ayudarlo a construir un perfil de lo que se puede ignorar y de lo que se debe mirar.


Por ejemplo, las aplicaciones para “/”, o la parte superior de la página. Es probable que todos los visitantes pasan allí, y cuanto más tráfico tiene, encontrará más de estas líneas en sus logs. Así que queremos descartar este tipo de cosas, o archivos CSS o JS que son cargados a cada solicitud. Todo esto es, en la mayoría de los casos, el ruido y es bastante fácil filtrarlo. Si usted es un geek de terminal, puede utilizar comandos comogrep para ver sus logs, eliminando estas entradas innecesarias:



$ cat access-log |grep -Ev "\.(js|css|png|jpg|jpeg) HTTP/1"| more

En el ejemplo anterior, se descartó todo tipo de archivos .js, .css, .png, .jpg y .jpeg. En un sitio medio, se reducirá más del 60% el número de líneas que deben ser inspeccionadas. También puede descartar visitas sencillas a sus páginas principales, lo que reducirá más del 80% el número de líneas:



$ cat access-log |grep -Ev "\.(js|css|png|jpg|jpeg) HTTP/1" |grep -Ev " GET (/|/contact|/signup) HTTP/1"| more


En este ejemplo, ignoré las peticiones “/” , las páginas /contact y /signup. Dependiendo de su sitio web, usted pasará sólo unos pocos cientos de líneas de registro, sin duda mucho mejor que lo que originalmente empezamos.


Si por alguna razón usted todavía tiene miles de aplicaciones, por lo que quiere empezar a hacer algunas suposiciones y ajustar sus filtros. Lo mejor es filtrar las solicitudes de ciertas actividades que sabe que merece inspección, inclusive:



  1. Peticiones POST.

  2. Peticiones para páginas admin.

  3. Peticiones para localizaciones no estándar.

Eso se hace fácilmente, cambiando el comando grep para mostrar apenas peticiones para “wp-admin|wp-login|POST /”:



$ cat access-log |grep -E "wp-admin|wp-login|POST /" | more

Eso generalmente disminuye el número de líneas por 1/200, haciendo que sea mucho más fácil analizarlas. Si conoce a las direcciones IP de los administradores del sitio web, puede eliminarlas, así (se utilizó 1.2.3.4 y 1.2.3.5 como ejemplos):



$ cat access-log |grep -E "wp-admin|wp-login|POST /" |grep -v "^1.2.3.4|1.2.3.5" | more

Un Ejemplo del Mundo Real


Ya hemos compartido algunos pasos para ayudarlo a entender y analizar sus datos. Sin embargo, ¿cómo aplicamos y aclaramos este proceso?


Queremos compartir con ustedes un ejercicio reciente que tenía que ver con uno de nuestros clientes. El cliente estaba usando WordPress, ha sido comprometido y tenía la misma pregunta que todo el mundo tiene; ¿Cómo me han hackeado? Lo siguiente será probablemente un poco más técnico y requiere un cierto conocimiento de línea de comandos, pero no debería ser difícil para las personas más técnicas. Para las que no lo son, no se preocupen porque estamos aquí.


Lo primero que hicimos fue agregar todos los registros en un archivo, para nuestra salud mental:



# cat /var/log/httpd/*.access.log* > /tmp/all-logs
$ wc -l /tmp/all-logs
1071201

Esto hizo 1.071.201 líneas de registros, como se muestra por wc; lo que significa que tendríamos que aprovechar los trucos de análisis de arriba para terminar de analizarlas antes de Navidad.


En primer lugar, buscamos peticiones POST a wp-login:



$ cat /tmp/all-logs |grep wp-login|grep "POST /" |grep -v "^CLIENTIP"
188.163.91.92 - - [24/Jun/2015:14:00:40 -0500] "POST /wp-login.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:15.0) Gecko/20121011 Firefox/15.0.2"

Retiramos nuestra dirección IP del cliente y los resultados fueron en realidad una sola línea de log de 188.163.91.92 (una dirección IP ucraniana).



$ whois 188.163.91.92
route: 188.163.64.0/18
descr: Kyivstar GSM, Kiev, Ukraine
origin: AS15895
mnt-by: KYIVSTAR-MNT

Naturalmente, podría haber sido un falso positivo o un intento de ataque de fuerza bruta, pero si el usuario visitó wp-admin después de la wp-login, significa que su ingreso tuvo éxito:



$ cat /tmp/all-logs |grep ^188.163.91.92 |grep wp-admin | head -n 3
188.163.91.92 - - [24/Jun/2015:14:00:41 -0500] "GET /wp-admin/ HTTP/1.1" 200 49913 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:15.0) Gecko/20121011 Firefox/15.0.2"
188.163.91.92 - - [24/Jun/2015:14:00:44 -0500] "GET /wp-admin/ HTTP/1.1" 200 49913 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:15.0) Gecko/20121011 Firefox/15.0.2"
188.163.91.92 - - [24/Jun/2015:14:00:45 -0500] "GET /wp-admin/theme-editor.php HTTP/1.1" 200 49286 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:15.0) Gecko/20121011 Firefox/15.0.2"

¡Espera un ratito! Creo que he encontrado algo aquí. Esta IP de Ucrania en realidad accedió a la wp-admin después de haber hecho el log in y se dirigió directamente aleditor de temas. Esa es una gran bandera roja para nosotros y es un claro indicador de que vale la pena prestar atención a ella, especialmente debido a que el propietario del sitio web vive en los EE.UU. y no tiene trabajadores a distancia. Necesitamos investigar más profundamente. Ahora podemos mezclar nuestra grep con el comandocut para ver de una manera más fácil cada URL visitada por esta IP:



$ cat /tmp/all-logs |grep ^188.163.91.92 | cut -d " " -f 1,6,7
188.163.91.92 "GET /wp-login.php
188.163.91.92 "GET /wp-login.php
188.163.91.92 "POST /wp-login.php
188.163.91.92 "GET /wp-admin/
188.163.91.92 "GET /wp-admin/
188.163.91.92 "GET /wp-admin/theme-editor.php
188.163.91.92 "GET /wp-admin/theme-editor.php?file=404.php&theme=aphrodite
188.163.91.92 "POST /wp-admin/theme-editor.php
188.163.91.92 "GET /theme-editor.php?file=404.php&theme=aphrodite&scrollto=0&updated=true
188.163.91.92 "POST /wp-content/themes/aphrodite/404.php
188.163.91.92 "GET /wp-content/themes/aphrodite/was-wp.php
188.163.91.92 "GET /wp-admin/theme-editor.php
188.163.91.92 "GET /wp-admin/theme-editor.php?file=404.php&theme=aphrodite
188.163.91.92 "POST /wp-admin/theme-editor.php
188.163.91.92 "GET /wp-content/themes/was-wp.php
188.163.91.92 "GET /wp-admin/plugin-install.php?tab=upload
188.163.91.92 "POST /wp-admin/update.php?action=upload-plugin
188.163.91.92 "GET /wp-content/uploads/2015/06/maink.php
188.163.91.92 "POST /wp-content/uploads/2015/06/maink.php
188.163.91.92 "POST /wp-content/uploads/2015/06/maink.php
188.163.91.92 "GET /wp-content/uploads/was-wp.php

Dios mío, ¿ve la línea de tiempo de los acontecimientos?


El atacante inició sesión en el sitio web a través de wp-login, fue al editor de temas y modificó el archivo 404.php:



188.163.91.92 "GET /theme-editor.php?file=404.php&theme=aphrodite&scrollto=0&updated=true

Después de eso, él visitó el archivo 404 directamente:



188.163.91.92 "POST /wp-content/themes/aphrodite/404.php

Es, probablemente, un backdoor PHP (y era). Utilizó este archivo para crear otra puerta trasera was-wp.php, y se puede ver que la visitó más tarde también. Otro ejemplo de cómo un atacante no sólo afecta al medio ambiente, pero luego hace de todo para mantener el acceso, controlar el sitio web y asegurarse que si se actualiza los controles de acceso, todavía él puede mantenerlo.


Con eso, teníamos información suficiente para decir con un alto grado de confianza que se fraudaron el nombre de usuario y la contraseña de los clientes, dando al atacante lo que necesitaba. El atacante entonces utilizó su editor de temas para modificar archivos, lo que permitió la inyección de puertas traseras, lo que le dio el control total incluso después de se actualizar las credenciales.


Lo que estos logs no muestran, sin embargo, es cómo consiguieron la contraseña. De nuevo lo observamos al cabo de unos días, y vimos constantes intentos de acceso al medio ambiente, pero es difícil decir si esto era la causa o no, o si el atacante tuvo sólo suerte.


Espero que este post le dará una visualización inicial y sencilla de lo que es el mundo de la ciencia forense y lo que se necesita. Esto no debe confundirse con la atribución, sin embargo, que con la identificación del mundo de la identificación de QUIÉN lo hackeó. Este es un proceso completamente diferente.


Utilizamos WordPress como ejemplo anteriormente, pero se puede aplicar todo eso a otras tecnologías de sitios web.


Fuente:https://blog.sucuri.net


Noticias de seguridad informática
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)