Download BackBox 3 - Iniciación al Pentesting PDF

TitleBackBox 3 - Iniciación al Pentesting
File Size3.8 MB
Total Pages37
Table of Contents
                            Backbox Linux 3 – Iniciación al Pentesting
Por Ismael Gonzézles D.
Este libro se distribuye bajo una licencia Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional
Usted es libre de:
Copiar y redistribuir el material en cualquier medio o formato
Bajo las condiciones siguientes:
Attribution — Debe reconocer adecuadamente la autoría, proporcionar un enlace a la licencia e indicar si se han realizado cambios. Puede hacerlo de cualquier manera razonable, pero no de una manera que sugiera que tiene el apoyo del licenciador o lo recibe por el uso que hace.
NonCommercial — No puede utilizar el material para una finalidad comercial.
ShareAlike — Si remezcla, transforma o crea a partir del material, deberá difundir sus contribuciones bajo la misma licencia que el original.
Introducción
	¿Qué es el Pentesting? Pentesting es el trabajo que realiza un Hacker para determinar todas las vulnerabilidades de un sistema, programa, servidor, o empresa. El pentester por su parte es aquella persona que se encarga de realizar una batería de pruebas para después presentar un informe detallado a la empresa o servicio por el que fue contratado. Este trabajo se denomina Hacker ético.
	Un contrato de Hacker ético compromete al pentester o auditor a ceñirse a las condiciones de su contrato. Esto permite evaluar todos los riesgos de una empresa sin que ésta se vea afectada por los datos obtenidos
Capítulo 1 Primeros Pasos Con Backbox
	Herramientas y su uso
	Por donde empezar
	Objetivo 1: Atacar servidor web
