Redimensionar discos Virtual Box

NOTA: Para poder modificar el disco debemos asegurarnos que el tipo de disco es "Reservado dinámicamente"

La modificación es muy sencilla, ya que únicamente deberemos ejecutar este comando desde la ubicación en la que se encuentre el fichero de disco .vdi:

vboxmanage modifyhd nombre_disco.vdi --resize 20480

En este caso el número 20480 correspondería a 20GB. Si queréis ampliar por ejemplo a 30GB deberíais multiplicar 30 * 1024 = 30720.

Si todo funciona correctamente verás el progreso de la ampliación. Si por el contrario ves algo como esto:

0%… Progress state: VBOX_E_NOT_SUPPORTED VBoxManage: error: Resize hard disk operation for this format is not implemented yet!

Significa que el disco se creó con tamaño fijo, por lo que no podrás redimensionarlo.

Fuente:  http://www.unsysadminenapuros.com/

Ataque MITM con Ettercap + SSLStrip

La entrada de hoy va dedicada a ak!l3s, del blog 1 Gb de información, al cual os recomiendo que os suscribáis porque realmente publica cosas muy interesantes y muy bien explicadas. Espero que le pique el gusanillo con esta entrada y se decida a dar el salto a GNU/Linux :p

Ataques de robos de credenciales hay muchos, e infinidad de aplicaciones para poder llevarlos a cabo. Estoy seguro que más de uno ya tiene experiencia con "Cain & Abel" para Windows o "Evil FOCA" del equipo del gran Chema Alonso. Si no es así os recomiendo que les echéis un vistazo porque la verdad es que son muy interesantes y el uso es quizás más intuitivo que el de la PoC que vamos a hacer hoy.

En este gráfico veréis de manera un poco más gráfica qué es exactamente un ataque de MITM, en el cual nos pondremos entre la víctima y el destino para interceptar todo el tráfico:

NOTA: Tened en cuenta que este tipo de prácticas debe realizarse únicamente en vuestra red interna y siempre y cuando tengáis autorización para hacerlo. 

Pues bien, las herramientas que vamos a utilizar son las siguientes:

Kali Linux 

Ettercap 

SSLStrip 

iptables (para redireccionar el tráfico) 

Windows XP SP3 

arp -a (para comprobar la tabla ARP) 

Antes de empezar os haré una pequeña introducción sobre los scripts y programas que vamos a usar, de manera que sea más fácil entender todo el proceso. No debemos ser máquinas que se limitan a picar los comandos en pantalla. Para aprender realmente debemos entender qué está pasando y qué hace cada una de las ordenes que estamos ejecutando por consola.

Ettercap: Esta es la herramienta que utilizaremos para realizar el sniffing de la red, capturando los paquetes que se intercambien los dos equipos entre los cuales nos interpondremos (de ahí el nombre de MITM Man In The Middle, traducido del inglés como Hombre en el medio)

SSLStrip: Esta aplicación, desarrollada por Moxie Marlinspike, para explicarlo de una manera clara, elimina la "s" del "https" cuando el usuario accede a las paginas en las cuales va a validarse, de manera que él contenido de los campos no viajará cifrado y podremos capturarlos con Ettercap.

iptables: Creo que no hace falta que explique realmente las funciones de iptables, ya que es de sobra conocido y hay multitud de información en la red. Solo decir que en este caso lo usaremos para filtrar todo el tráfico del puerto 80 al puerto de escucha de SSLStrip, de modo que esta aplicación pueda hacer bien su trabajo.

arp -a: Esta ordena la ejecutaremos en la consola cmd de Windows para ver la tabla ARP, la cual modificaremos mediante el ataque con Ettercap.

Lo primero que vamos a hacer es activar el "IP forwarding" de nuestra tarjeta de red. Esto hará que la máquina a la cual estamos atacando no pierda la conectividad, ya que haremos un reenvío de las peticiones.

Podemos hacerlo de diversas maneras, las cuales explico a continuación:

Ejecutamos este comando en nuestra shell:

sysctl -w net.ipv4.ip_forward=1 

O bien hacemos un echo 1 >> /proc/sys/net/ipv4/ip_forward

Ambas cosas tienen el mismo propósito, así que vosotros escogéis el método que más os guste o que os resulte más fácil de recordar.

Seguidamente vamos a aplicar el filtro en iptables para redireccionar todo el tráfico del puerto 80 al puerto 1001, que es el puerto en el que pondremos a escuchar a SSLStrip. Esto lo haremos de la siguiente manera:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 1001

Traducido a una frase entendible para los mortales:

"En la tabla nat añadimos una regla para que todo el tráfico del protocolo TCP cuyo destino sea el puerto 80 se redirija al puerto 1001"

Podemos comprobar que la regla se ha introducida correctamente haciendo lo siguiente:

iptables -L -t nat

Ahora vamos a poner a SSLStrip a la escucha en el puerto 1001, lo cual especificamos con el argumento -l. Con el argumento -f hacemos que cambie el favicon de la página web que visita la víctima, apareciendo en su lugar un icono de un candado para no levantar sospechas.

Dejamos lanzado SSLStrip y abrimos otra terminal, desde la cual empezaremos a usar Ettercap para sniffar el tráfico de la red.

En este caso se trata de un ataque dirigido hacia una IP en concreto de la red, aunque se podría lanzar para toda la red pero cantaría un poco y queremos hacer el menor ruido posible.

Ejecutaremos lo siguiente:

ettercap -T -q -i tarjeta_de_red -M arp:remote /IP_VICTIMA/ /IP_ROUTER/ 

Pues bien, hecho esto ya tenemos lanzado nuestro ataque y ahora únicamente cabe esperar a que la víctima introduzca las credenciales en algún formulario.

Voy a representarlo mediante el acceso a una cuenta de Gmail desde el equipo Windows XP que tengo preparado:

Como veis en la captura, SSLStrip ha hecho bien su trabajo y la víctima está haciendo el login en una página no segura. En cuanto la víctima pulse sobre "Iniciar sesión" veremos lo siguiente en el terminal donde tenemos lanzado Ettercap, y en la cual se empezarán a mostrar las credenciales:

En la captura anterior veréis también varios intentos en Facebook y en Hotmail.

Para ver el efecto que se genera en Windows XP al lanzar este ataque adjunto capturas de la tabla ARP del equipo, la cual envenenamos con Ettercap para que todo el tráfico pase por nosotros. La primera entrada es la tabla ARP envenada, en la cual vemos que la MAC de 192.168.1.1 y de 192.168.1.35 (el equipo atacante) es la misma.

Al cerrar Ettercap se deshace el ataque y la tabla ARP queda con los valores por defecto:

Como veis es bastante sencillo realizar una ataque de este tipo y por supuesto llama muchísimo menos la atención que un ataque de DNS Spoofing o un SCAM, en el cual la víctima puede empezar a sospechar e incluso tirar del hilo para ver quién está atacándole.

Fuente: http://www.unsysadminenapuros.com/2013/08/ataque-mitm-con-ettercap-sslstrip.html

Understanding Man-In-The-Middle Attacks - SSL Hijacking (Ingles)

Buenos días.

En vista que en temas anteriores se ha tratado el tema de robar sesiones, ahora vamos a ver un complemento de la misma verificando "actualmente" estas vulnerabilidades.

Las técnicas anteriores la contra medida era usar el protocolo seguro ssl (https), ahora cual sera?.

El articulo no lo traduzco ya que es fácil de entender, ademas los conceptos informáticos personalmente creo que son internacionales (estándar ingles).

__________________________________________________________________________

Taking a look at SSL spoofing, discussing some theory behind SSL connections and what makes them in/secure.

If you would like to be notified of when Chris Sanders releases the next part in this article series please sign up to our WindowSecurity.com Real Time article update newsletter.
If you would like to read the other parts in this article series please go to

