CSG254: Network Security

This week we explore network sniffing, password gathering/cracking, and the basics of network-based attacks. These are some of the simplest and most basic methods (and most common too!) that attackers use to break into modern operating systems and it is essential to understand these mechanisms in order to properly secure a network. In future weeks we will be focusing on OS and application-specific flaws that have both in the past and in the present allowed intruders to obtain local user and super-user privileges on remote systems. But to start with, we focus on flaws at the administrative and network architecture level. Understanding these techniques and the tools used in these exercises should give you a good idea about why administrative policy and proper service configuration and deployment is so important – particularly the use of encrypted communications and good passwords.

As always, any tool mentioned here will be available via ftp from Dastun in the /pub/tools directory. Tools you will need to install for this assignment include:

• Ethereal/WinPcap
• Dsniff/LibNet/LibNids
• FragRouter
• ArpWatch
• LC4 (the artist formerly known as L0phtcrack)
• John the Rippper
• Assorted Dictionary Files
• DumpSec

1. Basics of Network Sniffing:

   1. Hopefully you have used a network sniffer before, either to analyze your local area network or to troubleshoot a connection problem. If you haven’t, familiarize yourself with Tcpdump and Ethereal. Throughout this assignment (and possibly future ones) you will find that it is often advantageous to capture data in Tcpdump and then import the captured packet data into Ethereal for analysis. Why does a user need to be root on a Linux system in order to run a sniffer?
   2. While sniffing network traffic from your Linux system, attempt a login to your Linux FTP server originating from your Windows system. Log in as an established user and update your web page (you configured your FTP server to allow for this in the first lab). Analyze the data you have captured and hand it in as part of this week’s assignment. What do you notice about the session that might be troubling from a security point of view? There are two things, in particular, that you should note about the insecurity of the FTP traffic.

   Optional

   1. How can you use Ethereal to isolate an FTP session like this amidst a storm of other traffic? To discover this you may need to create other concurrent sessions and then play around with the application’s options. Be choosy about what you submit (in other words, only submit the list of packets in 1,b that are actually part of the session and provide the payload-level details of the packets you find interesting).
   2. How would you suggest fixing the relative insecurity of FTP from an administrative point of view? Or telnet, for that matter? Propose an easily deployable solution.
   3. Why do you think a sniffer is one of the most common elements of a root kit that attackers might install on one of your systems once breaking in to it via some other remote exploit? Think of some other common elements of root kits that might be installed by a malicious user, given the opportunity.

2. Sniffing in Modern Networks:

   1. Install Dsniff and play around with it a little. One feature of Dsniff is it’s ability to understand different protocols and specifically listen just for the exchange of certain types of username/password authentication strings. Start a couple sessions as before, while authenticating from the same system Dsniff is running on, and provide the results of the password-grabbing session with your homework. Try protocols other than FTP too, anything that needs to authenticate a user. Be creative and provide these examples in your write-up.
   2. Learn how to create a password-protected section of your web site using htpasswd (Google on this term for more info) to limit access to a new page or directory you create under Apache and try capturing these sessions too. See how Dsniff responds, comment on its effectiveness, and include your results.
   3. Since using htpasswd obviously isn’t enough to truly “secure” a website by itself, move this password protected page you’ve created to an SSL/HTTPS website run on your Linux server. What does this provide for you and would it prevent an attacker from seeing the username/password information in a sniffer (when connecting to the HTTPS site)? NOTE: Don’t take down the regular website, just move the new document to the HTTPS site (run both HTTP and HTTPS).
   4. Start Tcpdump running on your Linux system again. Now, from your Windows system, start an FTP session with dastun. Log in as the anonymous user and retrieve one of the tools. Can you see this traffic in the Linux system’s captured packet data? Why or why not? What is the difference between a hubbed network and a switched one?
   5. Dsniff’s authors suggest a way to see traffic that might not otherwise be seen in these scenarios (switched networks). They provide two tools to assist in this manner. What are they, and how do they work? What are the differences between the two strategies? Set them up, test them, and then retry the experiment in part 1. Provide your conclusions, as well as reasoning if one of them fails to be successful. Hint: you will need to use FragRouter and make sure that IP forwarding option is enabled for one of these scenarios – it is a form of “man in the middle attack”.

   Optional:

   1. Suggest way(s) that we could effectively eliminate this sort of problem 2.e. One idea would be to install ArpWatch and use it to keep track of the ARP/IP pairings and notify you when changes take place. Do this, re-run 2.e and provide the results as part of your homework (NOTE that you should cleanse your ARP cache of the “bad” cached address first by performing some “normal” network communications before re-running 2.e).
   2. 2.f is one way to help detect (and therefore, a first step in preventing) the problem in 2.e from occurring. Another way might be to use static ARP tables on your switches. Discuss whether or not this might be a good idea and in what setting it would be most beneficial.

