Permissions spelling sanity check

Tutorials/Permissions.md

@@ -6,13 +6,13 @@ privilege (privesc) exploit, changing the current user to one with
 more permissions.
 
 While the example is a little contrived, Privesc is a common task in
-CTF (and pen testing) where we want to move from a low privilieged
+CTF (and pen testing) where we want to move from a low privileged
 user (usually from our foothold), to one with greater permissions.  In
 a CTF it means we get more flags, in the real world it generally means
 we have greater control over the system.
 
 The particular attack we are using here is called *path poisoning*,
-and gives us a nice way of running a user controlled file, rahter than
+and gives us a nice way of running a user controlled file, rather than
 the expected system file.
 
 ## Unix style permissions
@@ -121,7 +121,7 @@ certainly have come across SUDO before during the course, when
 updating the system or running more interesting commands.
 
 SUDO goes some way towards solving the problem of giving users the
-ability to have root privilieges, without needing to be root, but
+ability to have root privileges, without needing to be root, but
 still leaves us with a dilemma.  Sometimes a common program will need
 to run with elevated privileges, for example if it need to access low
 level system resources, or privileged information.
@@ -187,7 +187,7 @@ privileges of the user (in this case root)
 
 > Note: To see the elegance of 'Nix based systems, checkout the
 > permissions for the sudo command. There is an octocat sticker
-> whoever writes me the best explanaion of whats going on here.
+> whoever writes me the best explanation of whats going on here.
 
 Given that SUID files allow us to run commands as a privileged user,
 they can often be the weak point that allows us to gain further
@@ -201,18 +201,18 @@ When we want to run a system level command (for example ```ls```) the
 OS needs to know where to find the executable we are looking for.  We
 have a couple of options here:
 
