Thursday, October 25, 2007

DSNIFF

This article was taken from this website for our information and quick guide :
http://www.ouah.org/dsniffintr.htm


Penetration Testing with dsniff
Christopher R. Russel
February 18, 2001

What is dsniff?

The ability to access the raw packets on a network interface (known as network sniffing), has long been an important tool for system and network administrators. For debugging purposes it is often helpful to look at the network traffic down to the wire level to see exactly what is being transmitted. Dsniff, as the name implies, is a network sniffer - but designed for testing of a different sort. Written by hacker Dug Song, dsniff is a package of utilities that includes code to parse many different application protocols and extract interesting information, such as usernames and passwords, web pages being visited, contents of email, and more. Additionally, it can be used to defeat the normal behaviour of switched networks and cause network traffic from other hosts on the same network segment to be visible, not just traffic involving the host dsniff is running on.

These capabilities alone are enough to attract interest, but in its latest version (2.3 as of this writing, released late December 2000), it includes new programs to launch man-in-the-middle attacks on the SSH and HTTPS protocols, which would allow viewing of the traffic unencrypted, and even the possibility of taking over interactive SSH sessions. These new abilities have caused some uproar in the security community, however this document is not an ethical or technical debate; I only hope to show dsniff in action to help people understand its capabilities and therefore be better able to see weaknesses in their own network.

The dsniff Package

To give you an idea of exactly what dsniff can be used for, here is a list of tools included in the dsniff package, and a brief description of their function, partially taken from the dsniff README:
arpspoof redirects packets on a LAN to defeat the host-isolating behaviour of the switch.
dnsspoof forges replies to DNS queries.
dsniff password sniffer with ability to handle FTP, Telnet, SMTP, HTTP, POP, poppas, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL authentication info.
filesnarf saves files sniffed from NFS traffic.
macof causes LAN switch to fail-open (ie. Act as a hub and broadcast traffic to all hosts).
mailsnarf saves email messages sniffed from SMTP and POP traffic.
msgsnarf saves messages and chat sessions sniffed from most Instant Messenger protocols and IRC.
tcpkill kills specified in-progress TCP connections.
tcpnice slows down specified TCP connections.
urlsnarf reports URLs sniffed from HTTP traffic.
webspy sends sniffed URLs to your local Netscape browser, allowing you to browse in real-time along with the target.
sshmitm proxies and sniffs SSH traffic redirected by dnsspoof, captures password logins and optionally allows hijacking interactive sessions.
webmitm proxies and sniffs HTTP/HTTPS traffic redirected by dnsspoof, capturing SSL-encrypted logins and form submissions.



Penetration Testing

Dsniff’s author refers to it as "a collection of tools for network auditing and penetration testing", and it is from this perspective that I’ll demonstrate putting it to use.

Penetration testing is a form of security auditing, where you attempt to break in to a network - with the consent of those in charge of the network – trying to find weaknesses and vulnerabilities you were not aware of before, which hopefully leads to fixing those security holes. In my tests with dsniff, I used my own private home LAN. Unfortunately I do not have a switch at my disposal, so some of the switch-defeating mechanisms were not tested. However, I have seen some of these techniques used successfully for other purposes (such as clustering) and I have no doubt they work unless extraordinary precautions and limitations are enforced in the design of the network architecture.

WARNING: If you plan on testing dsniff on a network you do not own, be sure you have written permission from appropriate authorities, as password and message capture are extremely sensitive topics and probably illegal without precise guidelines.

In the following sections, we will see how dsniff can be used in several different attack scenarios. It is worth noting that although most of the techniques used by dsniff are not new, the fact that they are contained in a single easy-to-use package increases concern since it brings previously complex and difficult attack scenarios within the capability of the average script kid.

Attack Preliminaries: Accessing the Target Network Traffic