• Understanding Man-in-the-Middle Attacks – ARP Cache Poisoning (Part 1)
• Understanding Man-In-The-Middle Attacks – Part2: DNS Spoofing
• Understanding Man-In-The-Middle Attacks - Part 3: Session Hijacking

Introduction

So far we have discussed ARP cache poisoning, DNS spoofing, and session hijacking on our tour of common man-in-the-middle attacks. In this article we are going to examine SSL spoofing, which is inherently one of the most potent MITM attacks because it allows for exploitation of services that people assume to be secure. I will begin by discussing some theory behind SSL connections and what makes them secure, and then follow by showing how that can be exploited. As always, the last section of the article is reserved for detection and prevention tips.

SSL and HTTPS

Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption.  This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Examples of this include SMTPS, IMAPS, and most commonly HTTPS. The ultimate goal is to create secure channels over insecure networks.
In this article we will focus on attacking SSL over HTTP, known as HTTPS, because it is the most common use of SSL. You may not realize it but you probably use HTTPS daily. Most popular e-mail services and online banking applications rely on HTTPS to ensure that communications between your web browser and their servers in encrypted.  If it weren’t for this technology then anybody with a packet sniffer on your network could intercept usernames, passwords, and anything else that would normally be hidden.
The process used by HTTPS to ensure data is secure centers around the distribution of certificates between the server, the client, and a trusted third party. As an example let’s say that a user is trying to connect to a Gmail e-mail account. This involves a few distinct steps, which are briefly simplified in Figure 1.

Figure 1: The HTTPS Communication Process
The process outlined in Figure 1 is by no means detailed, but basically works out as follows:

1. The client browser connects to http://mail.google.com on port 80 using HTTP.
2. The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
3. The client connects to https://mail.google.com on port 443.
4. The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
5. The client takes this certificate and verifies it against its list of trusted certificate authorities.
6. Encrypted communication ensues.

If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to.

Defeating HTTPS

This process was considered highly secure up until several years ago when an attack was published that allowed for successful hijacking of the communication process. This process doesn’t involve defeating SSL itself, but rather, defeating the “bridge” between non-encrypted and encrypted communications.
Moxie Marlinspike, a well known security researcher hypothesized that in most cases, SSL is never encountered directly. That is, most of the time an SSL connection is initiated through HTTPS it is because someone was redirected to an HTTPS via an HTTP 302 response code or they click on a link that directs them to an HTTPS site, such as a login button. The idea is that if you attack the transition from an unsecured connection to a secure one, in this case from HTTP to HTTPS, you are attacking the bridge and can man-in-the-middle an SSL connection before it even occurs. In order to do this effectively, Moxie created the SSLstrip tool, which we will use here.
The process is fairly straightforward and is reminiscent of some of the attacks we’ve completed in previous articles. It is outlined in Figure 2.

Figure 2: Hijacking HTTPS Communication
The process outlined in Figure 2 works like this:

1. Traffic between the client and web server is intercepted.
2. When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.
3. The attacking machine supplies certificates to the web server and impersonates the client.
4. Traffic is received back from the secure website and provided back to the client.

The process works quite well and as far as the server is concerned it is still receiving the SSL traffic it wants to, it doesn’t know the difference. The only visible difference in the user experience is that the traffic will not be flagged as HTTPS in the browser, so a cognizant user will be able to notice that something is amiss.

Using SSLStrip

The program that makes all of this happen is called SSLstrip and is available from here. This program only runs on Linux so you can download and install it yourself, or if you don’t want to deal with the hassle of installing it yourself you can download and run Backtrack 4 which has it preinstalled.
Once you have access to SSLstrip there are a few perquisite tasks that must be done. First of all, the Linux distribution you are using must be configured for IP forwarding. To do this, enter the command echo "1" > /proc/sys/net/ipv4/ip_forward into a shell.