3. Common E-Mail Insecurities:

   1. Another tool in the Dsniff suite is mailsnarf. Describe what it does and in what scenario it could be troublesome to an administrator.
   2. The answer to the above problem demonstrates what might be seen as a major problem with modern mail protocols. Think about how SMTP could theoretically be modified to be more secure and prevent this sort of problem. Propose a replacement protocol in brief.
   3. Why don’t you think this has already been done? What would be difficult about deploying your proposed replacement protocol in the real world and why hasn’t this happened?
   4. Since your solution for 2.b might be considered impractical (by some, anyway), what could you do in the meantime to keep attackers who have rooted a system on your LAN from reading your email? What is used for “secure mail” today over the existing infrastructure? Contrast this to your answer in 2.b in terms of its relative strengths and weaknesses.

4. IP Spoofing, Man-In-The-Middle, and Session Hijacking Attacks

   1. Describe why an attacker would want to perform IP spoofing and what they could stand to gain by doing this. How would they do this? (draw a diagram in your homework, and remember to think about how they would keep the “real” host from responding too), and why does this make rhosts/rsh a bad idea for network use?
   2. Think of a simple way to install anti-spoof filters at your border routers or firewalls (simple: think of one basic characteristic you wouldn’t want possessed by traffic coming in to your nework and then vice-versa). Why might you also want to prevent source-routed packets to prevent spoofing attempts?
   3. Look at Dsniff’s dnsspoof utility and describe two ways in which this could be used by an attacker maliciously on your network.
   4. In 2.c, you set up an SSL website to help secure your web information. Now using dnsspoof and webmitm (another part of the Dsniff suite), demonstrate (actually perform this on your network and describe the steps in detail in your write-up) how an attacker could perform a man-in-the-middle and capture your authentication information even with this added level of security. This should demonstrate why users need to be wary of certificates not signed by a trusted Certificate Authority. Explain.
   5. Dsniff also has an SSH session hijacking (mitm) utility that can be used in interactive mode with the –I switch. You won’t be able to use sshmitm in class, but explain why not and under what conditions an attacker could. Also, explain how the attack works (use a diagram, accompanied by a brief discussion) and note how SSH detects this and reports it to the user.

   Optional

   1. Do a SSH session hijack. This has not been done with this network but one that is like it. Describe what you did in detail. Then state if if you where able to do a SSH session hijack. If it didn't work then state reasons why you think it didn't work. Note: This has not been done with our network, just 1 similar to it.
   2. Describe how to get around the certificate warning issue. If you need a certificate assume that a trusted CA is willing to sign your random certificate using information it can find out from public sources like business name, related server information. I.E. You can not fool the trusted CA into believing that you are IBM or some other company but yours. Hint: There are at least 3 ways to do this and two of these ways deal with the CN of the certificate given.

5. Password Auditing (Windows platform):

   1. Use LC4 to audit the passwords on your Windows 2000 system. Explain the differences between brute force, dictionary, and hybrid modes and what the relative advantages/disadvantages of each are. Run both a pure dictionary attack as well as a hybrid audit on your own system and see what the results are. Include your results with the homework.
   2. The Windows password database is called the SAM. As a local administrator on the system, you of course can audit your user’s passwords using a tool like LC4 at any time. But if you weren’t the administrator, how could you retrieve a copy of this? You’ll have to do some reading/exploring to find out (hint: the simplest way is through a silly administrative error during the backup process).
   3. In Windows 2000, the SAM is SYSKEYED for additional security. What does this mean?
   4. Why are the older LANMAN interpretations of the passwords weaker and how does the support for backwards-compatible passwords in the current versions of Windows 2000 constitute a weakness? Where are these passwords used and how could this insecurity be eliminated?

   Optional

   1. Discuss whether or not you think it is a good idea to force periodic password changes (30, 60, 90 day, etc). How often would you have your users do this? Justify your answer.
   2. One feature of Windows 2000 password maintenance allows accounts to be locked out if a certain number of bad logins for that user occurs (different options are configurable here as well). Explain why you think this is a good or a bad thing.
   3. One thing you could do to add an extra level of perceived security to a Windows 2000 installation is to change the name of the administrator account. Why does this seem to be an effective strategy? And how could an attacker tell which is the original administrator account regardless of it’s name? (HINT: Use DumpSec, examine some properties of the Administrator account)

6. Password Auditing (Linux platform):

   1. UNIX account information and passwords at one time was stored in /etc/passwd. However, modern systems store the “shadowed” passwords themselves in /etc/shadow for additional security. Explain how this is safer and why it’s dangerous to not use shadowed passwords. HINT: If need be, create a user with a fairly simplistic password to demonstrate.
   2. What is the value of a salt for system passwords?
   3. Use John the Ripper to audit your UNIX password security. Try wordlist mode, single crack mode, and incremental mode. Describe what they do, and mention an effective strategy for using John to audit UNIX passwords on your system. Include your results with your write-up. Is there value in using a tool like this to periodically audit your own user passwords? Explain.

   Optional

   1. Suggest an administrative password policy for your users. What constitutes a good password? Explain. Furthermore, how would you enforce this policy and ensure that users didn’t deviate from it?
   2. Why might it be advantageous to disable remote login of the root user via ssh, etc? How would an administrator be able to perform superuser functions without logging in as that user?