Before dsniff can be used on a LAN, naturally you first need root or administrator access to a host connected to the LAN. The dsniff toolkit is known to run on Linux, OpenBSD, FreeBSD, and Solaris. It is likely to be possible to port it to other UNIX platforms as well. There is even a version of dsniff for Windows NT, although it is older and lacks some of the features in version 2.3.

Once dsniff is compiled and ready on the attacking host within the LAN, there are three different possibilities for accessing the network traffic:

1. The LAN uses a hub: In this case, nothing extra needs to be done, all network traffic going to any host on the LAN is visible to all other hosts on the LAN.

2. The LAN uses a switch: In the switched architecture, all hosts are connected to the switch on their own isolated port, and the switch keeps track of which host is on which port, and then only sends traffic intended for that host to its port. However, this is mainly intended to increase performance (since each host gets a dedicated connection instead of being shared like with a hub), and the security benefit is mostly a side effect. Therefore, it is easy to defeat by simply confusing the switch so it cannot be sure which host is on which port. Most switches respond to this condition by "failing-open", which means it begins to act like a hub and send all traffic to all ports. This will also cause network performance to suffer greatly, which might be noticed by others on the network. To accomplish this:

* Use macof to flood the network with random MAC addresses, which will overflow the internal translation table of the switch. Without an accurate translation table, the switch can no longer know which host is on which port, which leaves the switch with no choice but to forward all packets to all ports (like a hub would do). This is known as "fail-open". If the switch does not fail-open, the only other option is to "fail-closed" in which case no network traffic will get through to any host on the LAN at all. Although this latter case is not an option for most equipment, it would be an especially easy denial-of-service attack.

Note: Most switches can be configured to allow only one, fixed, MAC address per port – In that case, macof would have no effect, but it is a difficult arrangement to manage.

3. The LAN uses a switch and you wish to target a specific host: If you do not want to sniff all the traffic on the LAN but only wish to target a specific host on it, you can leave the switch alone and just confuse that specific host into thinking you are the gateway/router. Therefore any traffic that host wishes to send to outside the LAN will go to your host first. This is the most clandestine form of sniffing, since it only affects the target host, and only in the way you specify, therefore it is not likely to be noticed by others. To implement this:

* Since we are targeting a particular host and not the entire LAN, we only need to cause the target host to misdirect its network packets to our MITM attack host (on the LAN). To accomplish this, we use arpspoof to send fake ARP packets to the target host, telling it that the MITM attack host is the gateway. That way, any traffic it tries to send outside the LAN will actually go to the MITM attack host. Before doing this, we have to tell the attack host to forward packets on to the real gateway otherwise it will be noticed quickly that the target host can no longer communicate outside the LAN.

Attack One: Password Sniffing

Once the network traffic from the target host, or the entire LAN, has been made available to the sniffing host using the techniques above, it is a simple matter to start the dsniff program, which will then automatically detect and capture interesting information from the traffic. In fact, even a normal sniffer will capture the traffic just as well, but normal sniffers do not have the built-in knowledge of various application protocols that dsniff has.

Attack Two: Message and File Capture

Using msgsnarf and filesnarf, capturing email messages and files transferred via NFS are just as easy as capturing passwords. Both these programs do the work of interpreting the relevant network traffic to get results. msgsnarf saves the captured email in an mbox-format file for standard UNIX mail-readers to use. filesnarf saves the captured files in the directory it is run from.

Attack Three: URL capture

urlsnarf is similar to the other tools mentioned so far, but specifically written to capture HTTP requests and log the URL being referenced. webspy is along the same lines, but instead of logging the URL, it actually commands your local Netscape web browser to follow the URLs as they are sniffed, allowing you to surf along with the target in real-time. As the README says, this is "a fun party trick."

Attack Four: Man-in-the-Middle

All the previous attacks are considered to be passive since they do not involve altering the behaviour of the systems being targeted (causing the switch to fail-open can be seen as an active attack on the switch, but the network traffic is merely observed, not intercepted or modified en route). On the other hand, a Man-in-the-Middle attack is an active attack since the attacking host plays an important role managing the network traffic between the source and destination targets.

