You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cryptography/aes.md
+46-1
Original file line number
Diff line number
Diff line change
@@ -192,7 +192,7 @@ Solution to a Cryptopals challenge with a script that exploits this AES CBC padd
192
192
193
193
This mode can turn AES which normally is a block cipher of 16 bytes at a time, into a stream cipher, meaning it can simply generate any amount of random bytes from a key as the seed. This keystream it generates can then be used to XOR with the actual plaintext to encrypt it. Decrypting goes exactly the same: generate the keystream, XOR it with the ciphertext and you get back the plaintext as XOR is symmetric in this way. 
194
194
195
-
It generates the keystream by **encrypting a CounTeR with the key**. This counter can simply start at 1, and goes up for every block. This way, you're encrypting some value to generate random-looking output for the keystream. 
195
+
It generates the keystream by **encrypting a CounTeR (CTR) with the key**. This counter can simply start at 1, and goes up for every block. This way, you're encrypting some value to generate random-looking output for the keystream. 
196
196
197
197
```python
198
198
cipher =AES.new(key, AES.MODE_ECB) # Uses AES-ECB with key
@@ -253,3 +253,48 @@ Then just repeat this for all the bytes you want. You can find an implementation
Solution to a Cryptopals challenge with a script that exploits this AES CTR statistical attack
255
255
{% endembed %}
256
+
257
+
## CFB Mode
258
+
259
+
Another mode to turn a block cipher into a stream cipher is the **Cipher FeedBack (CFB)** mode. One of its useful properties is its ability to "self-heal" in case of a missing piece of ciphertext, which is useful for lossy protocols that might drop packets. While this algorithm still uses a standard block size like 16 for encryption with the key, it generates blocks of a variable size $$s$$ which is useful for streaming. \
260
+
The following diagram shows decryption with the same size $$s$$ as its standard block size, no overflow:
Commonly this size is _smaller_ than the block size, resulting in each encryption with the key not being fully used. The XOR is only done as long as the plaintext or ciphertext is. Then for the next block, the diagram shows the ciphertext is used as the input for the encryption with the key, but this is not the whole story. Because this ciphertext is not long enough, it just pushes the previous input to the left as far as it needs to. Take the following example:
265
+
266
+
```python
267
+
IV="ABCD"# block size of 4 bytes
268
+
Ciphertext ="abcdefgh"# s of 2 bytes (16 bits)
269
+
------------------------------
270
+
i = ENC(IV) ="!@#$"# after AES encryption with Key
271
+
Plaintext = i ^CT="1234"# 1st chunk of output
272
+
273
+
NEW_IV=IV<<2+CT="CDab"# shift IV by adding CT
274
+
i = ENC(IV) ="%^&*"# new and different intermediate
275
+
Plaintext = i ^CT="5678"# 2nd chunk of output
276
+
```
277
+
278
+
### Predictable Output
279
+
280
+
One interesting thing about this algorithm is the fact that you can create repeating patterns in the output of a decryption. This is because when we provide an _Initialization Vector_ and a _Ciphertext_, both are used directly in the AES encryption. If we make these bytes all the same, no matter how much it shifts, the input will always be the same. With the same key, it means the intermediate value will also stay the same and be XORed with the same ciphertext each time. 
281
+
282
+
In the end, this means our plaintext will repeat every $$s$$ bits and if the goal is to generate some predictable output, we just have to guess $$s$$ bits correctly once and repeat it for the whole length. It can also be useful in getting lucky to output a set of characters that fit some condition, like being ASCII. With this trick, there is a pretty good chance all characters are ASCII because just the first $$s$$ need to.
</strong># # Check out GitHub README for more examples
76
76
</code></pre>
77
77
78
+
{% hint style="info" %}
79
+
**Tip**: The `.git/config` file may not be cloned, but if found locally, can contain git credentials used to push and pull to a remote origin. These may be re-used elsewhere or allow you to explore more of the remote git origin.
80
+
{% endhint %}
81
+
78
82
## Attacking Git Commands (RCE)
79
83
80
84
Git is a very flexible system, allowing many settings to be changed to decide how CLI tools interact with the repository. These configuration variables can allow executing arbitrary commands however when certain git commands are executed. The `core.fsmonitor` variable in `.git/config` is a common one that can be set to a bash command to execute:
Often in privilege escalation, you're letting a high-privilege user execute some command. Sometimes you can't directly execute a shell as that user and have to run some other command to send a way to get a shell somewhere. One simple way is to just execute a reverse shell as that user. Then you will get a privileged reverse shell in your listener. See [#reverse-shells](hacking-linux-boxes.md#reverse-shells"mention") for some examples of this. 
204
+
205
+
Another easy way if you already have access to the box, is to create a [#setuid](linux-privilege-escalation/command-triggers.md#setuid"mention") binary of bash that the target user is the owner of. The safest way to do this is to first copy /bin/bash to another location, which will make the owner of the file the user that executed the command. Then to later get back those privileges just add the SUID bit with `chmod +s` to take over the privileges of the owner when you execute the program as a low-privilege user. 
206
+
207
+
{% code title="Let target execute:" %}
208
+
```shell
209
+
cp /bin/bash /tmp/bash; chmod +xs /tmp/bash
210
+
```
211
+
{% endcode %}
212
+
213
+
<preclass="language-shell-session"data-title="Low-privilege user"><codeclass="lang-shell-session"><strong>$ /tmp/bash -p # -p to maintain privileges
**Warning**: While this shell allows filesystem access as `root`, it won't perfectly with with all commands as your main user is still `user`, we only raised their privileges. You can solve this by getting a clean shell with techniques like [#root-etc-passwd](../web/arbitrary-file-write.md#root-etc-passwd"mention").
Copy file name to clipboardExpand all lines: linux/linux-privilege-escalation/README.md
-126
Original file line number
Diff line number
Diff line change
@@ -6,129 +6,3 @@ description: >-
6
6
7
7
# Linux Privilege Escalation
8
8
9
-
If a system has been set up well, you might not instantly get all the privileges on the machine when you get in. It's pretty common to have a web server run as a low-privilege user, so if it ever gets hacked the attacker might not be able to do much on the server.
10
-
11
-
The point of Privilege Escalation is to abuse features of the system to execute commands as more privileged users, thus escalating your own privileges on the system. Most of the information was from the Linux PrivEsc rooms on TryHackMe:
Second PrivEsc room with more advanced techniques and a lot of detail
19
-
{% endembed %}
20
-
21
-
## Getting Shells
22
-
23
-
Often in privilege escalation, you're letting a high-privilege user execute some command. Sometimes you can't directly execute a shell as that user and have to run some other command to send a way to get a shell somewhere. One simple way is to just execute a reverse shell as that user. Then you will get a privileged reverse shell in your listener. See [#reverse-shells](../hacking-linux-boxes.md#reverse-shells"mention") for some examples of this. 
24
-
25
-
Another easy way if you already have access to the box, is to create a [#setuid](command-triggers.md#setuid"mention") binary of bash that the target user is the owner of. The safest way to do this is to first copy /bin/bash to another location, which will make the owner of the file the user that executed the command. Then to later get back those privileges just add the SUID bit with `chmod +s` to take over the privileges of the owner when you execute the program as a low-privilege user. 
26
-
27
-
{% code title="Let target execute:" %}
28
-
```shell
29
-
cp /bin/bash /tmp/bash; chmod +xs /tmp/bash
30
-
```
31
-
{% endcode %}
32
-
33
-
<preclass="language-shell-session"data-title="Low-privilege user"><codeclass="lang-shell-session"><strong>$ /tmp/bash -p # -p to maintain privileges
If you can only write to files, without running commands yet, you can write to some specific locations that will later execute commands. Profile files such as `.bashrc` or `.profile` contain scripts that are executed every time the user logs in, and you may be able to hide a reverse shell command here to trigger whenever the user logs in again. 
41
-
42
-
If you are able to write at some place with code that is executed by another user, try overwriting this code with a reverse shell or anything else you want them to do. For example a PHP shell like `<?= system($_GET["cmd"]) ?>` to run commands on a website. This really depends on what technologies exist on the system, but overwriting libraries may also be an option. 
43
-
44
-
For an instant trigger, the root user may edit `/etc/passwd` to add another root-level user with your own password. Then you can log in as that user and get root privileges:
<preclass="language-shell-session"><codeclass="lang-shell-session"><strong>$ su hacker
58
-
</strong>Password: hacker
59
-
# id
60
-
uid=0(root) gid=0(root) groups=0(root)
61
-
</code></pre>
62
-
63
-
If the machine uses SSH, another way would be to append your own public key to the `.ssh/authorized_keys` file in the target's home directory, which permits you access to the user via SSH. Just `cat` out your own `~/.ssh/id_rsa.pub` starting with `ssh-rsa...` and add it to a new line in the `.ssh/authorized_keys` file. Then you are allowed to log in simply using SSH:
64
-
65
-
```shell-session
66
-
$ ssh root@$IP
67
-
```
68
-
69
-
{% hint style="warning" %}
70
-
Default installations of SSH don't allow logging in as `root`. To check this look at the `PermitRootLogin` option in `/etc/ssh/sshd_config`:
Another way is creating a **backdoor** in the user's home directory. For Bash, the `~/.bashrc` file is most common as it executes in any non-login interactive shell. However, for login shells like SSH, a few more are executed in the following order. The _first_ readable file is the _only_ one that executes:
78
-
79
-
1.`~/.bash_profile`
80
-
2.`~/.bash_login`
81
-
3.`~/.profile`
82
-
83
-
Often the above files execute `~/.bashrc` as well to make sure login shells work similarly to non-login ones, so this is often your best bet. Here is a table that shows what Bash by itself:
See [this article](https://www.baeldung.com/linux/bashrc-vs-bash-profile-vs-profile) to get a full understanding, as well as the [source code](https://github.com/bminor/bash/blob/ec8113b9861375e4e17b3307372569d429dec814/shell.c#L1123-L1260). 
88
-
89
-
### Reading files
90
-
91
-
Being able to read files as a privileged user can allow you to read sensitive information. If you are reading as the `root` user, you may read the shadow hashes in `/etc/shadow`, which can be cracked locally to find users' passwords (See more info in [#cracking-shadow-hashes](../../cryptography/hashing/cracking-hashes.md#cracking-shadow-hashes"mention")). Then if you have cracked a password you can just log in as that user using `su`:
92
-
93
-
<preclass="language-shell-session"><codeclass="lang-shell-session"><strong>$ su root
94
-
</strong>Password: password123
95
-
# id
96
-
uid=0(root) gid=0(root) groups=0(root)
97
-
</code></pre>
98
-
99
-
Another common file to read is SSH private keys. These are located in the user's home directory in a `.ssh` folder. To find the home directory for a user you can check `/etc/passwd`:
This folder often contains an `id_rsa` file that is only readable by the user, but contains the private key that can be used SSH into that user. When you are able to read this file, copy it to your attacking machine and use `ssh -i` to use the private key:
<strong>$ chmod 600 id_rsa # Set correct permissions to allow SSH to use it
117
-
</strong><strong>$ ssh -i id_rsa root@$IP
118
-
</strong># id
119
-
uid=0(root) gid=0(root) groups=0(root)
120
-
</code></pre>
121
-
122
-
Some places where you may find cleartext/hashed credentials are firstly `.htpasswd` files for websites, if authentication is implemented this way. These files will contain a username and password separated by a `:` colon. \
123
-
In [git.md](../../forensics/git.md"mention") repositories, the `.git/config` file may also hold credentials for a _remote origin_. These are in plaintext as they are used directly for authentication, so you may find strong passwords.
124
-
125
-
```bash
126
-
find / -type f -name .htpasswd 2>/dev/null
127
-
find / -type d -name .git 2>/dev/null
128
-
```
129
-
130
-
### Deleting files
131
-
132
-
This is a bit of a special case, but if you have a primitive to delete an arbitrary file, you may be able to remove files that protect a service normally but still work without the file. You may find that an application replaces a **configuration file** with the default if it cannot find it, resetting any extra protections an admin may have put on it. 
133
-
134
-
Another trick is when the target user does not want to be spied on, so they symlink their `~/.bash_history` to `/dev/null`. This is a common default configuration in some places as well. When you **delete** this file it will remove the symlink, and bash will simply create the file and write to it when the next command is executed that should be put in the history. You may be able to read sensitive command-line arguments like passwords or other secrets if it is readable by you. 
0 commit comments