En este artículo quise demostrar algunos de los ataques que detecta y reporta logwatch a diario, de acuerdo a la información que recoge de los logs de accesos y errores del servidor Nginx, junto con un uso insospechado que recientemente encontré al mismo.

Logwatch es una herramienta indispensable en todos mis servidores. Es la que me permite tener una visión general de la actividad de cada servidor a lo largo del día. Y es la que, junto con AIDE, me permite detectar cualquier actividad sospechosa en los procesos y el filesystem.

Este es otro artículo para generar conciencia respecto a la seguridad de la información, y los peligros que supone poner un servicio a disposición de Internet (en este caso, un sitio Web). Es común que muchos administradores novatos o negligentes se inclinen hacia razonamientos del tipo "a mi no me va a pasar", "quién va a querer atacar mi servidor", u otros similares. Este tipo de argumentos son desacertados porque asumen intencionalidad. Es decir asumen que van a ser víctimas de ataques cuando un individuo quiera provocar específicamente un daño a la reputación de nuestra marca/empresa/cliente/servidor. Tal aseveración es falsa y la realidad es que, en la mayoría de los casos, los atacantes no buscan un daño o prejuicio, sino que simplemente buscan agregar un nodo más a una botnet, sin dejar el más mínimo rastro o daño que los pueda poner en evidencia. Y más aún, la mayoría de los ataques no son dirigidos específicamente a un sitio o servidor, sino que son "al voleo" y con herramientas automáticas. Y en muchos casos llevados a cabo por robots. A quién atacan luego con la botnet, vaya uno a saber. Lo importante es que sea lo más grande posible (en cantidad de nodos o bots).

En definitiva, cuando uno pone a disposición un servicio accesible públicamente, tarde o temprano será atacado. Pues los robots barren constantemente las redes IPv4 e IPv6 en búsqueda de nuevos hosts y puertos abiertos.

Este es un resumen de las URLs más interesantes que fue reportando Logwatch en este servidor a lo largo de unos días.

Information disclosure

Information disclosure es el caso en el que un atacante gana información valiosa acerca de un sistema. En estos accesos, los atacantes están tratando de obtener URLs relacionadas a recursos de alguna manera "ocultos" para los buscadores:

/google_matched_content_blacklist.txt
/google_matched_content_rules.xml
/google_matched_content_whitelist.txt
/robots.txt 

Reconocimiento de frameworks

En estos accesos se observa que los atacantes intentan reconocer qué versión de framework o CMS utiliza el sitio, para luego probar una batería de exploits a vulnerabilidades conocidas.

/assets/
/help.txt
/readme.htm
/readme.html
/readme.txt

¿Adivinen quién deja archivos readme.txt desparramados por todo el sitio? Sí, adivinaron: Wordpress.

Intentos de acceso a paneles de administración

En estos accesos los atacantes intentan encontrar puntos de ingreso a paneles de administración:

//adm.php
/admin.php

Ataques desconocidos (para mí)

En estos accesos hay una mezcla de intentos de inyección de código, mezclado con codificación de caracteres y otras yerbas:

/templates/linuxito/css/linuxito.woff)%20format(%22woff%22
/download/yQ2kCMRGthzgO4e
/DATADATADATA
\x09\x19\xFC\x9Ce\xD3P\xFF\x97\xDC\xD4O\x9 ... 6>\x86\xFA\x90O
mstshash=eltons

Búsqueda de scripts inseguros

En esta batería de accesos los atacantes intentan encontrar scripts PHP vulnerables o inseguros, o simplemente listar todos los scripts PHP para ampliar la superficie de ataque.

/xmlrpc.php
/ajax.php
/alias.php
/article.php
/blog.php
/cache.php
/code.php 
/config.php
/css.php
/defines.php
/diff.php
/dir.php
/dirs.php
/infos.php
/dump.php
/error.php
/file.php
/files.php
/footer.php
/functions.php
/gallery.php
/general.php
/global.php 
/header.php
/help.php 
/inc.php
/include.php
/info.php
/ini.php
/javascript.php
/lib.php
/list.php
/login.php
/menu.php
/model.php
/object.php
/option.php
/options.php
/page.php
/plugin.php
/press.php
/proxy.php
/search.php
/session.php
/sql.php
/start.php
/stats.php
/system.php
/template.php
/test.php
/themes.php
/title.php
/user.php
/utf.php
/view.php
/xml.php

Llama especialmente la atención el acceso a xmlrpc.php. ¿Adivinen quien usa RPC para ejecutar funciones de forma remota? Sí, adivinaron: Wordpress.

Path traversal/LFI

Los ataques path traversal intentan atravesar la jerarquía de directorios del servidor para acceder a archivos sensibles del servidor, localizados fuera de la raíz del sitio Web.

/\.\./\.\./\.\./
/../../../media/jui/fonts/IcoMoon.eot
/../../../media/jui/fonts/IcoMoon.eot?
/../../../media/jui/fonts/IcoMoon.woff
/../../../media/jui/fonts/IcoMoon.eot
/../../../media/jui/fonts/IcoMoon.eot?
/../../../media/jui/fonts/IcoMoon.woff
/../images/comment_grey.png

Vulnerabilidades de componentes de terceros de Joomla!

En Joomla!, la mayoría de los exploits y vulnerabilidades de seguridad ocurren en componentes de terceros. Es indispensable mantener al mínimo el uso de componentes de terceros y estar suscripto a la VEL para evitar riesgos.

/index.php?option=com_easyblog&view=dashboard&layout=write
//index.php?option=com_jdownloads&Itemid=0&view=upload

Búsqueda de configuraciones inseguras de Joomla!

En estos accesos intentan vulnerar la instalación de Joomla! y explotar scripts inseguros:

/index.php/component/users/?task=user.register
/.index.php?xo=echo(base64_decode('YWR6b250aWxvc2E='));
/install/index.php.bak?step=11&insLockfile ... nfig_update.php 
/index.php/component/users/

Para minimizar riesgos es necesario revisar la Security Checklist de configuración de Joomla!.

Intentos de acceso a archivos de Let's Encrypt

Este es otro intento de information leak, pero decidí clasificarlo aparte ya que apunta específicamente a Let's Encrypt. Es interesante ver lo rápido que surgen los ataques a nuevas tecnologías.

/.well-known/assetlinks.json

Intentos de acceso a Wordpress

Aburren. Por eso decidí bloquearlos con GTFO, el cual me ha dado un excelente resultado hasta el momento.

/wp-login.php
/seguridad/wp-admin/admin-ajax.php?action= ... ./wp-config.php
/seguridad/wp-login.php
/wp-admin/admin-ajax.php?action=revslider_ ... ./wp-config.php
/wordpress/
/wp/
/gnu-linux/wp-login.php
/seguridad/wp-login.php
/wp-admin/css/colors-classic.css
/wp-admin/images/wp-logo-2x.png
/wp-admin/js/media-upload.dev.js
/wp-content/plugins/akismet/akismet.js
/wp-content/themes/classic/rtl.css
/wp-content/themes/twentyeleven/readme.txt
/wp-content/themes/twentyten/images/wordpress.png
/wp-content/themes/twentyten/style.css
/wp-includes/css/buttons.css
/wp-includes/js/scriptaculous/wp-scriptaculous.js
/wp-includes/js/tinymce/langs/wp-langs-en.js
/wp-includes/js/tinymce/wp-tinymce.js
/wp-cache.php
/wp-content/plugins/myshe.php
/wp-content/plugins/wp-cache.php
/wp-main.php
/wp/wp-login.php 
/wp-content/themes/mTheme-Unus/css/css.php?files=../../../../wp-config.php

Intentos de acceso al panel de administración, intentos de inyección, path traversal, etc. De todo un poco. Es evidente que Wordpress es muy inseguro y está plagado de vulnerabilidades a lo largo de todas sus versiones. La mayoría de los ataques y escaneos a este sitio están dirigidos a Wordpress. Lógicamente los atacantes prueban todos los ataques existentes, porque en, lamentablemente muchos, casos los administradores no actualizan su/s instalación/es de Wordpress.

Búsqueda de archivos con información sensible

/license.txt
/fullchain.pem.

¿En serio hay gente que deja un certificado en la raíz del sitio? Es más, por el nombre de archivo ("fullchain") se trata de la cadena completa con clave privada incluida, CA y certificados root. SEs evidente que si los lammers lo buscan, es porque mucha gente lo hace, lo cual es terrible X(

El acceso a license.txt tal vez sea parte de un intento de reconocimiento de framework/CMS. Aunque no me extrañaría que pueda tratarse de la licencia de algún producto propietario. No dejar ningún archivo o información confidencial en ningún directorio de un sitio Web. Ni aunque se trate de un directorio protegido con contraseña, pues puede ser vulnerado con un ataque de path traversal.

Detección de protocolos, configuraciones y componentes inseguros

Finalmente intentos de detección de configuraciones inseguras y directorios desprotegidos:

/forum/
/ftp/
/webdav/
/doc/
/docs/
/document/
/documents/
/download/
/downloads/
/dwg/
/feed/
/files/
/reports/
/upload/
/uploads/
/work/

Otro uso insospechado para Logwatch

Estos días el jefe pidió una proyección de uso de disco a lo largo de todo el año para uno de nuestros sistemas con mayor volumen de datos, con el objetivo de justificar una inversión en storage. Vaya problema. ¿De dónde saco esa información? ¿Cómo sé cuánto espacio en disco consumía hace un año, en noviembre de 2015?

Y aquí es donde llega Logwatch a salvar el día:

Por defecto, Logwatch agrega, al final de cada reporte, el detalle de uso de disco actual. De esta forma podemos proyectar con exactitud cómo evolucionó día a día el uso de espacio en cada sistema de archivos. Brillante. Por supuesto, siempre que no hayamos borrado los correos (absurda práctica esa de borrar correos electrónicos, por más triviales que sean, son una excelente herramienta para ubicarnos temporalmente y responder muchas preguntas sobre nuestro pasado, aunque parezca increíble).

Gracias a Logwatch pude obtener tan valiosa información, que de otra forma no sé cómo hubiera podido saber. Tal vez hubiera podido obtener esta información desde el hipervisor, pero no con ese nivel de detalle.

Conclusiones

Esto es sólo una muestra de apenas algunas URLs a lo largo de un puñado de días. Mantengan sus servidores, plataformas, protocolos y servicios asegurados y protegidos, suscríbanse a listas de correo de seguridad, instalen Logwatch y AIDE, y por qué no implementen algún mecanismo de seguridad proactivo como mod_security o GTFO.


Tal vez pueda interesarte


Compartí este artículo