2017-07-13

Que pasa cuando las Funcionalidades son más complejas que los modelos de Seguridad #WordPress

El día de hoy voy a tratar de dar un punto de vista a una de las noticias más comentadas de la semana pasada como fué los más de 300.000 sitios vulnerables por un fallo de seguridad en un Plugins de WordPress.

Figura 1: Que pasa cuando las funcionalidades som más complejas que los modelos de Seguridad

La situación para llegar a este punto es más compleja y hasta quizás más profunda de analizar, pero voy a tratar de hacer un resúmen no solo de lo que pasó, sino también como podemos estar un poco más alerta.

A fines del mes de Junio, el equipo de investigadores de Sucuri, descubre y publica un fallo de seguridad, en la que afectar a un Plugin de WordPress llamado WP Statistics en su versión 12.0.8

Al parecer, según la publicación escrita por Sucuri, es posible llevar adelante un ataque por medio de una vulnerabilidad SQL Injection en uno de los parámetros no controlado por el desarrollador del Plugin.

Como siempre, hay que reconocer el excelente trabajo de Sucuri, al informar y alertar sobre los posibles problemas a quienes están a cargo del desarrollo de éste Plugin, ya que corresponde sin duda una gran responsabilidad.

Para hacer un poco de memoria, afortunadamente, hoy contamos con bases de datos de vulnerabilidades como WPScan Vulnerability Database donde podemos encontrar estos datos:

Figura 2: WPScan Vulnerability Database

Estos datos tienen que ser una fuente importante al momento de decidir si un Plugin va a pertenecer o no a un Proyecto de WordPress.

Otra fuente importante es el archivo ChangeLog que incorpora el Plugin de forma obligatoria, donde allí es posible seguir la evolución el proyecto y algunos detalles más.

Con esto no vamos a decir que WP Statistics no es un buen Plugin, sino que el analista o la persona que está a cargo de llevar adelante la implementación de WordPress tiene que conocer estos datos y el antecedente de cada componente dentro del proyecto.

Ésto es algo implícito que se sabe al momento de instalar WordPress o cualquier CMS como Joomla!, Drupal, PrestaShop, etc, donde por ninguna razón se garantiza la seguridad del proyecto.

Otro punto que se descuida son las actualizaciones, o lo que se vió en muchos casos luego de esta noticia, es que en muchos proyecto se desactivó el plugin para dejar de trackear la información pero dejaron el directorio del Plugin sobre el servidor, que a nivel técnico es posible seguir comprometiendo.

¿Esto se podría haber evitado?


Puede que si o puede que no, la realidad es que hoy fue un Plugin muy popular donde era de esperar que el impacto sea muy grande, mañana el problema puede estar en otro Plugin, en una librería o incluso sobre el mismo core de WordPress.

Lo más importante que tenemos que entender es que las funcionalidades no tiene que ser más complejas o sobrepasar las medidas de seguridad, de lo contrario no estaremos haciendo un buen trabajo al mantener la seguridad de WordPress.

En el ecosistema de WordPress es muy importante estar dispuesto a mantener una actualización en cada uno de los componentes importantes. WordPress es un gran proyecto que mantiene a sus usuarios acostumbrados a publicar varias actualizaciones por cada versión.

Si a priori sabemos que los componentes a lo largo del tiempo se van a actualizar, lo mejor que podemos hacer es redactar y poner en práctica como es la forma que vamos a actuar al momento que esto ocurra, cuáles van a ser los procedimientos que se van a ejecutar cuando ocurra X o Y evento.

De esta manera, cuando ocurra este tipo de publicaciones, rápidamente vamos a saber como actuar, e independientemente del valor de proyectos comprometidos, vamos a saber como actuar en el momento indicado.

Para conocer como adoptar nuevos hábitos de seguridad y poder llevar a otro nivel la fortificación de sus proyectos en WordPress, junto a los chicos de la editorial 0xWORD publicamos "Máxima Seguridad en WordPress".