Capítulo 2 Búsqueda de vulnerabilidades
	Introducción
	Una vez que ya tenemos bastante información del objetivo al que queremos atacar es hora de dar un paso más e intentar buscar algún tipo de vulnerabilidad que nos de acceso al sistema.
	Como ya hemos comentado antes, no siempre las categorías que nos ofrecen las Distros de seguridad se corresponden con el proceso de un Ethical Hack, ya que muchas de las herramientas sirven para hacer más de una función.
	En este tema utilizaremos alguna que otra herramienta que no se encuentra dentro de la sección de Búsqueda de Vulnerabilidades, pero que sin embargo nos servirá de igual manera.
	Las herramientas que utilizaremos para buscar vulnerabilidades no son más que escáneres de vulnerabilidades. Programas que están diseñados para automatizar una serie de funciones y que están pensadas para ayudarnos a no tener que hacer búsquedas manuales de cada tipo de vulnerabilidad. De un determinado servicio.
	El principal inconveniente de este tipo de búsqueda es que, la gran mayoría de las aplicaciones hacen falsos positivos. Eso significa, que aunque el programa encuentre una vulnerabilidad no siempre a de ser explotable.
	Nmap como escáner de vulnerabilidades (NSE Vulnscan)
	Casi se podría decir que nmap es la herramienta indispensable para cualquier hacker gracias a la cantidad de script que están desarrollados para ello, y que son configurables a nuestro gusto. De igual manera que utilizamos nmap para recolectar información lo haremos esta vez pero para buscar vulnerabilidades.
	Esto es posible a un script desarrollado específicamente para realizar esta función. El script consiste en hacer una búsqueda de las vulnerabilidades ya encontradas en un repositorio de dichas vulnerabilidades. (Este repositorio es actualizable desde cada una de las páginas oficiales desde las que se reportan las vulnerabilidades).
	Las bases de datos son:
	cve.csv
	osvdb.csv
	scipvuldb.csv
	secunia.csv
	securityfocus.csv
	securitytracker.csv
	El script que está basado en nmap NSE (nmap scritpting engine) debemos de bajarlo e instalar lo. Por defecto no viene instalado con nmap.
	La manera de instalar es copiando la carpeta completa de NSE Vulnscan en la ruta donde se encuentran el resto de script para nmap. Por defecto: /usr/share/nmap/scripts
	Página oficial de descarga: www.scip.ch/en/?labs.20130625
	PoC: Prueba de concepto Nmap Vulnscan v1.0
	El parámetro es bastante sencillo una vez que se tiene instalado el script.
	Basta con poner los parámetros que solemos poner habitualmente haciendo referencia al script:
	nmap -T4 -v -v -F --script vuln --script-args vulnscandb=securityfocus.csv www.sitioweb.com
	Lo que estamos consiguiendo con estos parámetros es decir a nmap que queremos que lance un escaneo básico, mostrándonos los errores y los resultados. Indicándole además que queremos que utilice un script (vuln) y añadiendo la base de datos done queremos que haga sus búsquedas.
	El resultado como comprobamos es bastante bueno, hemos obtenido un fallo de XSS (Cross Site Scripting)
	Nmap nos está sirviendo para buscar vulnerabilidades, sin embargo eso no quiere decir que aya a realizar el ataque por nosotros. Eso sí, nos dará toda la información necesaria. Tanto es así, que nos muestra la url completa a la que debemos atacar para explotar dicha vulnerabilidad.
	Aunque la explotación de vulnerabilidades las veremos en el siguiente tema, quiero mostrar como la vulnerabilidad de nmap es completamente explotable y no nos ha dado un falso positivo.
	Algo que debemos tener en cuenta es saber que, por mucho que cada herramientas está un poco más enfocada para un tipo de función es bueno combinarlas entre ellas. De nada sirve tener muchas información de nuestro objetivo si luego no sabemos como buscar vulnerabilidades. Y lo mismo pasa a la hora de buscar vulnerabilidades, de nada sirve encontrar vulnerabilidades si luego no sabemos explotarlas. Comento esto por que a lo largo de este tema iremos viendo como encontrar vulnerabilidades y como saber encontrar la manera de explotarlas.
	Posteriormente en el tema de explotación de vulnerabilidades nos centraremos más en como conseguir escalar privilegios, hacernos con el control de la máquina, etc. Pero de una manera mucho más concreta y sabiendo casi a un 100% que nuestro objetivo es vulnerable a ese ataque.
	Puesto que esto es una primera toma de contacto con el pentesting y más concretamente con Backbox, no vamos a pararnos a explicar cada una de las herramientas que trae el SO. Eso sí, nos centraremos en las que mejores resultados hemos obtenido a la hora de realizar una auditoría.
	El siguiente turno le toca a OWASP.
	Turno de OWASP
	OWASP podríamos decir que es una herramienta que trabaja como proxy. ¿esto que quiere decir? Nosotros podemos utilizar OWASP para que intercepte todo el trafico de nuestro navegador, y para ello sólo hemos de configurar el navegador para que salga por un proxy.
	Este proxy será la dirección local de tu máquina 127.0.0.1, y el puerto será el que se le haya asignado a OWASP, que por defecto es el 8081.
	También podemos utilizar OWASP como cualquier otro escáner. Simplemente metiendo la dirección a la que pretendemos atacar. OWASP se encargará de hacer un búsqueda de todas las vulnerabilidades posibles.
	Pero esto lo veremos después...
	La diferencia radica en nuestro propio criterio, es decir, el ataque va a ser el mismo, sin embargo podremos utilizarlo de la manera que nos sea más cómoda. Si utilizamos OWASP como proxy, estaremos obligando al navegador a que todas las direcciones pasen previamente por OWASP. Esto puede ser un poco caótico si a la misma vez que estamos atacando una web, también estamos visitando otras que no tienen nada que ver con el ataque. OWASP las recogerá y las analizará de igual manera.
	Eso sí, si sabemos esto previamente, tendremos el ataque mucho más controlado. Ya que podremos enfocar o centrar en aquella parte donde queremos o creemos que podemos encontrar una vulnerabildiad.
	El otro método de ataque es más directo aunque también es un arma de doble filo. Hablamos de un ataque que se realiza directamente sobre la web que nosotros le indiquemos. Esto incluye todo tipo de búsqueda de vulnerabilidades, recorrido de url, etc. Por tanto es un poco más llamativo para los FW, IDS/IPS, etc.
	La manera de trabajar de OWASP, para este caso será recorrer todas las URL del dominio que nosotros le hemos indicado y en cada una de ellas intentará hacer alguna comprobación para ver si es explotable o no. Este tipo de ataque es fácilmente detectable por los FW o los IDS. Ya que se estaría realizando pruebas malintencionadas desde nuestra IP.
		Manos a la obra: Primera prueba de concepto con OWASP
	Para ver el gran potencial de la herramienta lo que hemos hecho ha sido lanzar un ataque directo hacia una página. Esperando que nos reportara alguna vulnerabilidad, y que ésta no fuera un falso positivo.
	Cuando se lanza un ataque directo desde OWASP, y prácticamente desde cualquier escáner de vulnerabilidades, el proceso es lento y requiere de bastantes recursos del procesador y la memoria. Solo es cuestión, de esperar a que el ataque finalice y luego ir viendo que reporte de vulnerabilidades ha obtenido.
	En el caso de OWASP existen cuatro iconos con los que podremos diferenciar los tipo de alertas que ha ido encontrando. O mejor dicho el grado de vulnerabilidad.
	Tipos de alerta según el color:
	Rojo: Vulnerabilidad crítica.
	Naranja: Criticidad media
	Amarilla: Vulnerabilidad baja.
	Azul: Alertas informativas
	Nada mejor que ver el resultado obtenido del ataque para entenderlo bien.
	Con tan solo un par de “clic” conseguimos algunas que otras vulnerabilidades, de las cueles 2 de ellas son críticas y encontradas en más de un lugar de la página, tal y como muestra la imagen:
	Cross Site Scripting (XSS) fue encontrado en 16 lugares de la página.
	SQL injection fue encontrada en otros 5 lugares de la página.
	Sabiendo esto y con las herramientas adecuadas, ya casi estamos listo para realizar un ataque en toda regla y empezar a obtener datos privados del objetivo al que estamos atacando para después reportarlo en nuestra auditoría de ethical hack.