Figure 3: Enabling IP Forwarding
Once this has been done, we have to force all HTTP traffic that is intercepted to be routed to the port that SSLstrip will be listening on. This is done by modifying the iptables firewall configuration. This is done by using the command iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port .

Figure 4: Configuring IPTables to properly route HTTP traffic
Of course, you will replace with a random port of your choice. After these items have been configured we can run sslstrip and configure it to listen on the port specified with the command sslstrip -l .

Figure 5: Using sslstrip
The last step in this process is to configure ARP spoofing to intercept the traffic of the target host. We did this using Cain and Abel in Windows previously, but in this case we will use the arpspoof utility, which is built into Backtrack 4. The command to do this is arpspoof -i -t .

Figure 6: Configuring ARP Spoofing
Using this command you would substitute for the network interface you are performing these actions on (eth0, eth1, etc), for the IP address of the target client, and for the IP address of the gateway router the target is using.
Once completed you should be actively hijacking any SSL connections being established. From here you can fire up a packet sniffer and collect passwords, personally identifiable information, credit card numbers, etc from the traffic.

Defending Against SSL Hijacking

As discussed previously, SSL hijacking in this manner is virtually undetectable from there server side of the equation because as far as the server is concerned this is just normal communication with a client. It has no idea that it is communicating to a client by proxy. Luckily, there are a few things that can be done from the client’s perspective to detect and prevent these types of attacks.

• Ensure Secure Connections Use HTTPS - When you perform the attack described here it strips the secure aspect of the connection away, which is visible in the browser. This means that if you log into your online banking and notice that it is just a standard HTTP connection there is a good chance something is wrong.  Whatever browser you choose to use, you should ensure you know how to distinguish secure connections from insecure ones.
• Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
• Secure your internal machines - Not to beat a dead horse, but once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.

Wrap Up

This form of MITM attack is one of the deadliest because it takes what we think is a secure connection and makes it completely insecure. If you consider how many secure sites you visit each day and then consider the potential impact if all of those connections were insecure and that data fell into the wrong hands then you will truly understand the potential impact this could have on you or your organization.
If you would like to be notified of when Chris Sanders releases the next part in this article series please sign up to our WindowSecurity.com Real Time article update newsletter.
If you would like to read the other parts in this article series please go to

• Understanding Man-in-the-Middle Attacks – ARP Cache Poisoning (Part 1)
• Understanding Man-In-The-Middle Attacks – Part2: DNS Spoofing
• Understanding Man-In-The-Middle Attacks - Part 3: Session Hijacking

Fuente: 

http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html

Links de interés:

https://www.youtube.com/watch?v=ZSdQESKGyzY --> Tutorial sidejacking.

http://resources.infosecinstitute.com/ssl-attacks/ --> Conceptos.

https://scotthelme.co.uk/advanced-session-hijacking/ -->Windows

http://thehackernews.com/2012/09/crime-new-ssltls-attack-for-hijacking.html --> CRIME

Firesheep: HTTP session hijacking attacks

Firesheep es una extensión disponible para Mozilla Firefox, de fácil instalación, que permite demostrar la técnica de Hijacking sobre el protocolo HTTP, es decir, es una funcionalidad que se añade al navegador, en forma de extensión, que permite demostrar la técnica mediante el robo de la sesión de un usuario autenticado en un servicio web, por ejemplo: facebook, twitter, etc.

A raíz, de la publicación de la extensión firesheep, los populares servicios web, facebook y twitter, se apresuraron a proteger sus servicios frente al Hijacking.

A continuación, explico como funciona esta extensión y como podemos protegernos.

¿Qué es Hijacking?

La técnica de Hijacking, consiste en robar el identificador único de sesión que un servidor web asigna a cada usuario cuando accede a la página web, en concreto cuando introduce el binomio usuario/contraseña. Una vez el usuario realiza el inicio de sesión, el servidor envia una respuesta al navegador, en forma de cookie, con el identificador de sesión y los datos necesarios para que el servidor lleve el control del usuario autorizado. Esta cookie será utilizado por el navegador en sucesivas visitas y peticiones de páginas web, mientras éste se encuentre conectado al servicio.