A MITM attack is when the target host is fooled into thinking it is connecting to a desired destination host when in fact it is connecting to the attacker host, which then handles the connection to the desired destination host and proxies traffic between the two from that point on. In this way, the attacker host now completely controls the connection and can view and/or modify information passing between the connection it has forged with the source and destination hosts.

This type of attack is particularly effective when dealing with connections encrypted with public-key cryptography. If you are not familiar with this subject, one good overview is at the Netscape developer site. Public-key cryptography is an extremely effective encryption concept, but it does require that connecting host have a copy of the public key from the host being connected to. If the connecting host does not already have the public key from a previous connection with that host then it will have to get it from somewhere – with protocols such as SSH, the destination host will supply its public key itself. MITM attacks take advantage of this by intercepting the initial connection attempt and substituting their own "forged" public key (which they have the private key for and can therefore decrypt the data). If the user at the connecting end has never seen the correct public key before, it is likely the forgery will not be noticed and the attack will be a success. Even in the case where the user does have the correct public key to compare with it, often it just results in a small warning being printed saying the key has changed and if they want to continue connecting. Most users will simply click OK without another thought. This is not the fault of the protocol. This is a problem with user education and also with implementations that print simple warnings when an event as serious as a key change occurs.

Setting up the Attack

Executing the MITM attack is more complex than the others, but dsniff’s tools make it almost as easy. In this scenario there are three systems (plus the gateway) involved in our sample network:

Client Host: Windows, with PuTTY installed (a free Windows SSH program)

IP=192.168.1.77 (MAC address irrelevant)

MITM Attacker: (running dsniff)

MAC=08-00-BA-DD-FE-ED, IP=192.168.1.210

Destination: MAC address irrelevant, IP is outside 192.168.1.x

Hostname = "external.host.com"

Gateway (and DNS server): Serves 192.168.1.x LAN

MAC=08-00-DE-AD-BE-EF, IP=192.168.1.1

1. We have to fool the client (target) host into thinking the MITM host is the gateway. This is done using arpspoof. At the start, you can see the client has the correct ARP entry for the gateway:

[Client] C:\WINDOWS>arp -a
Interface: 192.168.1.77 on Interface 0x2000003
Internet Address Physical Address Type
192.168.1.1 08-00-de-ad-be-ef dynamic

Running arpspoof on the MITM host will change that. We must remember to enable ip-forwarding so the MITM host will hand off the packets to the real gateway. To minimize the visibility of this attack, we will specifically target the client system:

[MITM Host] % Arpspoof –t 192.168.1.77 192.168.1.1

Now we can check the client’s ARP table again to see if it worked:

[Client] C:\WINDOWS>arp -a
Interface: 192.168.1.77 on Interface 0x2000003
Internet Address Physical Address Type
192.168.1.1 08-00-ba-dd-fe-ed dynamic

You can see that this is the MAC address of the MITM host and all traffic destined for the gateway from the client will go to the MITM host instead. This phase of the attack is complete.

Next we need to look for DNS queries in the traffic, and when we find one for a destination host we want to impersonate, we respond to it ourselves instead of passing it on to the real DNS server. We reply with the IP address of the MITM attack host instead of the real IP. We use dnsspoof to respond to any request for hostname "external.host.com", which has an IP-address outside the 192.168.1.x network. We can be very specific by creating an /etc/hosts-format file specifying which hostnames to fake, but by default dnsspoof will just fake ALL hostname lookups which is fine for our example:

[MITM Host] % dnsspoof

Now to check that it is working on the client:

[Client] C:\WINDOWS>ping external.host.com
Pinging external.host.com [192.168.1.210] with 32 bytes of data:



It is working, external.host.com is reported to have the IP of the MITM host.

