Lab2, Breaking the Password Files.

• You should have finished the first part of this lab before you do this step.
• In this step, we will briefly explore the impact of "breaking" password files.
• Log in as bob
  • Please make a copy of both /etc/passwd and /etc/shadow
    • sudo cp /etc/passwd /etc/passwd.hold
    • sudo cp /etc/shadow /etc/shadow.hold
  • Unless you totally destroy the system, you should be able to restore these with
    • sudo cp /etc/passwd.hold /etc/passwd
    • sudo cp /etc/shadow.hold /etc/shadow
  • This is probably not a good idea in general, a better solution would be to restore these files from backup.
• Don't mess with any accounts bob or above in the password file.
• Try su - john
  • remember John's password is john
  • When you fish, exit (ie log out of John's account, return to bob)
• In a different terminal try ssh john@localhost
  • This simulates log in in as john.
• Back in Bob's terminal remove John's password
  • As root, edit /etc/passwd
  • sudo leafpad /etc/passwd (or whatever editor you wish)
  • Change john:x:1002 ...
  • To be john::1002 ...
• Try su - john again.
  • What is different?
• In a new terminal try ssh john@localhost
  • Notice you can't log in as john any longer.
  • The system does not allow a remote connection log in without a password.
  • Why would the system not let a user log in without a password?
• Let's add john to the sudoers
  • First su to john and make sure that he has no permission to run sudo.
  • As bob
  • sudo leafpad /etc/group (or replace leafpad with whatever editor you wish)
    • Find the line sudo:x:27:bob
    • Change this to be sudo:x:27:bob,john
  • Now su to John su - john
    • As John run sudo id
    • What powers has John gained and how?
    • Or as John run id
    • What does this show?
  • An attacker will frequently add back doors such as this to a system once they have gained access.
• Several other changes to John's password file entry.
  • Set up a bad password, edit the password file again
    • Change john::1002 ... in /etc/passwd.
    • to be john:BLAH:1002 ...
    • Now su - john with password anything you might guess.
    • We will discuss why this has probably made it impossible log in as John soon.
  • Break John's password file entry
    • Change john:BLAH:1002 ... in /etc/passwd.
    • to john:1002 ...
      • (Note, this is broken, there should be two ::, but try it with one)
    • Now su - john with password john.
    • Note, you can no longer su to john as this account no longer exists.
  • Change John's user id
    • Change john:1002 ...
    • change john:x:0: ...
    • Now su - john with password john.
    • What happened?
  • Finally change Sue's group id
    • First su to Sue and make sure she can not run sudo.
    • In the /etc/password change sue:x:1003:1003:...
    • to sue:x:1003:27:...
    • Try su - sue with password sue.
    • Now try (as sue) sudo whoami
    • What was the result of this change?
      • Looking at the group file, what is group 27?
      • Changing the fourth field of the password file changes the default group for that user.
      • What group did we just add Sue to?