Capítulo 3 Explotación
	Introducción
	Este tema será posiblemente uno de los más atractivos. En él vamos a ver como darle uso a toda la información que hemos recopilado anteriormente y que nos será de gran ayuda.
	Si hacemos un breve resumen ya tenemos; los puertos abiertos a los que vamos a atacar, el tipo de tecnología, y alguna que otra vulnerabilidad.
	Sabiendo esto sólo es cuestión de centrarnos en la vulnerabilidad que queremos explotar, elegir la herramienta y llevarlo acabo.
	Algunas pruebas básicas que se deben hacer antes de intentar vulnerar un sistema es descartar si las vulnerabilidades que devolvió OWASP ZAP son falsos positivos o realmente son vulnerabilidades explotables.
	En algunas ocasiones el saber si una web es vulnerable a una de estas fallas es muy sencillo.
	Por ejemplo: en el caso de una vulnerabilidad SQL injection sería cuestión de introducir una comilla simple (') para ver si se produce el error. Si existe error por parte del servidor es altamente probable que podamos realizar un ataque sobre la BBDD.
	Otro fallo de seguridad que se suele encontrar a menudo son los llamados XSS (Cross Site Scripting) que para reconocerlos solo hará falta introducir un pequeño “script” al final de la url con el objetivo de alterar la información de la página web.
	Basándonos en la(s) vulnerabilidad(es) que ya encontramos podemos empezar a descartar falsos positivos.
		Identificando vulnerabilidades.
	El primer paso de todos es revisar todas las vulnerabilidades e identificar de que tipo de vulnerabilidad se trata (SQL, XSS, DoDS,...)
	Examinando el informe de vulnerabilidades de OWASP ZAP tomaremos como ejemplo una de las alertas con mayor criticidad.
	Se trata de una vulnerabilidad SQL injection UNION sobre MySQL.
	Si esta vulnerabilidad fuera explotable estaríamos comprometiendo el sistema de la BBDD y posiblemente seríamos capaces de alterar el contenido tanto de la BBDD como de la página web a la que atacamos. Lo iremos viendo poco a poco.
	Para comprobar si existe un fallo de seguridad SQL injection vamos a coger la URL y a modificarla para ver que nos devuelve el servidor.
	URL original:
	URL modificada con una comilla al final (')
	El resultado es un claro error de sintaxis, esto es básicamente, en la gran mayoría de los casos, nos permitirá extraer información de la BBDD. Y gracias a esta pequeña comprobación podemos empezar a lanzar nuestro ataque.
		Vulnerando la BBDD y extrayendo información.
	Existen numerosas herramientas que nos ayudarán a lanzar un ataque sobre la BBDD. Al igual que sucedía con la búsqueda de vulnerabilidades, para explotar un fallo de SQL injection utilizaremos alguna herramienta que nos permita automatizar el ataque.
	Para ello utilizamos SQLmap, que es sin duda una de las herramientas más potentes que existe para realizar ataques de SQLinjection, y que además viene por defecto instalada en Backbox.
	Esta herramienta contiene numerosos script, con la configuración necesaria para poder lanzar un ataque sobre cualquier BBDD que sea vulnerable.
	Al acceder por primera a SQLmap y añadiendo el parámetro -h (#sqlmap -h), se mostrará alguna de las configuraciones más básicas y utilizadas.
	Algunas parámetros que debemos tener en cuenta son (por ejemplo) Level y Risk.
	Existen ocasiones que al intentar extraer información no obtendremos nada por parte del servidor, e iremos aumentando el grado de Level y Risk.
	Por otra parte, gracias a la gran capacidad de sqlmap, con el comando DUMP se puede llegar a realizar un volcado de la BBDD a tu máquina.
	Se podrías decir que utilizar SQLmap es fácil, o al menos intuitivo, ya que si se introduce algún parámetro mal la herramienta nos dirá que es lo que estamos haciendo mal, y nos dará algún tipo de solución.
		SQLmap: Prueba de concepto
	Lo primero que intentaremos será ver que Bases de datos almacena el servidor. Para ello añadimos el parámetro –dbs. Esto debería mostrar todas las BBDD.
	#sqlmap -u http://sitioweb.com/actualidad/evento.php?id=110 –dbs
	El resultado es precisamente el esperado, hemos conseguido obtener todas las bases de datos a través del fallo que encontramos. A partir de aquí será cuestión de ir viendo la ayuda de SQLmap para saber que podemos utilizar en nuestro beneficio. Lo más lógico sería, partiendo de la bases de datos a la que queremos atacar, hacer un volcado de la información de alguna de las tablas, columnas, o de la BBDD entera.
	Todas las Bases de datos están compuestas de Tablas, Columnas y Registros. Por tanto una Base de datos almacena numerosas Tablas, que estas a su vez almacenan numerosas columnas. Las columnas por su parte son las que almacenan los registros, es decir, la información final. Son estos datos los que pueden contener Nombres de usuarios, contraseñas, etc.
	Esto hay que tenerlo en cuenta ya que a la hora de lanzar el ataque con SQLmap lo haremos paso a paso e intentando provocar las menos sospechas posibles.
	Cuando hablamos de hacerlo paso a paso nos referimos a ir obteniendo información desde lo más básico hasta profundizar en cada una de las bases de datos. Es decir, primero veremos las bases de datos que almacena el servidor, después veremos las tablas de alguna base de datos, luego las columnas dentro de esa tabla, y así sucesivamente.
		Obteniendo las tablas de la base de datos
	Para obtener la información de las tablas que almacena la base de datos, hemos de indicar a SQLmap la URL y la base de datos de la que queremos la información.
	Como el listado de las bases de datos ya lo hemos obtenido anteriormente será cuestión de ver si existe alguna BD que por su nombre parezca más relevante.
	Con el siguiente comando enumeraremos, nos mostrará, las tablas de la base de datos db23616:
	#sqlmap -u http://sitioweb.com/actualidad/evento.php?id=110 --level=5 --flush-session --tables -D bd23616
	El resultado es una gran lista de tablas. Algunas de ellas, por su nombre, bastante significativas, como es el caso de los datos de Recursos Humanos.
	NOTA: Es importante saber que SQLmap en cada ataque que lanza guarda los resultados en una carpeta (/, que después utiliza para buscar en ella en caso de realizarse un nuevo ataque sobre la misma URL. Con esto sqlmap pretende ahorrar tiempo en nuestra buscada. Sin embargo en muchas ocasiones nos puede perjudicar ya que sqlmap trata esta información de la misma manera que lo hace un navegador web con los temporales. Es posible que en algunas ocasiones no se estén mostrando los resultados “reales” acorde con lo que lanzamos, el motivo es que sqlmap siempre que se haya realizado una consulta previamente sobre esa web, antes de volver a lanzar un nuevo ataque, mostrará los resultados ya obtenidos con anterioridad. Esto se soluciona añadiendo el parámetro –flush-session el cual nos permitirá saltarnos esta especie de caché.
	Si continuamos buscando información sensible en las tablas y en las DB, podremos ver como colarnos en el servidor es mucho más fácil de lo que se piensa en un primer momento.
	Como ya comentamos al principio de este Tema, una vez vulnerado el servidor mediante una inyección SQL, podríamos decir que tenemos “control total” sobre la máquina.
	En este ejemplo vamos a ver como una de las tablas de de una DB contiene las contraseñas, en
	texto claro, de unos usuarios.
	Estas cuentas de usuario que se almacenan en texto claro, se trata de cuentas, que por algún motivo, el administrador a decidido guardar sin cifrar. Este gran fallo de seguridad nos va a permitir seguir introduciéndonos un poquito más en la máquina.
Capítulo 4 Post-explotación
	La post-explotación de los sistemas en una auditoría de hacking ético no es más que aquello que podemos realizar una vez vulnerado los sistemas. Es decir, una vez que ya tenemos control sobre un equipo intentar vulnerar otros equipos de la red.
	Durante todo el libro se está realizando el ataque sobre una misma máquina, por lo tanto, y para que todos entendamos bien el concepto de post-explotación seguiremos haciéndolo de igual forma, sobre la misma máquina.
	Como ya hemos visto, tenemos acceso sobre la BD, y además tenemos unas passwords que se pueden ver sin necesidad de Crackearlas.
	Al principio del Tema 1, se vio que la recogida de información era muy importante para después poder realizar un ataque. Esto nos va a permitir vulnerar aún más la BD.
	Si recordamos, la máquina que estamos atacando, que no es más que un servidor web, uno de sus apartados era un blog basado en Wordpress. Vamos a aprovecharnos de la brecha de seguridad del MySql para hacernos con el control total de la base de datos a través del archivo de configuración del propio Wordpress.
	Esto lo podremos hacer con SQLmap descargándonos o mostrando (como prefiramos) el archivo wp-config.php el cual contiene el nombre de usuario y la contraseña con la que Wordpress se conecta a la BD.
	Otras de las características de SQLmap de la que sacaremos gran partido es la posibilidad de leer ficheros del servidor o máquina remota. Observando la ayuda que nos ofrece SQLmap vemos que sus usos y funciones son casi infinitos. Ahora bien, fijémonos en el parámetro –-file-read=
	Este parámetro nos permite leer un archivo al lanzar el comando #sudo sqlmap -u http://website.es/actualidad/evento.php?id= –-file-read=/etc/passwd
	Es lo mismo que si hiciéramos un #nano /ruta/del_archivo.txt
	Esto nos permitirá visualizar el archivo en nuestra máquina. Como ya he comentado, sabiendo que nuestro objetivo tiene un Wordpress montado, y que éste guara la información del nombre de usuario y las password de la base de datos a la que se conecta, podremos penetrar en este servidor. Para ello sólo debemos de leer el archivo wp-config.php
	#sudo sqlmap -u http://website.es/actualidad/evento.php?id= –-file-read=/opt/lammp/sitio/blogs/2013/wp-config.php
	Acceso al servidor
	Existen muchas formas de poder acceder al servidor una vez que se encuentra una brecha de seguridad en el sistema. En la gran mayoría de las ocasiones el acceso al servidor será de manera indirecta para ir escalando privilegios.
	Es muy común en un ataque la escalada de privilegios.
		Escalada de privilegios
	Se conoce como escalada de privilegios la técnica que permite ir adquiriendo más permisos sobre un sistema informático. Algunos casos típicos es cuando un atacante obtiene la cuenta de usuario de un sistema sin apenas privilegios, y a partir de éste ir accediendo a otros sistemas hasta hacerse con algún otro usuario Administrador que le otorgue más permisos sobre su propio sistema o sobre otro.
	Esto se emplea normalmente para conseguir un control total sobre la máquina que se quiere atacar.
		Acceso indirecto al servidor: Base de datos
	En base a la información extraída del archivo de configuración de Wordpress podemos acceder y hacer un recorrido por servidor que almacena la Base datos, con el fin de ver que otras Bases de datos, tablas, y usuarios existen en él.
	Aunque esto mismo se podría haber hecho anteriormente con SQLmap, la navegación en un entorno gráfico mediante un cliente de sql es mucho más amigable e intuitiva a la hora de seguir buscando información sensible que nos permita ir escalando privilegios.
	El archivo de configuración wp-config.php de Wordpress permite conectar la página web montada sobre wordpress con la Base de datos. Para ello este archivo guarda las credenciales del servidor contra el que se autenticará, así como la Base de datos a la que debe de atacar.
	Para realizar la conexión contra el servidor de Base de datos se ha utilizado el cliente Dbeaver (http://dbeaver.jkiss.org/) multiplataforma y operativo para todos los gestores de base de datos conocidos.
	Penetrando en Wordpress
	Existen escáner de vulnerabilidades web capaces de encontrar vulnerabilidades en Gestores de Contenido tipo CMS como Wordpress, Joomla, etc, pero además, por otra parte también existen herramientas especializadas, pensadas para analizar y encontrar todo tipo de vulnerabilidades en Joomla y Wordpress, como es el caso de wpscan para Wordpress, o joomscan para Joomla.
	Estas herramientas son capaces de analizar todo tipo de plugin, componentes, módulos, widgets... con el fin de determinan cuales de ellos están instalados, cual es su versión y si es vulnerable o no.
	Esta vez no vamos a mostrar ninguna de estas herramientas ya que anteriormente hemos obtenido acceso a la Base de datos del servidor donde se aloja también la Base de datos del propio Wordpress, pero está bien saber que existen para en un futuro poder utilizarlas en nuestras auditorías de seguridad.
		Creando un nuevo usuario en Wordpress a través de mysql
	Ahora que tenemos acceso a la Base de datos probaremos a crear un usuario con permisos Admin dentro del panel de administración de Joomla.
	El motivo de hacer esto y no extrae directamente la contraseña de alguno de los usuarios que ya exista en Wordpress, es porque el cifrado de la contraseña de Worpdress es muy fuerte, y tardaríamos meses en poder Crackear el Hash.
	Para poder crear un nuevo usuario de Wordpress a través de la Base de datos, debemos de insertar una sería de filas y campos dentro de la tabla wp-usermetada y wp-users. Estas dos tablas son las que contienen la información de los usuarios y sus permisos.
		Wp-users
	Esta tabla contiene los campos de toda la información del usuario:
	Nombre
	Contraseña
	Nickname
	Email de usuario
	Estado
	Etc.
		Wp-usermetada
	Sin embargo esta otra tabla contiene los datos necesarios que otorga al usuario ciertos permisos y privilegios, como son:
	Editor
	Autor
	Administrador
	Invitado
	Etc
	Quizás una de las cosas más importantes a tener en cuenta es el nombre que elijamos para el nuevo usuario que crearemos. Hay que procurar pasar lo más desapercibido posible.
	Inventarse nombres del tipo, user_tmp, 001_tmp, admins, usr... pueden ser una buena idea para que el administrador del sitio apenas se de cuenta de que existe un nuevo usuario. El nombre que se pone es de esta índole para que en caso de que alguien lo vea tienda a pensar que es un usuario del propio sistema, o que fue creado junto con la instalación de algún componente o plugin.
	Para la parte que contiene los privilegios de los usuarios, tan solo vamos a fijarnos en cual de los usuarios que ya existe es administrador para copiar los mismos valores en una nueva fila y asociarlos al ID del usuario que hemos creado.
	Es decir, el primer paso es añadir una nueva fila en la tabla wp_usuers, tal y como muestra la ilustración 21. El segundo paso es insertar dos filas más en la tabla wp_usermetada, las cuales asociaremos al ID del usuario que creamos anteriormente en la tabla wp_user.
	Con esto ya podríamos ir a la parte de administración de Wordress e intentar ingresar con el nuevo usuario que hemos creado.
	Por defecto en la ruta con la que accederemos a Wordpress se ubica en www.sitio.com/wp-admin.
	Si todo ha ido bien ya podemos empezar a navegar por todo el sitio en busca de más información relevante, o en busca de nuevas proezas que nos ayuden a adentrarnos un poco más en la infraestructura de la empresa.
	Local File Inclusion: un paso más cerca del control
	Local file inclusion (LFI ) se trata de una vulnerabilidad que permite al atacante subir una shell al servidor.
	Esta shell no es más que un archivo que puede estar programado en distintos lenguajes como son PHP o ASP. El atacante buscará la manera de poder subir el archivo/shell a través de la web.
	Normalmente este fallo de seguridad es debido a que los formularios de subida de archivos (documentos, imágenes, música... ) no hacen bien el filtrado del tipo de archivo o extensión que se sube. Esto se debe a un fallo de programación en el propio PHP o por una mala configuración en Apache.
	Al disponer de una shell en la máquina de manera local podremos enviar casi cualquier comando como si estuviéramos delante del ordenador. Comentar que, a pesar de que se pueden lanzar comandos, no todos los comandos se podrán ejecutar, ya que para abrir determinados programas o acceder a algunos directorios y carpetas, se requieren permisos más elevados o de Root, sin embargo estos pocos permisos serán suficiente como para intentar una escalada de privilegios y así poder tener control total sobre el usuario y la máquina.
	Si bien es cierto que en la mayoría de los casos este fallo se explota a través de formularios de subida, cada hacker se las ingenia para al final disponer de una shell en el servidor web independientemente el medio que haya utilizado.
		LFI a Wordpress
	Llegados a este punto podíamos haber vuelto a buscar vulnerabilidades, esta vez en Wordpress, con el fin de encontrar algún plugin que nos facilitara la subida de una shell. Sin embargo, puesto que ya tenemos un usuario Admin, nos aprovecharemos de éste para introducir así nuestra shell.
	El proceso es sencillo ya que tan sólo nos va a hacer falta modificar algún archivo PHP de los que compone Wordpress. Al tratarse de uno de los archivos del propio Wordpress, el usuario Admin de Wordpress tendrá permisos suficientes para modificar dicho archivo y que éste se quede guardado en el servidor.
	Para lograr nuestro propósito vamos a acceder al panel de administración con el usuario Admin (el cual ya creamos anteriormente a través de la BD) y vamos a buscar, entre toda la configuración del Panel Admin, la manera de modificar un archivo de los que compone Wordpress.
	Una buena idea sería editar la plantilla/Theme que está instalado en ese Wordpress. Muchos de los archivos que componen el Theme están programados en PHP y se pueden editar.
	Siempre que se hagan este tipo de modificaciones hay que tener cuidado con el archivo que se modifica, ya que si editamos un archivo que no debemos podemos dejar sin servicio la web.
	Ahora que ya sabemos cual va a ser la forma de actuar y el proceso que se va a seguir, necesitamos descargar una shell para incrustarla en uno de estos archivos. En la web http://www.oco.cc/ podemos encontrar numerosas shell que nos servirán para hacer esto mismo. Cualquiera de ellas es válida.
	Como ejemplo utilizamos la shell c99.php los pasos a seguir son:
	Descargamos la shell (c99, r57, c100...)
	Con algún editor de texto, abrimos la shell y copiamos su contenido.
	Buscamos un archivo php que se puede editar dentro del panel Admin de Wordpres.
	Pegamos el contenido de la Shell en el archivo de Wordpress.
	
	Después de colocar la Shell en uno de los archivos sin que nadie note nada, nos falta saber la ruta exacta donde está alojada. En Wordpress, como en todos lo CMS, los archivos, directorios y rutas, son estáticos, por lo que podemos hacer dos cosas, 1-Bajarnos Wordpress y ver donde se encuentra la ruta, o 2-Buscar la ruta dentro del código fuente.
	Quizás si hubiéramos modificado cualquier otro archivo de Wordpress nos hubiera hecho falta bajar una copia de Wordpress a nuestro equipo para ver la ruta, o utilizar un spider para recorrer todas las URL y ver así todos sus directorios (algo que puede estar capado si el administrador se ha preocupado de la seguridad de su sitio). En nuestro caso no va ser necesario todo esto, si vemos el código fuente de la página principal de Wordpress, podremos localizar fácilmente la ruta donde esta el Theme.
	Lo siguiente será ver que comprobar que todo ha salido como esperamos y que al introducir la ruta donde hemos guardado la Shell realmente se muestra el panel de configuración de la Shell c99.
	La ruta entera quedaría de la siguiente manera:
	http://192.168.233.211/wordpress/wp-content/themes/twentytwelve/author.php
                        
Document Text Contents
Page 2

Backbox Linux 3 – Iniciación al Pentesting

Por Ismael Gonzézles D.

Este libro se distribuye bajo una licencia Reconocimiento-NoComercial-CompartirIgual
4.0 Internacional

Usted es libre de:

Copiar y redistribuir el material en cualquier medio o formato

Bajo las condiciones siguientes:

Attribution — Debe reconocer adecuadamente la autoría, proporcionar un
enlace a la licencia e indicar si se han realizado cambios. Puede hacerlo de

cualquier manera razonable, pero no de una manera que sugiera que tiene el apoyo
del licenciador o lo recibe por el uso que hace.

NonCommercial — No puede utilizar el material para una finalidad
comercial.

ShareAlike — Si remezcla, transforma o crea a partir del material,
deberá difundir sus contribuciones bajo la misma licencia que el

original.

http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#
http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es_ES#

Page 19

Capitulo 2 – Búsqueda de vulnerabilidades

La manera de trabajar de OWASP, para este caso será recorrer todas las URL del dominio que
nosotros le hemos indicado y en cada una de ellas intentará hacer alguna comprobación para
ver si es explotable o no. Este tipo de ataque es fácilmente detectable por los FW o los IDS. Ya
que se estaría realizando pruebas malintencionadas desde nuestra IP.

Manos a la obra: Primera prueba de concepto con OWASP

Para ver el gran potencial de la herramienta lo que hemos hecho ha sido lanzar un ataque
directo hacia una página. Esperando que nos reportara alguna vulnerabilidad, y que ésta no
fuera un falso positivo.

Cuando se lanza un ataque directo desde OWASP, y prácticamente desde cualquier escáner de
vulnerabilidades, el proceso es lento y requiere de bastantes recursos del procesador y la
memoria. Solo es cuestión, de esperar a que el ataque finalice y luego ir viendo que reporte de
vulnerabilidades ha obtenido.

En el caso de OWASP existen cuatro iconos con los que podremos diferenciar los tipo de
alertas que ha ido encontrando. O mejor dicho el grado de vulnerabilidad.

Tipos de alerta según el color:

Rojo: Vulnerabilidad crítica.

Naranja: Criticidad media

Amarilla: Vulnerabilidad baja.

Azul: Alertas informativas

Nada mejor que ver el resultado obtenido del ataque para entenderlo bien.

Con tan solo un par de “clic” conseguimos algunas que otras vulnerabilidades, de las cueles 2
de ellas son críticas y encontradas en más de un lugar de la página, tal y como muestra la

19

Ilustración 9: Ataque automático a una URL con OWASP ZAP

Ilustración 10: Leyenda de iconos

Page 36

Capítulo 4 – Post-explotación

◦ Pegamos el contenido de la Shell en el archivo de Wordpress.



Después de colocar la Shell en uno de los archivos sin que nadie note nada, nos falta saber la
ruta exacta donde está alojada. En Wordpress, como en todos lo CMS, los archivos, directorios
y rutas, son estáticos, por lo que podemos hacer dos cosas, 1-Bajarnos Wordpress y ver donde
se encuentra la ruta, o 2-Buscar la ruta dentro del código fuente.

Quizás si hubiéramos modificado cualquier otro archivo de Wordpress nos hubiera hecho falta
bajar una copia de Wordpress a nuestro equipo para ver la ruta, o utilizar un spider para
recorrer todas las URL y ver así todos sus directorios (algo que puede estar capado si el
administrador se ha preocupado de la seguridad de su sitio). En nuestro caso no va ser
necesario todo esto, si vemos el código fuente de la página principal de Wordpress, podremos
localizar fácilmente la ruta donde esta el Theme.

Lo siguiente será ver que comprobar que todo ha salido como esperamos y que al introducir la
ruta donde hemos guardado la Shell realmente se muestra el panel de configuración de la
Shell c99.

La ruta entera quedaría de la siguiente manera:

http://192.168.233.211/wordpress/wp-content/themes/twentytwelve/author.php

36

Ilustración 26: Shell copiada en archivo author.php del theme Twenty Twelve de Wordpress

Ilustración 27: Código fuente de la página principal de Wordpress

Page 37

Capítulo 4 – Post-explotación

37

Ilustración 28: Shell c99: Panel de administración

Similer Documents