27 de agosto de 2015

WP-CLI para Auditores II


Una nueva entrada, y la idea de hoy es explorar algunas cosas que WP-CLI trae y que podemos sacar partido en cada auditoría que tengamos que llevar adelante.

Mi primera recomendación, es que siempre tengan presente el modo de instalar WP-CLI, yo soy partidario de descarga la herramienta, utilizarla y finalmente eliminarla, con esto siempre vamos a estar utilizando la última versión y no dejarlo dentro del sistema que quizás nunca más se vuelva a utilizar, esto simplemente es una apreciación personal.

Los comandos y argumentos asociados a WP-CLI son en algunos casos bastante intuitivos y con bastante ayuda dentro de la línea de comandos, de todas maneras y para consultas específicas, lo mejor que pueden hacer es recurrir a la documentación oficial del proyecto.

Nos afrontamos a un proceso de auditoría sobre una instancia de WordPress que aparentemente fue vulnerada o comprometida, ya sea que depositaron algún backdoor o lograron descifrar las credenciales de un usuario y cambiaron la integridad del mismo.

Con el mayor de los recaudo posibles tratamos de sacarla de línea a dicha web pero evitar que los usuarios continúen accediendo, por otro lado realizamos una copia de seguridad de todo el sitio y su base de datos para luego poder reproducirlo en un entorno controlado y poder hacer alguna de las pruebas.

Estaremos o no de acuerdo que este proceso nos va a llevar mas tiempo, o quizás implica asignar el doble de recursos, sin embargo para garantizar un buen trabajo de auditoría y posteriormente una buena restauración de las cosas, es mucho mejor y más cómodo trabajar con esta metodología.

Las auditorías implican conocer un poco más de información sobre lo que estamos trabajando, para este caso es buenos saber las versiones de cada componente y tomar nota de todas y cada una de las cosas.

Afortunadamente WP-CLI esta para ayudarnos y dentro de la instancia de WordPress que estamos auditando podemos ejecutar el argumento core para obtener más información:

$ ./wp-cli.phar core
usage: wp core check-update [--minor] [--major] [--field=<field>] [--fields=<fields>] [--format=<format>]
   or: wp core config --dbname=<dbname> --dbuser=<dbuser> [--dbpass=<dbpass>] [--dbhost=<dbhost>] [--dbprefix=<dbprefix>] [--dbcharset=<dbcharset>] [--dbcollate=<dbcollate>] [--locale=<locale>] [--extra-php] [--skip-salts] [--skip-check]
   or: wp core download [--path=<path>] [--locale=<locale>] [--version=<version>] [--force]
   or: wp core install --url=<url> --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core is-installed [--network]
   or: wp core language <command>
   or: wp core multisite-convert [--title=<network-title>] [--base=<url-path>] [--subdomains]
   or: wp core multisite-install [--url=<url>] [--base=<url-path>] [--subdomains] --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core update [<zip>] [--version=<version>] [--force] [--locale=<locale>]
   or: wp core update-db 
   or: wp core verify-checksums 
   or: wp core version [--extra]

See 'wp help core <command>' for more information on a specific command.

Es importante no intentar actualizar absolutamente nada, estamos en la fase de recopilar todo tipo de información actual.

Para determinar la version de WordPress lo podemos hacer de la siguiente manera:

$ ./wp-cli.phar core version
4.2.2

$ ./wp-cli.phar core version --extra
WordPress version: 4.2.2
Database revision: 31535
TinyMCE version:   4.109 (4109-20150505)

Mientra más detallada sea la información, en muchos casos va a ser mejor.

En un modo paranoico podemos verificar algunos archivos dentro de WordPress para realizar las comprobaciones:

$ cat wp-includes/version.php

Ahora que ya contamos con la información de WordPress, podemos verificar si dentro del core tenemos alguna actualización:

$ ./wp-cli.phar core check-update
+---------+-------------+-------------------------------------------+
| version | update_type | package_url                               |
+---------+-------------+-------------------------------------------+
| 4.3     | major       | https://wordpress.org/wordpress-4.3.zip   |
| 4.2.4   | minor       | https://wordpress.org/wordpress-4.2.4.zip |
+---------+-------------+-------------------------------------------+

Por otro lado, podemos obtener información del lenguaje que se encuentra activo:

$ ./wp-cli.phar core language list 

Aquí, vamos a poder ver un gran listado donde figura el lenguaje, el estado que tiene y su última actualización, mientras continuamos obteniendo más información.

Finalmente, si a la instancia de WordPress se le modificó alguno de los archivos importante, podemos realizar una verificación por medio de checksums y obtener una aproximación del problema.

Veamos los siguiente ejemplos:

$ ./wp-cli.phar core verify-checksums
Success: WordPress install verifies against checksums.