The Target host will then begin the connection to the hostname the user specified, but to the IP address WE specified (192.168.1.210), which means the MITM host. If the application being used is SSH or a web browser using HTTPS, we can use sshmitm or webmitm to handle both those protocols (incidentally, sshmitm only supports the SSH1 protocol, not the newer SSH2 protocol, although it is still subject to the same trust requirement for the key exchange just as any public-key encryption is). sshmitm or webmitm sends a forged public-key to the target host, and then also begins a connection of its own to the real destination server. Once this is done, we actually have two connetions; one going from the target/victim host à MITM host, and another going from the MITM host à real destination host. At this point the MITM host can proxy the traffic between the two hosts, decrypting and re-encrypting all traffic in the process, all the while monitoring the decrypted traffic. Additionally, since they are two independent connections, we can always terminate the target hosts’ connection and simply take over the interactive session from the MITM à destination host ourselves.

To verify this is working, we try connecting to example.host.com using PuTTY on the client host. This is a host we’ve connected to before, so we already have a copy of the real public key. What we get is a warning message:

WARNING – POTENTIAL SECURITY BREACH!

The server’s host key does not match the one PuTTY has stored in the registry



Then the user has three options: Yes, No, and Cancel. Yes and No both continue the connection (Yes updates the stored key, No does not), and only Cancel stops the connection. Yes is the default choice if the user just hits enter without reading or thinking.

At least PuTTY is good about warning the user in clear terms. Some other clients such as SecureCRT (a commercial client) do not explain what the implications of the warning are at all and simply ask the user if they wish to continue connecting (defaulting to yes). UNIX SSH clients can be configured for "strict" host key checking which will automatically disallow any connecting to a host who’s host key has changed. This forces the user to manually remove the existing known-host key if they are sure there is no security problem.

HTTPS traffic can be attacked in a similar way, using webmitm instead of sshmitm.

Summary

It is hard to study dsniff without being at least slightly troubled by the ease at which you can gather passwords, emails, files, and eavesdrop on encrypted connections, even on switched networks. This paper has demonstrated some of these cases and hopefully provides some of the perspective on these problems that real penetration testing provides. Of course, these vulnerabilities are not the fault of dsniff or its author and if dsniff causes a greater concern for the basic security of network architectures, application protocol design, and public-key infrastructure then it will have done a service for us all.

References:

Drury, Jason. "Sniffers: What they are and How to Protect From Them." 11 November 2000. http://www.sans.org/infosecFAQ/switchednet/sniffers.htm

Song, Dug. "dsniff."
http://www.monkey.org/~dugsong/dsniff/

Seifreid, Kurt. "The End of SSH and SSL? Follow-up." 22 December 2000.
http://www.securityportal.com/seifried/sslssh-followup20001222.html

Song, Dug. "dsniff Frequently Asked Questions."
http://www.monkey.org/~dugsong/dsniff/faq.html

Saso. "Re: Cisco Catalyst switches." 13 June 2000.
http://archives.neohapsis.com/archives/vuln-dev/2000-q2/0916.html

Netscape Communications, Inc. "Introduction to Public-Key Cryptography."
http://developer.netscape.com/docs/manuals/security/pkin/contents.htm

Tatham, Simon. "PuTTY: A Free Win32 Telnet/SSH Client."
http://www.chiark.greenend.org.uk/~sgtatham/putty/

Wednesday, May 09, 2007

Popup Message Using SMBclient

Send popup message using smbclient:

smbclient -M NETBIOSNAME -U FROMNAME

where -U Fromname is an optional

findsmb


This will give you a list of all the smb clients in your subnet.

This gives you the IP:
nmblookup -R [NETBIOS name]

This gives you the NETBIOS name:
nmblookup -A [IP]

Wednesday, March 14, 2007

NCSA Authentication

You can configure Squid to prompt users for a username and password. Squid comes with a program called ncsa_auth that reads any NCSA-compliant encrypted password file. You can use the htpasswd program that comes installed with Apache to create your passwords. Here is how it's done:

1) Create the password file. The name of the password file should be /etc/squid/squid_passwd, and you need to make sure that it's universally readable.

