Next Week’s Registration: https://networkdefense.clickmeeting.com/cuckoos-egg-3
This week, we reviewed chapters 4-8.
After setting up his monitoring system, Cliff observes another suspicious login using the Sventek account. Now, Cliff is better equipped to figure out what is going on and monitor every command issued by the potential attacker. He reads the logs showing the activities taken by the attacker over a three hour span. First of all, he notices that the attacker is logged in from Tymnet. This means the attacker could be coming from anywhere as Tymnet was a global network. Cliff digs into the meat of the log and is alarmed the find that Sventek is operating as a superuser. That shouldn’t be possible!
The Principle of Least Privilege
In security, we operate under the principle of least privilege. The means that users on a system should only be allowed to do the bare minimum required to complete their task and for only as long as they are required to complete it. This means users should not have administrative privileges to change the system, and applications should be installed with limited user accounts. This speaks to the concept of the attack surface. Any access an attacker has on a system provides points of interaction. Generally speaking, the more points of interaction the attacker has, the more opportunities they have to force applications or systems to respond in ways that might allow compromise. This characterizes the attack surface. The fewer interaction points we give users, the smaller the attack surface is when an attacker compromises a user’s account.
In class, we completed an exercise where we mapped the privileges of various roles in a bank setting and analyzed the attack surface of roles controlled by an attacker. I also discussed mechanisms meant to ease the burden of PLP, just as Windows User Account Control (UAC) and Linux sudo. We are all sysadmins on our own mobile devices, and I discuss how these vendors have taken the approach of forcing us to consent applications into specific access based on their feature needs. Facebook was given as an example along with screenshots showing all the things it needs to access in order to provide its full array of features.
More Reading:
- The Principle of Least Privilege: https://www.us-cert.gov/bsi/articles/knowledge/principles/least-privilege
- Implementing Least Privilege in your Enterprise: https://www.sans.org/reading-room/whitepapers/bestprac/implementing-privilege-enterprise-1188
- Add a User to the Sudo group in Ubuntu: https://www.digitalocean.com/community/tutorials/how-to-create-a-sudo-user-on-ubuntu-quickstart
Dig Deeper Exercises:
- Level 1: Look at the permissions granted to a social media app on your phone. Try to map each permission to a specific function.
- Level 2: On a Windows system, use a limited user account and attempt to perform an administrative action. Find an event log that indicates you took this action.
- Level 3: On a Linux system, create a limited user account. Give it sudo privileges to perform administrative actions. Test this out, and find an event log indicating you took this action.
Cliff continues to dig around and discovers how the attacker became a superuser. It turns out that the attacker found a bug in the gnu-emacs application related to how it assigns ownership of files mailed between users on the system. The application simply changes the ownership of a file without respect to privilege assignments. Since the application was installed as an admin user, this allowed the attacker to trick it into copying a file such that it became owned by a privileged account. The attacker used this big to replace a systems ATRUN file, which executes every 5 minutes to conduct system administration tasks. When the attacker’s version of this file ran, it added the Sventek user to an administrative users group.
As a superuser, the attacker begins pillaging the network. They read sensitive files and e-mails, and look for passwords. The attacker also appears to be very paranoid and constantly looking over their shoulders. They enumerate who the system operators are and constantly look to see who is logged into the system and what processes are running.
Cliff presents these findings to his boss, who tells him to keep watching the attacker but not to take action yet. The monitoring system is refined to alert only when known compromised accounts login.
Process Monitoring
We use this opportunity to talk about process monitoring. The concept of a process is easy to understand, but we should give attention to the tools we can use to monitor running processes and their limitations. Active process monitoring is something done by defenders to look for suspicious or malicious processes. It is also something done by attackers to look for processes that might detect them or prevent them from accomplishing a goal.
In class, I demonstrated the PS command on Linux and discussed different ways to use it to look for running processes. I also demonstrated Process Explorer on a Windows system, as well as TASKLIST for command-line and remote process monitoring.
More Reading:
- 30 Useful PS commands for process monitoring: https://www.tecmint.com/ps-command-examples-for-linux-process-monitoring/
- Example PS Command Usage: https://www.lifewire.com/uses-of-linux-ps-command-4058715
- Windows Process Explorer: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
- Viewing and Killing Processes on Remote Windows Computers: https://www.windows-commandline.com/kill-remote-process/
Dig Deeper Exercises:
- Level 1: Choose three processes you use on a daily basis. Use the tools here to locate them and trace their parent processes as far as you can. Research what each parent process does.
- Level 2: Compare your system to a clean system with no software installed (you may need to set up a virtual machine in a lab to do this). Identify what processes are unique to your system and those that are standard with the operating system.
In discussion with one of Cliff’s colleagues, the attacker’s use of the PS command is brought up. The attacker uses a flag (-g) that is supported on AT&T Unix, but not Berkeley Unix that is run at LBL. Someone wagers that the hacker is not from the west coast or he would be well versed in their flavor of Linux.
The attacker dials back in but doesn’t stay on LBL systems for long. Instead, they use LBL as a hop point to connect to a DoD server as the user Hunter. Cliff queries the NIC and finds that this IP belongs to Anniston Army Depot in Alabama. He calls the system operator and explains what he observed. The operator is aware of the attacker having been there, but thought he had been eradicated. It turns out that the attacker was using the same emacs bug but is coming in through LBL and not the front door anymore. Cliff ponders the thought that the attacker might be southern, as it would explain the familiarity with AT&T Unix which was run on the Anniston systems.
Next Session
November 30th 7:30PM ET
Read Chapters 9-14
Register/Attend Here: https://networkdefense.clickmeeting.com/cuckoos-egg-3