CSG254: Network Security

NOTE: Read this entire document before beginning the lab assignment.

Lab Assignment

1. Password Cracking

   The term "password cracking" generally refers to an offline dictionary or brute-force attack run against a previously obtained password hash or encrypted file. In this section, you will learn to run programs for cracking Windows and Linux password hashes.

   1. In modern systems, password hashes are not exposed to normal users. Only those with administrator access may see these. However, since many users re-use passwords between systems and applications, cracking one system's passwords can be very valuable to an attacker for future intrusions.

      Log in to your Windows server and use a browser to download pwdump3 and pscp from http://strawman-fedora.nslab.ccs.neu.edu/labs/lab4/. Save pscp.exe in C:\WINNT\system32, so that it will be in your PATH. You may extract pwdump3v2.zip anywhere you like, but be sure to remember the path for later.

   2. Review the documentation included with pwdump3. In a cmd shell, cd to the directory containing the pwdump3.exe binary and run the command to extract your Windows system's user password hashes. (Be sure to use your system's hostname instead of localhost.) Write the output to a file and then use pscp to copy them to your Linux router.

   3. Log into your Linux router and use the unshadow command (which comes with John the Ripper) to combine your /etc/password and /etc/shadow files. (Most user information is stored in /etc/password, but in modern Unix systems, password hashes are stored in /etc/shadow.) Your command line should look something like:

          unshadow /etc/passwd /etc/shadow > router-passwd.txt
           

   4. Next, prune out the unnecessary lines from both of the password files you just generated. Remove all accounts except those of your team's users and the Administrator/root users.

   5. Obtain two additional sample password files from http://strawman-fedora.nslab.ccs.neu.edu/labs/lab4/. Be sure to download and save both the Linux password file, and the Windows SAM dump. These files should be saved in a directory of your choice on your Linux router, along with the two password files you created earlier.

   6. Use john to execute a dictionary attack against all four password files. (This documentation may be helpful.) In order to do this, you may use your Linux system's built-in spellcheck dictionary, located at /usr/share/dict/words, or you may download a larger dictionary from some other source. (Just be sure to observe the dictionary format requirements.) If you successfully crack any passwords in the provided password files, record these passwords for later submission. If you successfully crack any passwords from the files you generated, record those, and have your users change their password to something more secure.

   7. Unfortunately, this method of password cracking has its limits. With a good dictionary, in conjunction with some simple permutations, many typical user passwords may be cracked, but even relatively short random passwords won't be. When dictionary attacks fail, crackers will generally resort to brute-force attacks, where all possible passwords are tried. This can take a great deal of time, and against good hashing mechanisms, it is often infeasible. However, weaker hashing mechanisms can be quickly brute-forced using pregenerated rainbow tables. Rainbow tables are one implementation of time-memory tradeoff used to greatly speed up password cracking. They are particularly effective when password hashes are not salted.

      For the next few steps, you will be using RainbowCrack to attack Windows LM hashes. Review the online documentation for RainbowCrack, and learn how to generate a rainbow table based on a desired character set and password length. (Running rtgen with no arguments provides some usage information as well.)

   8. Now, use rtgen to generate a rainbow table for all 1 to 6 character LM passwords using the alpha-numeric character set. (To do this, you will likely need to copy the sample character set configuration file from /usr/local/src/rainbowcrack-1.2-src/src/charset.txt to your current directory.)

      Generating these tables will use a significant amount of disk space, use df -h to determine which partition you want to save the generated tables in before you begin. In addition, we recommend you use the following table parameters to keep your table size reasonable: rainbow_chain_length=2100,rainbow_chain_count=2000000

      Also note, that this may take as long as an hour or two to complete. (rtgen will print periodic status updates as it runs.)

   9. Once the tables are generated, use rtsort to sort your tables. (You may want to make a backup copy of your sorted tables.)

   10. Use rcrack along with your rainbow tables to attack both your Windows server's password file and the downloaded Windows password file. Once again, record any successfully cracked passwords and change your team's passwords if they were cracked.