[root@example tmp]# touch /etc/squid/squid_passwd
[root@example tmp]# chmod o+r /etc/squid/squid_passwd
2) Use the htpasswd program to add users to the password file.
You can add users at anytime without having to restart Squid.

In this case, you add a username called karim:

[root@example tmp]# htpasswd /etc/squid/squid_passwd karim
New password:
Re-type new password:
Adding password for user karim
[root@example tmp]#

3) Find your ncsa_auth file (make sure ncsa_auth is a executeable file.)

[root@example tmp]# find / -name ncsa_auth
/usr/lib/squid/ncsa_auth
/usr/local/squid/bin/ncsa_auth
[root@example tmp]#

4) Edit squid.conf; specifically, you need to define the authentication program in squid.conf, which is in this case ncsa_auth.

Next, create an ACL named ncsa_users with the REQUIRED keyword that forces Squid to use the NCSA auth_param method you defined previously. Finally, create an http_access entry that allows traffic that matches the ncsa_users ACL entry. Here's a simple user authentication example; the order of the statements is important:
(Note : Don't forget to restart your squid service)

#
# Add this to the auth_param section of squid.conf
#
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

#
# Add this to the bottom of the ACL section of squid.conf
#
acl ncsa_users proxy_auth REQUIRED

#
# Add this at the top of the http_access section of squid.conf
#
http_access allow ncsa_users


Tuesday, March 13, 2007

Cron Jobs



In the /etc directory you will probably find some sub directories called
'cron.hourly', 'cron.daily', 'cron.weekly' and 'cron.monthly'. If you place
a script into one of those directories it will be run either hourly, daily,
weekly or monthly, depending on the name of the directory.

If you want more flexibility than this, you can edit a crontab (the name
for cron's config files). The main config file is normally /etc/crontab.
On a default RedHat install, the crontab will look something like this:


root@example # cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

The first part is almost self explanatory; it sets the variables for cron.

SHELL is the 'shell' cron runs under. If unspecified, it will default to
the entry in the /etc/passwd file.

PATH contains the directories which will be in the search path for cron
e.g if you've got a program 'foo' in the directory /usr/cog/bin, it might
be worth adding /usr/cog/bin to the path, as it will stop you having to use
the full path to 'foo' every time you want to call it.

MAILTO is who gets mailed the output of each command. If a command cron is
running has output (e.g. status reports, or errors), cron will email the output
to whoever is specified in this variable. If no one if specified, then the
output will be mailed to the owner of the process that produced the output.

HOME is the home directory that is used for cron. If unspecified, it will
default to the entry in the /etc/passwd file.

Now for the more complicated second part of a crontab file.
An entry in cron is made up of a series of fields, much like the /etc/passwd
file is, but in the crontab they are separated by a space. There are normally
seven fields in one entry. The fields are:


minute hour dom month dow user cmd

minute This controls what minute of the hour the command will run on,
and is between '0' and '59'
hour This controls what hour the command will run on, and is specified in
the 24 hour clock, values must be between 0 and 23 (0 is midnight)
dom This is the Day of Month, that you want the command run on, e.g. to
run a command on the 19th of each month, the dom would be 19.
month This is the month a specified command will run on, it may be specified
numerically (0-12), or as the name of the month (e.g. May)
dow This is the Day of Week that you want a command to be run on, it can
also be numeric (0-7) or as the name of the day (e.g. sun).

user This is the user who runs the command.
cmd This is the command that you want run. This field may contain
multiple words or spaces.

If you don't wish to specify a value for a field, just place a * in the
field.

e.g.
01 * * * * root echo "This command is run at one min past every hour"
17 8 * * * root echo "This command is run daily at 8:17 am"
17 20 * * * root echo "This command is run daily at 8:17 pm"
00 4 * * 0 root echo "This command is run at 4 am every Sunday"
* 4 * * Sun root echo "So is this"
42 4 1 * * root echo "This command is run 4:42 am every 1st of the month"
01 * 19 07 * root echo "This command is run hourly on the 19th of July"

Notes:

Under dow 0 and 7 are both Sunday.

If both the dom and dow are specified, the command will be executed when
either of the events happen.
e.g.
* 12 16 * Mon root cmd
Will run cmd at midday every Monday and every 16th, and will produce the
same result as both of these entries put together would:

* 12 16 * * root cmd
* 12 * * Mon root cmd

Vixie Cron also accepts lists in the fields. Lists can be in the form, 1,2,3
(meaning 1 and 2 and 3) or 1-3 (also meaning 1 and 2 and 3).
e.g.
59 11 * * 1,2,3,4,5 root backup.sh
Will run backup.sh at 11:59 Monday, Tuesday, Wednesday, Thursday and Friday,
as will:
59 11 * * 1-5 root backup.sh

Cron also supports 'step' values.
A value of */2 in the dom field would mean the command runs every two days
and likewise, */5 in the hours field would mean the command runs every
5 hours.
e.g.

* 12 10-16/2 * * root backup.sh
is the same as:
* 12 10,12,14,16 * * root backup.sh

*/15 9-17 * * * root connection.test
Will run connection.test every 15 mins between the hours or 9am and 5pm

Lists can also be combined with each other, or with steps:
* 12 1-15,17,20-25 * * root cmd
Will run cmd every midday between the 1st and the 15th as well as the 20th
and 25th (inclusive) and also on the 17th of every month.
* 12 10-16/2 * * root backup.sh
is the same as:
* 12 10,12,14,16 * * root backup.sh

When using the names of weekdays or months, it isn't case sensitive, but only
the first three letters should be used, e.g. Mon, sun or Mar, jul.

Comments are allowed in crontabs, but they must be preceded with a '#', and
must be on a line by them self.

Saturday, March 10, 2007

Mutt

Mutt is a mail user agent. We can use this Mutt to send email in a command line. You need to install the Mutt before you can used it.

For Redhat and it equivalent:
up2date mutt

You can check using command rpm -qa if it already install after you up2date it.

Example send email:

mutt -s "Test mail" -a /tmp/file.tar.gz username@yahoo.com < /tmp/mailmessage.txt where:
  • "Test mail" = will be the subject of the email because of -s
  • /tmp/file.tar.gz = will be the attachment file because of -a
  • username@yahoo.com = recipient address
  • /tmp/mailmessage.txt = will be the body or content of the email

Note: make sure your machine are able to connect to outside world if using the external email address and please check also the mail in the bulk or spam mail section.

Monday, February 12, 2007

Managing User And Group From A Command Line #1

useradd - Create a new user or update default new user information
passwd - update a userâs authentication tokens(s)



useradd :

useradd [username] -d [/home/username] -p [password]

Change username with your desired name and -d is for home directory and -p is for password. This is a minimum requirement to create user. You can check it by change to user that you already created using su [username] and using whoami command.

passwd :

[root@foot /]# passwd username
Changing password for user username
New UNIX password:
Retype new UNIX password:

Using command passwd and username that you want to change and type your new password.

Thursday, February 08, 2007

Routing Table

using netstat -rn

Destination Gateway Genmask Flags MSS Window irtt Iface
210.187.61.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.118.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
229.188.33.0 210.187.61.173 255.255.255.0 UG 0 0 0 eth1
236.182.2.0 210.187.61.173 255.255.255.0 UG 0 0 0 eth1
244.189.40.0 210.187.61.173 255.255.255.0 UG 0 0 0 eth1
245.7.87.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
219.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 110.187.61.173 0.0.0.0 UG 0 0 0 eth1

example of routing table in Redhat.

To add Default Gateway;

route add default gw 192.168.111.1 eth0

To add another network segment;

route add -net 111.222.333.0 netmask 255.255.255.0 dev eth0

To remove or delete routing in table;

route del default gw 192.168.111.1 eth0


fx-mails.com