Figura 3: Máxima Seguridad en WordPress

Saludos!

2017-06-22

2 herramientas para generar reportes en #SQUID

Una de las tareas principales de los administradores de red es tomar el control de todos y cada uno de los recursos, como así también optimizar los servicios brindados.

Figura 1: 2 herramientas para generar reportes en SQUID

Para mejorar el rendimiento y la experiencia de navegación suelo utilizar un servicio de Proxy llamado SQUID como así también para generar políticas de navegación gracias a sus ACL, aceleración en las consultas y control de ancho de banda por medio de sus delay_pools.

2 herramientas para generar reportes en SQUID


1) SARG - Squid Analysis Report Generator: Es una herramienta indispensable para mantener el control detallada de la actividad de cada usuario dentro de su navegación a Internet, por otro lado permite estimar la cantidad acumulada de recursos consumidos y todo por medio de un reporte web muy intuitivo.

Figura 2: SARG

En todo momento, gracias SARG es posible visualizar el TOP de sitios medido por la cantidad de request solicitados, los dominios que ingresó cada usuario, Descargas, accesos denegados por alguna ACL y fallos en la autenticación.

Como instalar SARG


Para poder instalar el generador de reportes SARG simplemente es necesario ejecutar en los sistemas Debian:

$ apt-get install sarg

Si todo finalizó correctamente, pueden editar su archivo de configuraciones alojado en /etc/sarg/sarg.conf donde desde allí van a poder ajustar algunos parámetros.

2) Calamaris - Se trata de otro generador de reportes, escrito en el lenguaje Perl5 y al igual que SARG, en sus reportes utiliza como input el archivo log que genera el servicio de SQUID.

Figura 3: Calamaris

En lo personal utilizo calamaris no tanto desde el cron de GNU/Linux, sino en determinados periodos para conocer de forma rápido valores como el funcionamiento del cache, y la forma en la que está trabajando, los tiempos en sobrecarga del servidor y la cantidad de request.

Además de un resumen, calamaris les puede mostrar más de 15 categorías de información, como los protocolos más usados, dominios más consultados, funcionamiento del caché, extensiones de archivos descargados, etc.

De no ser configurado correctamente, es posible encontrar algunos Dorks en Google.

Como instalar calamaris


Para instalar calamaris en sistemas basados en Debian, pueden ejecutar:

$ apt-get install calamaris

Y para comenzar a probarlo, los invito a que ejecuten la siguiente secuencia de comandos.

$ cat /var/log/squid3/access.log | calamaris -a | less

Suponiendo que el archivo access.log se encuentra en el PATH mencionado para el ejemplo.

Ya sea que necesitemos información de una herramienta específica o haciendo uso de más recursos, la idea de generar reportes no solo es un beneficio para conocer como responde el servicio al esquema de la red, sino también para depurar errores, ACL, y saber con precisión datos tales como, la cantidad de usuarios detrás de nuestro proxy, el consumo diario promedio de los usuarios y el rendimiento de nuestro servicio Proxy en la red.

A poner en práctica estas herramientas, y me gustaría que dejen en sus comentarios más herramientas que utilizan para conocer la salud de sus implementaciones de Squid.

Saludos!

2017-06-19

WebApp Information Gatherer con #wig

Hoy les quería compartir una de esas herramientas geniales para iniciar los procesos de Pentesting y específicamente en su primera etapa que es la recolección de información.

Figura 1: WebApp Information Gatherer con wig

Se trata de wig - WebApp Information Gatherer, una herramienta escrita en Python3 para la línea de comandos que permite recopilar información de aplicaciones webs y de numerosos CMS tales como WordPress, Joomla!, Drupal, Magento, PHPbb, phpMyAdmin, entre los más populares.

Con un dato un poco más técnico, wig utiliza una base de inferencia por ejemplo de firmas md5, expresiones regulares, cabeceras, etc para determinar algunas versiones específicas de alguno de los productos mencionados.