2. Exploiting File Race Conditions

   1. A common type of software bug, the race condition, can manifest itself as a serious security vulnerability. Time-of-check-time-of-use (TOCTOU) vulnerabilities are a specific type of race condition, typically appearing as locally exploitable privilege escalation holes. For the purposes of this section, you will need to learn mainly about Unix symbolic links (symlinks) and their properties. Read about them and experiment with them in your home directory on your Linux system until you feel comfortable with how they behave. The man page for ln may be helpful here.

   2. Review the shell script /root/bin/find-suid and become familiar with how it works. If you aren't familiar with some of the commands used in the script, see their man pages, or try running them individually to see how they work. Now, make a backup copy of this script before going any further. (It is very important that you do so.)

   3. Open your system-wide crontab (located at /etc/crontab) in your favorite editor and notice the last line, which is commented out. Replace the parameter at the end of the line with your email address, and then uncomment the line. Save your changes. Now this job will run once every minute, possibly sending you the list of all suid/sgid files under /home.

   4. Make sure you are logged in as a non-root user. Devise a symlink attack which overwrites /root/bin/find-suid to, ultimately, grant you access to a root login shell. (Imagine you didn't already have root access through sudo.) Save all scripts, and record all pertinent commands you ran to exploit this vulnerable script.

   5. Be sure to disable the cron job by commenting out the last line of /etc/crontab when you are finished. If you need to try multiple times to exploit this problem, you may log back in as root and restore /root/bin/find-suid to its original state from the backup you made earlier. (Just be sure to drop privileges again before you go back to exploiting.)

3. Rootkit Techniques & Common Rootkits

   1. Rootkits are packages of software typically used by attackers to reinforce their control over a system after they obtain adminstrative privileges. Read about them, and be sure you understand the difference between a userspace/application rootkit and a kernel level rootkit.

   2. Review one of the following analyses of compromises: 1, 2, 3. Pay particular attention to way the defending administrator detected the compromise, and the tools that they used for analysis.

   3. Now, download and install either Rootkit Hunter or Chkrootkit on your Linux router and run it once. (Record the output for later submission.)

4. File Integrity with AIDE

   1. AIDE is a host-based intrusion detection system (HIDS) which uses techniques similar to that of the more well-known Tripwire®. It attempts to detect intrusions by monitoring the filesystem and alerting administrators when suspicious changes occur. You can read more about how to use AIDE here.

   2. AIDE is already installed on your Linux router, but it is not configured. Create an AIDE configuration file and store it as /usr/local/etc/aide/aide.conf. Then setup aide to run every 4 hours via cron. You should use /etc/crontab for this, and you may write your own external shell script which starts aide if you wish.

      Your configuration should satisfy the following:

      • All files on the filesystem should be hashed and have all metadata (timestamps, permissions, etc) checked unless you have a good reason not to. You should try to eliminate all false positives (eg. alerts that are a result of normal operation), which means: if you expect something should change on a regular basis, then exclude it from the checks. However, only exclude the minimal number of changes necessary to eliminate false positives.
      
      
      • Your AIDE configuration file must include comments explaining why you have excluded certain files' attributes from being checked. Every exclusion must be documented, and should include a description of the specific normal, everyday process which effects the change you are expecting. (For example, if you exclude the contents of a log file from being checked, then explain what process writes to that log file regularly.)
      
      
      • Your AIDE configurations and database should be readable/writable only by the root user.
      
      
      • Each time AIDE checks the system, any alerts (unexpected file changes) must be emailed to one or more members of the team.
      
      
      • Your AIDE database must not be scripted to update automatically. If you need to update it, do it manually.
      
      You should check your AIDE configuration a few times over a few days to eliminate as many false positives as you can. A sample configuration for AIDE can be found on your system at /usr/local/src/aide-0.10/doc/aide.conf.

   3. Once you have a stable AIDE configuration, log into your system and touch (see man touch for more information) an executable in /usr/local/bin to change its modification date. When your cron job runs again, it should send you an alert email about this change. Save a copy of this email for later submission. (After you are done, you may update your AIDE database to stop future email alerts.)

Questions

1. Name at least three reasons why LM hashes are easier to crack than salted SHA1 hashes.
   
   
2. Suppose a user selects a random, 8 character password from the set of characters [A-Za-z0-9], and the password is hashed via an unsalted SHA1 hash. If an attacker wished to precompute all possible 8 character password hashes (of this character set) and store the pairs in a simple list, how many megabytes of disk space would this require at a minimum? (Assume one megabyte is equivalent to 2²⁰ bytes, and that the passwords themselves are stored in ASCII.)
   
   
3. Suppose the find-suid script contained an additional line right above the call to find, which read:

       rm -f $TMP_FILE

   Would this script still be vulnerable to a symlink attack? Explain your reasoning.
   
   
4. State which intrusion analysis you studied in step 3.2, and describe how the administrator(s) determined which rootkit was being used.
   
   
5. When you ran chkrootkit/rkhunter, did you notice any warnings that were likely false positives? What were these?
   
   
6. In your Linux router's current AIDE configuration, name one way an attacker could prevent you from being alerted to system changes. In the worst-case scenario, if an attacker can gain root on your system, will file integrity checking suffice as a intrusion detection mechanism? If not, in what scenarios might it help secure the system?
   
   

Submission Notes

• You need to submit one short report for your team, which includes all answers to questions in the "Questions" section above, and the items listed below. The report must indicate what each team member did. (While the work for this lab can be split up amongst your team members, at least two team members must participate in each main section of the lab, and all team members must understand the answers given for the questions.)
  
  
• Be sure to report on any passwords successfully cracked in section 1. Include user account, the associated password, and what tool was used to crack it. Include program output for these successful attacks.
  
  
• You need to include all scripts you wrote in section 2, and include a short explanation of how your exploit works.
  
  
• Don't forget to include the output of either Chkrootkit or Rootkit Hunter in your final submission.
  
  
• Include all configurations and scripts you wrote in your setup of AIDE. Also submit a copy of the email alert you received when touching the executable.
  
  
• You will likely need to search the web for answers to many questions in this lab. This is permitted, but be sure to record EVERY reference you use and include them in your final report. You may quote short portions of text from these references, but don't just copy-and-paste complete answers. You must provide explanations in your own words.
  
  
• Submit all items in one email to prabhu@ccs.neu.edu and CC noubir@ccs.neu.edu. Be sure to send all files in one .tar.gz or .zip file. Acceptable report formats are text, RTF, PostScript, and PDF.