Una cookie es un fragmento de información que se almacena en el disco duro del visitante de una página web a través de su modo a petición del servidor de la página. Esto permite al servidor llevar el control de los usuarios que visitan la página web. Algunos agentes maliciosos utilizan estan cookies para recoger información sobre los hábitos del usuarios, pero eso es otro tema a tratar en otro artículo.

Un atacante, mediante esta técnica podría acceder a la cuenta del usuario victima sin necesidad de introducir el nombre de usuario y contraseña; Pues habría capturado la cookie de sesión, suplantando la identidad del mismo en el navegador; Es decir, a todos los efectos, para el servidor web el atacante será un usuario autorizado, dejandole acceder por completo a la información de la cuenta del usuario que ha sido "Hijackeado".

¿Cómo funciona firesheep?

Se instala la extensión en el navegador, con la posibilidad de realizar el robo de sesiones (hikacking) a tan solo un click del ratón. La herramienta viene configurada por defecto para robar las sesiones de multiples redes sociales entre las que se encuentran facebook y twitter.

Es especialmente "peligrosa" en redes wifi públicas y abiertas, como por ejemplo: aeropuertos, cafeterías, hospitales, universidades y otros edificios públicos.

El funcionamiento es el siguiente:

Un posible atacante (hombre de negro) con firesheep instalado se conecta a una red wifi pública y abierta, la aplicación firesheep comienza a capturar todo el tráfico de red que circula por la red wifi extrayendo las "cookies" de los servicios facebook y twitter (tal y como se muestra en la imagen). Todos los usuarios son capturados salvo uno de ellos, que en el siguiente apartado explicamos ¿porque no?.

Detalle técnico:
Firesheep es una extensión que necesita instalar las librerías Winpcap para que funcione sobre Windows, además de necesitar permisos de Administrador en Windows Vista o superior. Ya que utiliza la característica de monitoring (modo promiscuo) de la tarjeta de red para escuchar todo el tráfico que circula por el medio al cuál se encuentra conectado. En nuestro caso, una red inalámbrica.

El proyecto firesheep fue abandonado por sus creadores, y solo es posible instalarlo en la versión 3.x de Firefox. No obstante, recientemente el laboratorio Acatel-Lucent Bell, ha publicado un paper titulado Show Me Your Cookie And I Will Tell You Who You Are   (Muestrame tus cookies y te diré quien eres) explica toda la información que puede ser extraída de nuestras cookies de session en google. Este laboratorio ha retomado el proyecto de firesheep incluyen la capacidad de capturas las Cookies de sesión de Google.

¿Cómo protegernos?

Esta técnica, hijacking, así como la extensión firesheep es inútil cuando se cifra la conexión de extremo a extremo, es decir utillizando HTTPS. 

Recomendación: Activar la navegación segura (HTTPS) en el servicio para la utilice siempre y por defecto.

De hecho, si disponéis de una cuenta en facebook, en el menu de configuración puede configurarse para que por defecto se utilice HTTPS para todas las comunicaciones con el servicio.

Para proteger facebook de esta herramienta debeís de ir a configuración de la cuenta, en el menú de Seguridad, activar la "Navegación Segura".

Activar Navegación Segura en Facebook.

Para proteger vuestra cuenta de twitter, ir a configuracion de cuenta, y hacia el final, Activar el HTTPS.

Activar Navegación Segura en Twitter.

Utilizar la navegación segura (HTTPS), nos permite protegernos frente a las técnicas de hijacking, y la captura de información sensible cuando se utilicen redes wifi públicas y desprotegidas. Siendo recomendable, utilizarlo siempre independientemente de la seguridad de la red a la que estés conectado.

¿Se puede detectar Firesheep?

Ahora que estas protegido, configurando los servicios web para la navegación segura (HTTPS), surge una pregunta ¿Podemos saber si alguién esta utilizando Firesheep en una red wifi pública y abierta? La respuesta es SI.

Existe una extensión de Firefox, Blacksheep basada en el código fuente de Firesheep. Esta extensión (add-ons) es capaz de detectar si alguién esta utilizando Firesheep, para ello cada X minutos configurables (5 min por defecto) simulará conexiones HTTP con datos falsos a los sitios que Firesheep es capaz de manejar. De esta forma  blacksheep rastreará la red a la que nos encontramos conectados en busca de indicios y trazas de intentos de conexión de firesheep utilizando los valores falsos simulados por blacksheep.

En el caso de que sea detectado, la extensión nos alertará de que efectivamente existe alguién ejecutando Firesheep.

Conclusiones

Siempre que sea posible se debe de utilizar y/o configurar el servicio web que utlizamos para que se posible el acceso con navegación segura (HTTPS). 

Descargas:

Extensión Firesheep
Extensión Blacksheep

Referencias:
Firesheep
Extensión firesheep, hackear cuentas de facebook a un click en GenBeta.es
Novedades en Firesheep en Dragonjar.org

NOTA:
El contenido de este artículo es meramente informativo, no me hago responsable del uso que de él se pueda hacer.

Fuente:
http://www.seguridadparatodos.es/2011/09/firesheep-http-session-hijacking.html

Links de interés:

http://www.el-palomo.com/2012/05/session-hijacking-secuestro-de-sesiones-va-droidsheep/ --> Tutorial
http://www.technosavvypr.net/tag/http-session-hijacking-attacks/
https://github.com/codebutler/firesheep/downloads --Descarga
https://support.microsoft.com/kb/2647902/es --Contramedida
http://www.oni.escuelas.edu.ar/2009/ENTRE_RIOS/1457/hijacking.htm --Conceptos básicos

WDivulge, Descubriendo carpetas y archivos ocultos

En las auditorías webs, es esencial poder usar alguna herramienta del tipo “enumeración”. Esto nos sirve para encontrar paneles de administración, directorio con información sensible. E incluso directorios con permisos incorrectos que permitan listar archivos.

Descargamos la herramienta y vemos que listas de archivos va a buscar.

darkmac:lists marc$ more files.txt“pictures”[###]\”.jpg”“DCP_”[####]\”.jpg”“IMG_”[####]\”.jpg”“”[##]\”.jpg”“dsc”[#####]\”.jpg”“dscn”[####]\”.jpg”“mvc-”[###]\”.jpg”“mvc”[#####]\”.jpg”“P101″[####]\”.jpg”“IMG_”[###]\”.jpg”“IMAG”[####]\”.jpg”“_MG_”[####]\”.jpg”“dscf”[####]\”.jpg”“pdrm”[####]\”.jpg”“IM”[######]\”.jpg”“EX”[######]\”.jpg”“pict”[####]\”.jpg”“P”[#######]\”.JPG”“IMGP”[####]\”.JPG”“PANA”[####]\”.JPG”“Image(“[##]\”).JPG”“DSCI”[####]\”.JPG”“PICT”[#####]\”.jpg”“HPIM”[####]\”.jpg”“DSCN”[####]\”.jpg”“DSC”[#####]\”.jpg”“IMG_”[#####]\”.jpg”darkmac:lists marc$

Podemos modificar esta lista y añadir las nuestras.

Lanzamos la herramienta contra un servidor web en un entorno controlado.

La petición que hará la herramienta es la siguiente:

“GET /pictures298.jpg HTTP/1.1″

Si queremos ver que peticiones se están originando realmente, podemos ver los logs de la parte de servidor

Como véis la herramienta va probando las distintas combinaciones, si por ejemplo quisiéramos bloquear este fuzzer, podríamos configurar algo como:

#Block scanners      BrowserMatch ^wdivulge deny_host     Deny from env=deny_host  

Ya tenemos una herramienta mas para nuestro arsenal!

Fuente: http://www.flu-project.com/2013/04/wdivulge-descubriendo-carpetas-y_1.html