Como se puede ver, la comprobación fue exitosa, ahora les propongo modificar de forma intencional alguno de los archivos que incorpora wordpress, por ejemplo wp-comments-post.php incorporando algunos espacios o saltas de línea, volviendo a realizar la comprobación obtenemos lo siguiente:

$ ./wp-cli.phar core verify-checksums
Warning: File doesn't verify against checksum: wp-comments-post.php
Error: WordPress install doesn't verify against checksums.

Es bueno aclarar un punto, esta verificación por checksums no va a lograr determinar cuando por ejemplo agregamos algún archivo, suponiendo el caso que se agregó en /wp-content/plugins/backdoor.php esto lo va a pasar por alto, por esta razón tenemos que tener mucho cuidado en los reportes y el análisis que vamos a realizar de esta información que vamos recopilando.

Hasta aquí, son temas sumamente interesantes verdad? Buenos los invito a seguir en las próximas entregas.

Saludos!

21 de agosto de 2015

Google Hacking: Autoconfiguración de Proxy

Estos últimos días, mientras trabajaba e implementaba servidores de Proxy Cache SQUID3, comencé a interiorizarme un poco más en los archivos o scripts de auto-configuración de Proxy.


Todo esto con la idea de que un cliente de nuestra red, tenga la posibilidad de detectar la existencia de un proxy y lograr configurarse automáticamente sin la intervención de una configuración manual.

Ahora bien, la pregunta es la siguiente: ¿Se encuentra disponible estos scripts de auto-config en la Internet? ¿Qué información podría encontrar allí? La realidad es que SI encontramos muchos archivos de autoconfiguración y podemos obtener información de una aproximación de como son los pools de IP Internos, información de Proxy, puertos, etc.

Le agradezco nuevamente a la gente de Exploitdb por publicarlo en estos últimos días y para encontrar estos archivos podemos hacer la siguiente búsqueda en Google:

filetype:pac inurl:"/proxy"


Para obtener un poco más de información técnica de como construir nuestros script auto-config de proxy les recomiendo este enlace de Wikipedia.

Saludos!

Enlace | Exploitdb

20 de agosto de 2015

Google Hacking: Descubriendo reportes de Sarg

Hace un par de días, publicaron en Exploitdb un pequeño pero interesante dork que encontré dentro de Google, que permite encontrar algunos reportes de Sarg.

Sarg es un excelente analizador de log que parsea y muestra de una forma mucho más amigable un reporte completo de toda la actividad del servicio de Squid, como sistema de proxy dentro de una red lan.

Para encontrar estos reporte, podemos ingresar en google:

inurl:"/squid-reports/" AND intitle:"SARG reports"



Enlace | Exploitdb

18 de agosto de 2015

Estrictamente secreto y confidencial.pdf.jar

Esta es una crónica que se remonta a principios del 2015, cuando el 18 de Enero de este año, Argentina quedaba conmocionada por la noticia de que el Fiscal Alberto Nisman apareció muerto en su departamento.

Hasta ese momento, todo un trasfondo político, social y que a día de hoy continúan las investigaciones del hecho, sin embargo en el último evento BlackHat USA 2015, realizado el 1 de Agosto, el investigador Morgan Marquis­ Boire realizó una presentación donde explicaba que un posible virus había infectado el teléfono del ex Fiscal Nisman.

En una entrevista que publica el diario La Nación, contó que Nisman fue blanco de un Remote Access Tooklit (RAT), que es un "software que permite a un hacker o a un espía acceder de forma remota a la computadora o el dispositivo móvil de alguien".

Ya se encuentra disponible el paper de Morgan presentado en BlackHat "BIG GAME HUNTING: THE PECULIARITIES IN NATION­STATE MALWARE RESEARCH" y quizas dentro de unos meses podamos contar con el video de su presentación completa.

Por otro lado, este último fin de semana, el periodista Jorge Lanata, denunció que le infiltraron el mismo virus que a Nisma, con lo cuál si esto se comprueba, es una pista más quizás para ir esclareciendo todo este caso judicial que por momentos parece tan confuso y lleno de problemas.

Este fin de semana, el periodista decía lo siguiente:



Con todo esto que estamos viviendo, podemos llegar a pensar lo siguiente. Hoy no existe delito ni crimen si que la tecnología este presente, el mercado del "cibercrimen" requiere cada vez más de profesionales Informáticos Forenses con la capacidad de acercar y recopilar pruebas tan valiosas como la de este investigador.

Saludos!

14 de agosto de 2015

Actualización de Seguridad en WordPress 4.2.4

Agosto se inicio con una importante actualización de seguridad en el core de WordPress para llegar a la versión 4.2.4


Esta nueva versión de seguridad corrige 6 fallos importantes como 3 fallos XSS, un potencial SQL injection que podría utilizarse para comprometer un sitio.

De más esta decir, que a estas alturas su sitio tendría que estar actualizado para evitar cualquier tipo de posible ataques.

Saludos!

Enlace | WordPress 4.2.4 Security and Maintenance Release

Entradas populares