For those who haven’t had the pleasure, Avaya Aura is a (rather complicated) platform for managing IP phones. Today we’re going to be looking at Avaya Aura Device Services (AADS) component of the platform and detailing two vulnerabilities we found during our research.
The first big hurdle with this type of research is getting the software up and running. To provide its phone management service AADS requires significantly more resources than can be provided by a 2020 MacBook Pro. Eventually some in our team managed to get it running in a cloud environment, however a majority of the analysis was still done offline. To perform the analysis we took the AADS installation binary and extracted as much of it as was possible on a vanilla Fedora VM. We couldn’t run anything, but the extracted files still gave us some insight into how the application would run when properly installed.
Looking at the install file, <span class="code_single-line">aads-188.8.131.52.268.bin</span> we discovered that it is a Makeself archive, a compressed TAR archive and installation script rolled into one file. Looking below we can see the start of the install script at the head of the file and then the beginning of the TAR archive that follows.
Since the Makeself format is designed to be self-contained, we were able to just extract everything from the archive and avoid running the installation script by adding the <span class="code_single-line">--noexec</span> flag. This flag prevents the installation script from running. This is needed as the script will detect that we do not have enough resources to run the application, cleanup the extracted files and then exit.
Looking at what we found inside the archive, there were a lot of scripts and a lot of <span class="code_single-line">.rpm</span> packages.
We slowly started force installing the <span class="code_single-line">.rpm</span> packages, adding in missing dependencies as best we could.
After all this was done we had a filesystem that somewhat resembled an AADS install and started poking around to see what we could find. Most of the bigger components had installed themselves under <span class="code_single-line">/opt/Avaya/AADS/184.108.40.206.268/applications</span>.
Cross-Site Scripting (XSS)
We took the available <span class="code_single-line">.jar</span> and <span class="code_single-line">.war</span> files we found and decompiled them. We then started combing through the source code for common errors. One such low-hanging fruit was checking all the <span class="code_single-line">.jsp</span> files for <span class="code_single-line"><%=</span> which would output whatever expression that follows to HTML without any sanitisation. Not only did we find one that was easily controllable, it was also pre-authentication.
In <span class="code_single-line">/opt/Avaya/AADS/220.127.116.11.268/applications/admin.war</span> under <span class="code_single-line">public/login.jsp</span> we found the following snippet.
Tracing <span class="code_single-line">messageLabelVar</span> back to the top of the file we found that it was taken straight from the query parameters with no validation.
An almost introductory example of cross-site scripting in Java, we were able to put together the following payload and achieve reflected XSS with no authentication required.
On some installations of Avaya Device Services, this XSS vulnerability was only accessible by performing a directory traversal attack that exposes the administration panel. For example:
Remote Code Execution (RCE)
After exhausting a lot of the Java, we turned our attention to any configuration files that were installed. Mostly this was to try and determine how each of these Java applications were intended to be accessed and from where. Luckily for us we found much more than we expected. Inside <span class="code_single-line">/etc/httpd/conf.d/ssl.conf</span>, we were greeted by the following configuration snippet.
Surprised at seeing WebDAV in 2022, we searched for the location where the <span class="code_single-line">Avaya_Phone</span> environment variable was set as this was the only security control preventing us from accessing the WebDAV endpoint. Fortunately this was rather easy, we found it set in <span class="code_single-line">/etc/httpd/conf/httpd.conf</span>.
Could it really be that easy? All we had to do was set our <span class="code_single-line">User-Agent</span> header to <span class="code_single-line">AVAYA</span> and we could upload a <span class="code_single-line">.php</span> file.
And, since there was nothing preventing PHP execution in the <span class="code_single-line">/PhoneBackup</span> directory, executing the file was just as easy.
Giving us this response.
So what did we learn? As usual a good portion of security research is just getting the software to run. But once we’re over that hurdle, there’s still plenty of low-hanging fruit. Even if it is a little outdated, knowing about WebDAV and other bygone technologies is always a useful tool to have in your belt.
When reporting these vulnerabilities to Avaya, we were told that they were fixed in a previous release of the software, however no CVE’s were claimed for these issues. If you would like to remediate these vulnerabilities, please refer to ACS-21519 Address PSST Reported RCE vulnerability on Utility Services in the Release Notes 18.104.22.168. This can be found here.
As always, customers of our Attack Surface Management platform were the first to know when this vulnerability affected them. We continue to perform original security research in an effort to inform our customers about zero-day vulnerabilities in their attack surface.