Saturday, June 14, 2008
What is ARP Poisoning ?
In an Ethernet network computers communicate with each other via Ethernet (MAC (Media Access Control)) addresses. So, there is a mechanism needed for matching of IP addresses with the addresses in an ethernet network. The mechanism is called ARP (Address Resolution Protocol). What ARP does is exactly what most people do, when they have to find Mister X in a crowd of people - they shout loud enough, so that everyone can hear them and expect Mister X to answer, if he is there. When he answers, we will know who is he.
When ARP wants to know whats the Ethernet address matching a given IP address it uses an Ethernet technic, called BROADCASTING, with which the datagram is addressed to all the workstations in the network. The broadcast-datagram sent by ARP contains a request for the IP address. Every computer, received that request compares the requested address with its own IP address and if they match, it sends an ARP reply back to the asking computer. After rreceiving the reply, the asking computer can get the Ethernet address of the computer it is looking for, from his reply. After the computer finds an Ethernet address, he stores it in its ARP cache (ARP table), so he won't need to look for it the next time he wants to send a datagram to the same address. However, it is not good this information to be stored forever (the Ethernet adapter of the other host may be replaced for some reasonm and the entry for the computer's IP in the ARP cache will become invalid). So the entries in the ARP cache expire after a period of time.
What's the difference between switch and hub?
The switches (hubs) don't only provide more connect points to the network - they're also retransmitters of the signal. However, the hub just retransmits the data received from one port to all the other ports so no need to poison, as you get the datagram anyway. Normally, the network adapter compares the destination Ethernet address of the packets, and compares it with it's own Ethernet address. If they match - the data is accepted. If they don't - it just drops the packets. You can put your network adapter in promiscuous mode (which is exactly what Ettercap does) and get all the packets. The switch does the things in a more 'elegant' way. It has a simple CAM (Channel Access Method) table, which is a simple mapping of Ethernet addresses and ports. When a datagram comes through a port, the switch remembers the source Ethernet address of the datagram and stores it in the cam table for the given port, so when a datagram arrives for this computer, it doesn't retransmit it to all ports, but only to this one, which is bound to the Ethernet address of the receiver in the CAM table. If no Port Security, the CAM table is dynamically updated (e.g. if you want to connect to another port, if you change your network adapter etc.). Thus, we can change the CAM table and map another Ethernet address to our port. This technique is called Port Stealing and is discussed in another topic.
Now about the poisoning:
Most operating systems will replace an entry in their ARP cache even if they haven't sent and ARP request before. That allows a MITM (Man-In-The-Middle) attack to be performed. For example, lets say we have 2 computers, with Ethernet addresses AA:AA:AA:AA:AA:AA for computer A, and BB:BB:BB:BB:BB:BB for computer B and IP addresses 10.10.0.1 for computer A and 10.10.0.2 for computer B. Now we want to perform MITM attack. We are computer C with Ethernet address CC:CC:CC:CC:CC:CC and IP address 10.10.0.3. So we send and ARP reply to computer A, saying that we have IP address 10.10.0.2. Computer A updates its ARP cache and since we have an Ethernet address CC:CC:CC:CC:CC:CC, the entry in his ARP cache for 10.10.0.2 is bound to our Ethernet address. Now when computer A wants to send a datagram to computer B, it checks first the ARP cache, to see if computer B's Ethernet address is already there. Since th packet is for 10.10.0.2 (computer B's IP address), computer A founds that the Ethernet address for computer B is CC:CC:CC:CC:CC:CC (out Ethernet address) and sends the datagram to us. Computer A is poisoned. We do the same to computer B - it has an ARP entry for 10.10.0.1 (computer A's IP address) bound to CC:CC:CC:CC:CC:CC (our Ethernet address), so when it sends datagrams to computer A, these datagrams come to us. For the communication between computer A and computer B to continue uninterrupted, we need to forward the packets to their original destination. So when we receive a packet for a computer A - we forward it to computer A, when we receive a packet for computer B - we forward it to computer B. In Linux, for this to works, you can use the simple kernel forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward) or use a more complex one, that Ettercap and some other tools use, which even allows you to perform a MITM attack on a SSL connection.
Click here for more information about ARP
Counter measures for ARP poisoning :
Some operating systems like Solaris do not accept ARP replies without first initiating an ARP request, so they are not vulnerable to this attack.
In this case, an ICMP spoofed packet (ping) is used. The goal is, to get a valid entry in victim's ARP cache, because when they receive an ARP reply from you they will first check their cache to see if you're already there and if you're not - they simply wont add you at all. So you send each victim a ping with source your own Ethernet address and the other victim's IP address. In the case mentioned above, you ping computer A with source IP address 10.10.0.2 and Ethernet address CC:CC:CC:C:CC:CC and computer B with source IP address 10.10.0.1 and Ethernet address CC:CC:CC:CC:CC:CC. Once you gor yourself in their ARP cache, you can poison normally.
Tuesday, June 3, 2008
GENERATING A CERTIFICATE REQUEST FROM A WINDOWS 2003 SERVER MACHINE AND AUTHORIZING IT FROM OPENSSL CA-SERVER.
After the installation of IIS. Go to the Internet Information Services Manager . Select the website where we require to install the certificate. then right click on the default website. Then select directory security tab.
On the Directory Security tab, click Server Certificate
Click Next and select Create A New Certificate
Select Prepare The Request Now, But Send It Later and click Next
Type a name for the certificate and bit length, and then click Next.
Type your organizational name and organizational unit in the box provided and click Next.
Enter your Web server name and click Next.
In the next dialog box, provide some geographical information and click Next.
Enter the location and the name for the certification request, then click Next.
Verify the information and click Next, and then click Finish.By default The request file will be saved in the (c:\>) drive. The file type will be (.txt) format.Copy it and take it to the OPENSSL CA server .
In the OPENSSL server paste it in the CA-server directory. Rename it to (newreq.pem). (because the OPENSSL command to sign a certificate request takes only this name so it must be newreq.pem and will be in the current directory).
Now, lets sign the 'certificate request':
$sh /usr/lib/ssl/misc/CA.sh -sign ( The CA.sh file is automatically stored in that specified loacation at the time of CA installation).
After the file sign process completed the certificate is created named (newcert.pem ) in the current directory.
This certificate will not be supported by a windows 2003 server. You have to again rename it to .cer file.
Take the .cer file to the windows machine. Again select the Internet information service manager(IIS).
Go to the Internet Information Services Manager .
Select the website where we require to install the certificate then right click on the default website.
Then select directory security tab.
On the Directory Security tab, click Server Certificate.
select process the pending request and install it.
Then browse and select the new certificate and click next then finish. The newly installed certificate will be installed. You can see the certificate by clicking on the view certificate button.
Under Debian, the following packages have to be installed via apt-get:
* libapache-mod-ssl (will automatically be installed by apache-ssl)
The SSL certification process consists of three basic steps:
* If not done already, create a certificate authority (CA), which we will use to sign our own
* Create a new certificate request
* Sign the request with our CA to obtain a valid certificate.
Create a certificate authority
The OpenSSL package comes with a default openssl.cnf file under /usr/lib/ssl/openssl.cnf.
We will edit the default values slightly, ie. we change the default path from demoCA to
ourCA. To do so, copy /usr/lib/ssl/openssl.cnf to /etc/ssl/openssl.cnf and change the line
dir = ./demoCA
dir = /etc/ssl/ourCA
For security reasons, you will have to create the necessary file and directory structure
manually. In particular, you have to create the following folders and files:
* /etc/ssl/ourCA/index.txt (empty file)
* /etc/ssl/ourCA/serial (file containing "01" as the first and only line)
We can now tell openssl to create a new certification authority for us:
#openssl req -new -x509 -keyout /etc/ssl/ourCA/private/cakey.pem -out
/etc/ssl/ourCA/cacert.pem -config /etc/ssl/openssl.cnf
You will be asked a few questions about the new CA. Just enter information that makes sense
and is valid. Also, choose a good passphrase, since you'll have to remember it every time
you want to validate and sign a new certificate request.
Issue a certificate request
We are now ready for the interesting part of this tutorial. To create a certificate request, execute
#openssl req -new -keyout newkey.pem -out newreq.pem -days 365
OpenSSL will again ask you a few questions. Make sure that you enter the hostname of your SSL
server as "Common Name". This is very important and things will break if you don't do it.
If everything went fine, this will give you two new files in the directory where you ran this
command. The first is our certificate private key and the second file (newreq.pem) is the c
ertificate request for the CA.
There is one obstacle with the private key in the current form: It requires a passphrase to be
used. That means, if you want Apache to use this SSL key, you'll have to supply the passphrase
at Apache's startup. This is not very handy, for sure. We can however, remove the passphrase by
#openssl rsa -in newkey.pem -out nopwkey.pem
You will be asked for the private's key passphrase. If things went right, you will have a new
private key called nopwkey.pem, which is not passphrase protected anymore.
To let a CA sign a certificate request, they need both, our private key and the certificate
request. We can combine both into one file by cat'ing them together:
#cat newreq.pem nopwkey.pem > new.pem
Signing the certificate
The last step consists of the actual signing process. Just issue
#openssl ca -policy policy_anything -out newcert.pem -config /etc/ssl/openssl.cnf
in the same directory where your certification request files are stored. You will first be asked for the CA passphrase (now you know why it is important to remember it!) and you can then either sign or reject the certificate.
You should now copy newcert.pem and nopwkey.pem to some convenient place, since Apache will only need those two files to operate in SSL mode.
Under Debian, the SSL enabled Apache version has its own configuration file, available under /etc/apache-ssl/httpd.conf. Edit and change or add the following lines:
SLCertificateFile /path/to/newcert.pem //This is our signed certificate
SSLCertificateKeyFile /path/to/nopwkey.pem //This is our unencrypted private key.
Start Apache-SSL by executing,