Mostrando entradas con la etiqueta google. Mostrar todas las entradas
Mostrando entradas con la etiqueta google. Mostrar todas las entradas

jueves, 28 de abril de 2016

Hacking con buscadores. Episodio III. La Venganza de las Shells


Saludos hackers!!
Os traigo una nueva entrega de la saga de hacking con buscadores.
En esta ocasión, vamos a buscar shells en PHP, tales como C99Shell y R57Shell.

Podemos buscar estas puertas traseras en sitios webs que ya han sido comprometidos por otr@s, con el fin de aprovecharnos del trabajo de otros para poder "investigar" en las máquinas objetivo.

Para ello usaremos los siguientes dorks:

  • "your ip * server ip" uname sysctl.


Entrando en alguna de ellas, podremos ver la shell, y todo lo que podemos hacer en ella para controlar el sistema.


 Y otra versión distinta de la shell R57:



Con la siguiente dork veremos más shells:
  •  "your ip * server ip" "uname -a".



Y podemos ver los siguientes tipos de shell:





Como se puede observar, son varios sitios webs que están bajo el control de una o varias personas, teniendo acceso a todo lo que hacen en su sistema. El cual anteriormente fue comprometido de alguna manera.

Son más shells las que existen, solo he mencionado de las más conocidas, pero puede haber miles de sitios webs con puertas traseras como estas, y que los propietarios de dichos sitios no tienen ni la menor idea de que su sistema, toda la información, y todo lo que ell@s hacen, está en poder de los crackers.


viernes, 4 de marzo de 2016

Hacking con buscadores. Episodio I. La Amenaza del Search



Saludos Hackers!

Soy Hurd4n0, y os presento esta PoC que será el comienzo de una saga xD.

En ella veremos dos ejemplos sencillos de unas "Google Dorks" y del daño que pueden llegar a ocasionar en malas manos.

  • "this page gives you" "mysql admin * no password"

Con esta dork, lo que estamos buscando son cuentas de administración de base de datos de MYSQL que no tienen una contraseña. Podemos observar los siguientes resultados:


 Pero si ponemos la dork sin las comillas, nos aparecen más resultados:




Al entrar en los enlaces, las páginas que nos saldrán serán como la siguiente:


Lo que podemos ver en la captura es la página de chequeo de seguridad de un servidor web en XAMPP, en el que podemos observar que tiene varias opciones inseguras, que suponen un peligro para el servidor. Como por ejemplo, que la herramienta PHPMyAdmin sea accesible sin credenciales.



  •  inurl: ws_ftp filetype:ini intext:pwd
Esta dork nos permitirá visualizar ficheros de configuración ws_ftp.ini. En el contiene información sobre dominios, usuarios y passwords con cifrado, pero bastante débil, sobre servicios de WS_FTP:


Podremos observar el tipo de información que contiene uno de estos ficheros:



A lo largo del fichero, podemos ver los parámetros UID y PWD, los cuales contienen usuario y password respectivamente. A continuación, vemos la debilidad del sistema de cifrado:


Con esto me despido, hasta la siguiente entrega, en la cual seguiremos observando el potencial del hacking con buscadores.

Un saludo hackers!!









miércoles, 2 de marzo de 2016

Evil GO.ogle

Buenas hackers!
En esta prueba de concepto os explicare como una persona con fines mal intencionados puede obtener el correo electronico Gmail de los empleados de una organización a través de Twitter como medio de propagación.



A traves del bypass del hsts conocida por @ShargonXL, el link http://www.google.es/?gws_rd=ssl fuerza el http saltandote el https, capturando la cookie de sesión de la cuenta de Gmail si ese usario previamente esta logeado en el navegador. Es un fallo de seguridad ya que un usuario mal intencionado puede enviar ese link a traves de ingenieria social y con un ataque man-in-the-middle obtener la cookie y sesión de Gmail.
¿Se consideraria un fallo de seguridad el degradar de https a http? Si se da el caso o la opinión de que no lo es, ¿por qué se implementa el sistema de seguridad hsts? El hsts precisamente consiste en evitar que una pagina web nunca vaya por http, porque es un protocolo inseguro, entonces ¿por qué el hsts de Google no funciona con ese link?, si la medida de seguridad hsts no funciona un atacante mal intencionando mediante Man-In-The-Middle tiene una capacidad enorme para interceptar las peticiones y respuestas entre un usuario y un servidor de aplicaciones web, es decir, se manda el link,  se abre un esnifer para capturar el trafico, pincha la victima y se obtiene la cookie y el email, saltando el https de Google.

Proof of concept by naivenom,
El empleado con conocimientos de hacking y con sintomas de Burnout (esta quemado con su trabajo :S), realizará un ataque Man-In-The-Middle estando en medio de la comunicación interceptando la información entre el emisor y receptor. Para ello tendrá que estar en la misma red LAN, y utilizar el protocolo IPv4 para el intercambio de datos.
El ataque esta basado en ARP Spoofing, donde el atacante con malas intenciones se colocará entre el router y la victima. Cuando el router envie tráfico a la victima, este pasara primero por la maquina del atacante.
El protocolo ARP permite el conocimiento de la dirección física de otro dispositivo partiendo de la base que conoce una dirección IP.




El planeamiento del ataque deberá ser meticuloso y saber el medio de propagación del link. En este caso el atacante usará el Twitter y mediante ingenieria social convencera al personal de la empresa para seguir esa cuenta. Propagará el link con un mensaje privado a todo el personal diciendo que el lugar del restaurante donde van a cenar es este: http://www.google.es/?gws_rd=ssl

Una vez planeado el ataque, empieza el ataque Man-In-The-Middle:

PASO 1: 

Será necesario que el atacante tenga un portatil y acceso a la red. Cumple de sobra estos requisitos. Abrira el programa EvilFOCA para realizar el ataque Man-In-The-Middle.


Una vez envenenado la tabla ARP de la victima, todos los paquetes enviados entre router y victima pasarán por nosotros.

PASO 2: 

Ahora procedemos a abrir un esnifer de paquetes de red como por ejemplo Wireshark.
Quizas sea este el paso más delicado y dependemos de varios factores:
  • Tiempo que haya de interacción entre victima y el software Twitter
  • Si la victima pincha el enlace o no. Se presupone de nuestra previa habilidad en convencimiento y confianza que le ofrecemos a la victima. 
Una vez que la victima pincha el enlace desde su maquina, se le abrirá la pagina de google y si hay suerte de que tenga ya logeada la cuenta de Gmail, obtendremos la cookie y el correo.


Guardamos la captura en .pcap

PASO 3:

Analizaremos la captura hecha con el software Fiddler.
Podemos observar que a través de la petición GET, obtenemos el Gmail de la victima con tan solo estar logeada.


Con el correo electronico podemos realizar ataques de phishing o envio de malware, obteniendo una shell del sistema victima.

PASO 4: 

Al capturar el tráfico, obtenemos unas cookies. De un modo u otro instalando una extensión en chrome podemos replicar esas cookies y tener la sesión loegada del Gmail victima en nuestra maquina. También deberemos modificar el user-agent con otra extensión proporcionada por Chrome:





Replicamos las cookies que obtenemos en la captura de Wireshark o Fiddler y la añadimos o editamos en nuestro navegador:


Actualizamos con la replica de las cookies obtenidas mediante el esnifer y escribimos la URL del link:



Como pueden observar es fácil a traves de un ataque Man-in-the-middle y el bypass del hsts, obtener información sensible como puede ser el correo electronico o el nombre y apellidos.

P.D Esta prueba de concepto esta realizada con fines educativos siempre en un entorno de trabajo propio, usando la propia red LAN y cuenta de correo (en este caso) de Gmail. No nos hacemos responsables de su mal uso.


Google Analytics