Figura 2: Firmas md5 en la base de conocimiento de wig

De esta manera, wig tiene como objetivo buscar y exponer la mayor cantidad de información posible, como tecnologías que se utilizan en un determinado proyecto web, subdominios encontrados para el dominio especificado en el escaneo, archivos y directorios interesantes y por supuesto enlaces a las vulnerabilidades detectadas.

Por otro lado, wig permite brindar recomendaciones sobre otras herramienta que se podría utilizar para obtener más información una vez detectado algún producto.

Para obtener wig, es posible clonar su repositorio a su ordenador local de la siguiente manera:

$ git clone https://github.com/jekyc/wig.git

Para comprender y ver una demo de como wig nos puede ayudar en nuestras auditorías, les comparto un pequeño video.


Saludos!

Enlace | wig - WebApp Information Gatherer en GitHub

2017-06-06

Como redimensionar un disco virtual #KVM

Desde hace tiempo estoy trabajando a diario con servidores virtuales, particularmente con esquemas qemu-kvm pese a que en varias oportunidades he tenido la suerte de probar otros hipervisores tales como Hyper-V, VMWare y VirtualBox.

Figura 1: Como redimensionar un disco virtual #KVM

Aún recuerdo cuando comencé a utilizar infraestructura de virtualización, realizar todas las operaciones en servidores virtuales sobre un mismo dispositivo físico es genial, por que uno logra una abstracción al hardware realmente muy interesante sin perder performance y escalando rápidamente.

Sin embargo, esta semana me tocó volver a los libros y realizar una tarea que resultó ser más interesante de lo que pensaba y se basaba en la siguiente ejemplo.

Sobre un servidor virtual ya creado, se estaba quedando ajustado de espacio físico en su disco virutal, por ejemplo un disco virtual de 40GB en un formato qcow2 llamado "servidor-0010.qcow2".

Sea por las razones que fueran, el disco ya estaba casi completo, por lo que el objetivo era aprovechar el potencial de la virtualización, agrandar el disco virtual por lo menos al doble y finalmente hacer que el sistema operativo lo reconozca.

Otra de las opciones interesante de la virtualización, es tener la posibilidad de montar escenario de pruebas, a partir de un respaldo anterior, jugar y romperlo hasta que se cumpla la tarea. Claro que no voy a comentar mucho las veces que "rompí" máquinas virtuales, sino mejor entrar en los detalles de la solución.

Lo primero que les recomiendo es trabajar con el servidor virtual apagado, para evitar corromper el sistema de archivos o algo, por lo cuál lo más probable es que este tipo de tareas lo llevemos adelante en un stop programado con poca carga en ese servidor.

$ virsh shutdown servidor-0010

Con este comando, enviamos una señal para apagar el servidor. Si estamos acostumbrados a utilizar virt-manager como interface gráfico, es un procedimiento similar, incluso más simple.

Figura 2: virt-manager

El siguiente punto, es utilizar la herramienta qemu-img para proporcionar más espacio del disco virtual, y eso lo podemos hacer de la siguiente manera:

$ qemu-img resize /var/lib/libvirt/images/servidor-0010.qcow2 +20GB

Muy simple verdad? Pues ahora falta lo más complicado y se los explico.

Así como está, si volvemos a iniciar el servidor virtual, solo va a reconocer que está en un disco más grande pero ese espacio en disco al no tener partición asignada en este momento no se podría utilizar.

En este punto es necesario acomodar el sistema de particiones conforme a lo necesario y dependiendo de como están distribuidas las particiones.

Quienes tengan los conocimientos y la experiencia para hacerlo utilizando la herramienta fdisk está muy bien, pues allí pueden trabajar y jugar con las particiones. Por mi parte encontré un LiveCD de Gparted donde es posible bootear este Live para acomodar de forma gráfica el sistema de particiones.

Con esto, redimensionamos el espacio de un disco virtual e hicimos que el sistema operativo lo reconozca.

Saludos!

Entradas populares