-  1. Hard Code all runnable commands (which is a silly idea, as it
-     means we wouldnt be able to install anything)
-  1. Hard Code the place where runnable commands are stored.  (a less
-     silly idea.  However, we still lack some flexiblity in where we
-     can place executables, and it can lead to problems with "local
-     user " instals, where a user can install their own version of a
-     program), or where programs with a lot of executables (for
+  1. Hard Code all run-able commands (which is a silly idea, as it
+     means we wouldn't be able to install anything)
+  1. Hard Code the place where run-able commands are stored.  (a less
+     silly idea.  However, we still lack some flexibility in where we
+     can place executable, and it can lead to problems with "local
+     user " installs, where a user can install their own version of a
+     program), or where programs with a lot of executable (for
      example ```perl`` on my system) are used, and it makes sense to
-     logically seperate these into their own directory.
+     logically separate these into their own directory.
   1. Store the possible locations of the binary in some user level
-     variable.  This means that we get a decent level of flexiblity in
-     the global locations our system will look for exectables, whilst
+     variable.  This means that we get a decent level of flexibility in
+     the global locations our system will look for executable, whilst
      also giving the user control of locations that software is
      installed locally.
 
@@ -259,7 +259,7 @@ Therefore when I call a command, the system looks in:
   - ```/usr/bin/core_perl```
 
 As we step through each directory, if the request file is found it is executed and the search ends.
-Lets say we are lookign for ```ncat``` (which lives in /usr/bin) we get:
+Lets say we are looking for ```ncat``` (which lives in /usr/bin) we get:
 
  - ```/usr/local/sbin``` (Fails)
  - ```/usr/local/bin``` (Fails)
@@ -269,20 +269,20 @@ Lets say we are lookign for ```ncat``` (which lives in /usr/bin) we get:
 > ./<command> if we are executing a file in the current working
 > directory.  
 >
-> If we specify a full path (either absolute or relitive) to the
+> If we specify a full path (either absolute or relative) to the
 > file. The OS will look in that location (and only that
 > location). Otherwise, the OS makes use of the $PATH variable to look
 > for the relevant file.  As the current directory is unlikely to be
 > in the $PATH, then the system is unable to find the command.  We
 > also know that "." is a special path, representing the current
-> directory.  Therefore "./<command>" is an (relitive) path, which
+> directory.  Therefore "./<command>" is an (relative) path, which
 > means that the current directory it the first and only place we
 > look.
 
 
-### Modifing the path.
+### Modifying the path.
 
-As a system variable, we can modify the path in userspace.  There are two ways of doing this:
+As a system variable, we can modify the path in user space.  There are two ways of doing this:
 
 The first approach is to use the EXPORT command to set the path for that terminal session.
 ~~~
@@ -294,7 +294,7 @@ PATH=/tmp```.
 
 We hit our first Gotcha here.  This command will set the $PATH to be
 only ```tmp```, which means all the usual places are removed and the
-OS cannot find anything.  A much better aproach is to *prepend* the
+OS cannot find anything.  A much better approach is to *prepend* the
 desired directory to the current path using
 
 ~~~
@@ -377,9 +377,9 @@ Paying attention to the permissions here we have:
   - The source code for our Runme program ```source.c``` which we can
     read.  
 
-Awesome, we have the first peice of our puzzle.  Executable with SUID
+Awesome, we have the first piece of our puzzle.  Executable with SUID
 permissions, that *may* (and as its a CTF box, its likely), have a
-vulnerablity.
+vulnerability.
 
 Lets run the program and see what happens.
 
@@ -395,7 +395,7 @@ help message to push us in the right direction.
 ## Looking at the source
 
 Next lets examine the source code for the binary in ```source.c```
-(OK, we wont usally find the source, but this is the first couple of
+(OK, we wont usually find the source, but this is the first couple of
 weeks, so I am being generous, We could however use ```strings``` or
 ```objdump``` to try to work out what is going on)
 
@@ -417,15 +417,15 @@ clear what is going on.
  - ```printf("Attempting to access file:\n");```  Display a message to the screen
  - ```system("cat /home/level18/File.txt");```  Use the dreaded ```system``` call to access a file.
  
-Now, our developer has done something right, by hardcoding the address
+Now, our developer has done something right, by hard-coding the address
 of the file we are trying to access.  However, they have made a
 mistake in the way the ```cat``` function is being called.  By not
-specifing a full path to the file, they are reling on the OS using the
+specifying a full path to the file, they are relying on the OS using the
 $PATH to find the program.  As we can control the $PATH, then we may
 have a way to modify the behaviour of the code.
 
 > NOTE: This isn't something you will find *that* often.
-> However, sometimes a developer trys to make the program "platform
+> However, sometimes a developer try's to make the program "platform
 > independent" (as there is still no agreement on which /bin directory
 > things go in), which gives us a way in.
 
@@ -438,12 +438,12 @@ Therefore our proof of concept attack looks something like this:
 
 ## Getting A Cat to do what we want it to do
 
-Before we drop a shell, lets create a less evil cat (mr tiddles) to
+Before we drop a shell, lets create a less evil cat (Mr tiddles) to
 help illustrate what is going to happen.
 
 We create the file in the */tmp* directory (You can use anywhere, but
 /tmp is a good habit to get into, firstly it gets wiped on reset, and
-secondly on CTF's like hack the box, its less likely to be interfeared
+secondly on CTF's like hack the box, its less likely to be interfered
 with than doing it in user. Personally, on HTB I do most of my work in
 /tmp/.dang/)
 
@@ -471,8 +471,8 @@ uid=1019(level18) gid=1019(level18) groups=1019(level18)
 level18@18f7df960aa1:~$
 ~~~
 
-> NOTE: If you have any expericnce with Cats for the furry kind, This
-> is probaly the first time a cat has actually done what you want it
+> NOTE: If you have any experience with Cats for the furry kind, This
+> is probably the first time a cat has actually done what you want it
 > to.
 
 Cool, so we have a program called *cat* that runs the *id* command.
@@ -493,9 +493,9 @@ uid=1019(level18) gid=1019(level18) groups=1019(level18)
 
 So whats happening here:
 
-  1. Cat command is called, as no path is speified the OS uses the system $PATH
+  1. Cat command is called, as no path is specified the OS uses the system $PATH
   1. First place in the $PATH is ```/tmp``` Which contains a program called ```cat```
-  1. OS runs this verision of ```cat``` and stops its search, without
+  1. OS runs this version of ```cat``` and stops its search, without
      going anywhere near the intended program.
 	 
 
@@ -561,7 +561,7 @@ session then ```/tmp``` remains at the start of the path.  Therefore
 any call to cat will call our evil version at ```/tmp/cat```, which
 then drops another ```sh``` shell.
 
-You can see from the process list, that after a couople of times, we have several shell processes spawned.
+You can see from the process list, that after a couple of times, we have several shell processes spawned.
 ~~~
 USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 elev18        48  0.0  0.0   4168   588 pts/0    S    21:20   0:00 ./runme
@@ -574,9 +574,9 @@ elev18        58  0.0  0.0  36632  2844 pts/0    R+   21:25   0:00 ps -ux
 $ 
 ~~~
 
-We can work aound this in several ways.  Either using an alternative
+We can work around this in several ways.  Either using an alternative
 program (such as less or nano) to access the flag file, of make a call
-to the origianl version of cat using a full path
+to the original version of cat using a full path
 
 ~~~
 $ whereis cat
@@ -592,8 +592,8 @@ This was a walkthrough of Level 18 of the Linux trainer, and the
 Theory behind the attack
 
 Path poisoning is where we take advantage of a poorly written program
-and modify its behaviour.  It occours because the developer has not
-hard coded paths to executables, instead reling on the systems $PATH
+and modify its behaviour.  It occurs because the developer has not
+hard coded paths to executable, instead relying on the systems $PATH
 variable to find the desired program.
 
 As the $PATH is controllable by the user, we can change where the OS
@@ -612,7 +612,7 @@ Our proof of concept for the Exploit was
  1. Identify Interesting Binaries on the file system
    - Those with SUID bit set
    - Those that make use of the System() call
- 1. Check these for Vulnerablities
+ 1. Check these for Vulnerabilities
    - Non hardcoded paths for System
  1. Create a modified version of the command in the System() call
    - In this case it was ```cat```
@@ -629,7 +629,7 @@ to access restricted files, try the following:
 level18@18f7df960aa1:~$ rm File.txt
 rm: remove write-protected regular file 'File.txt'? y
 
-#Overrite with Pass.txt
+#Overwrite with Pass.txt
 level18@18f7df960aa1:~$ mv Pass.txt File.txt
 
 #Check permissions and Access
@@ -649,14 +649,14 @@ Password for the next level is 84d284bda556887dfe827bb9ddba6cc1
 level18@18f7df960aa1:~$ 
 ~~~
 
-So even though we dont have permission to delete, or modify File.txt
+So even though we don't have permission to delete, or modify File.txt
 or Pass.txt, we are able to.  Why is this??
 
-Read about the inode permissions on directorys and try to find out.
+Read about the inode permissions on directory's and try to find out.
 
 # Further Reading.
 
 - [Linux.com article on Permission](https://www.linux.com/learn/understanding-linux-file-permissions) 
 - [Pentester Lab article on SUID and Find](https://pentestlab.blog/tag/find/)
-- [GTFO bins](https://gtfobins.github.io/)  An excellent resouce of binaries useful for privilege excalation, and escaping restricted enviroments.
+- [GTFO bins](https://gtfobins.github.io/)  An excellent resource of binaries useful for privilege escalation, and escaping restricted environments.