Author: therealFIGBERT <email@example.com>
Date: Sun, 5 Jan 2020 11:48:36 -0800
Write privsec1 walkthrough, create scripts and walkthroughs folders
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/linux_and_misc/addition.py b/linux_and_misc/scripts/addition.py
diff --git a/linux_and_misc/binaryaddition.py b/linux_and_misc/scripts/binaryaddition.py
diff --git a/linux_and_misc/walkthroughs/privesc1.md b/linux_and_misc/walkthroughs/privesc1.md
@@ -0,0 +1,27 @@
+# privsec1 Walkthrough
+[privsec1](https://twinpeaks.cs.ucdavis.edu/challenge?id=11) is the first privilege escalation challenge that we are presented with, and requires a different set of skills than the previous challenges. Whereas previous challenges, like [addition](https://twinpeaks.cs.ucdavis.edu/challenge?id=9) and [binaryaddition](https://twinpeaks.cs.ucdavis.edu/challenge?id=10), relied almost only on our coding skills, this challenge introduces a new concept: situational awareness attacks.
+What is a situational awareness attack? A situational awareness attack is, according to [tokyoneon](https://twitter.com/tokyoneon_) on [Null Byte](https://null-byte.wonderhowto.com/how-to/hacking-macos-perform-situational-awareness-attacks-part-1-using-system-profiler-arp-0186422/):
+>the act of gathering hardware, software, and network information about the target. This information can be used to further compromise the target, their online accounts, and pivot to other devices and services within the network.
+## Intelligence Gathering
+An initial assessment of our surroundings on connection reveals the server is running Debian GNU/Linux 10 (buster). A quick check of the flag, located at `/home/admin/flag`, reveals some valuable information. Trying to read the file with `cat` spits out this error: `cat: /home/admin/flag: Permission denied`. Running `ls -la /home/admin | grep flag` shows us that the permissions are set at 440 – only the file's owner has read access.
+This information gives us a pretty good idea of our situation and goal:
+ * the `admin` user has read-only access to the flag
+ * our current user, `user`, has no access to the flag
+ * impersonate `admin` and read the file
+How do we impersonate a user? `sudo`! One problem: when we run `sudo cat /home/admin/flag`, we're prompted for a password. The only password we know for the account – `tucking_bacteria_litter_cheek_scrutiny` – doesn't work, and we're locked out after three attempts. As with most privilidge escalation attacks, we now have to look toward misconfigured permissions.
+Executables on linux are often in the `bin` folders, so the first place we should look is `/bin`. A quick `ls` of `/bin` reveals nothing interesting, so we can move on.
+After looking around a bit, we find a second folder of executables, at `/usr/bin`. Running `ls` and scanning through, we've hit the jackpot: A `sudo` executable. Checking the permissions by running `ls -la | grep sudo`, we see: `-rwsr-xr-x`. Not only is the file executable by everyone, it's also [sticky bit (suid) enabled](https://www.linuxquestions.org/questions/linux-newbie-8/what-is-s-instead-of-x-in-the-file-permission-when-i-look-at-usr-bin-chsh-223386/), which means that the file "will be executed with root permissions by all users."
+All that's left is to run the executable with the proper input. A quick check of `sudo -h` spits out the help page, and a scan of that reveals the structure needed. Lastly, we run the command: `./sudo -u admin -s cat /home/admin/flag`. Just like that, we have the flag: