Hi everybody, I will share with you in this article in detail how I was able to find CVE-2022–42710 through static analysis

Summary of Linear eMerge E3 Series:

The Linear eMerge E3 Series is one of the industry leading products in building management systems as it is one of the most widely used products in the industry which is used for control

• School Districts and Campuses (K12 & Higher Ed)
• Corporate Campuses
• State/Local Government buildings (Civic Centers, City Hall, Police Stations, Jails, etc.)
• Public Utilities
• Transportation (Airports, Subway, Bus Depots)
• Places of Worship (Churches, Mega-Church campuses)
• Medical Facilities (Hospitals, Pharma, Bio Labs, etc.)
• And more

Let’s start the Static-Analysis:

while i was doing security source code review i came across this PHP script

http://127.0.0.1/badging/badge_template_print.php

TPL_DIR in configuration file =tpl/

we get “tpl” parameter from the user and then pass it to simplexml_load_file so our input will be parsed by the XML parser, at first glance it seems that it’s not vulnerable to XXE as to be vulnerable to XXE it needs to load “LIBXML_NOENT” class which substitute external entity which leading to XXE

example on vulnerable code to XXE

try
{
    $template = $_REQUEST["tpl"];
    $xml = simplexml_load_file(TPL_DIR.$template, 'SimpleXMLElement', LIBXML_NOENT);

but that is not our scenario so it’s not vulnerable until now to XXE

but i started to gather more information about the XML parser library

okay the libxml version is not vulnerable to XXE by “substitute external entity” by default at the latest version but according to this version it seems a little bit old so we need to do some search about it on CVE details https://www.cvedetails.com/

maybe there is exploitation or someway to abuse of the function in a bad way

after doing some search found some exploits but they didn’t match the configuration of the application so they didn’t lead to any vulnerability

Anyway, the above step is important in our static code analysis as it sometimes leads to critical vulnerabilities

As there is a researcher who found a similar scenario while he was doing some code review for a java application he found that developers use XMLparser library that allows for external entity substitution by default which eventually leads to XXE vulnerability, you can find more details on the vulnerable XML parser library that were used by the vulnerable application in the previous scenario at https://nvd.nist.gov/vuln/detail/CVE-2017-1000190

So i found nothing for this specific version and the only allowed method is by adding the “LIBXML_NOENT” class to the “simplexml_load_file” function to substitution external entity as I described so the product is not vulnerable to XXE

So let’s get back to our point

At the underline code we can figure out how the XML data will be parsed

The application will take a file as input and parse it by the XMLparser then save it at $xml variable

as you see in the above code the input file should contain an orientations tag and inside it should be two tags orientation and background tags then at line 56 you will find that whatever is inside the background tag will be printed

so to achieve our XSS we should define <xml> tag first to make the parser know that we parse XML file then define <orientations> tag as we saw in the PHP code then inside it defines two tags the first one <orientation> tag and the second one <background> tag which will be printed through echo function and contain our XSS payload

The final payload will be like that

CDATA is used to command the parser that the particular section of the document contains no markup and should be treated as regular text and not parsed as XML

the reason for that is to make the parser consider our <script>tag as text inside the background tag which later will be printed in the application

But wait a minute

How can we upload our XML file that contains the exploit to achieve the XSS?

After some research in the application i came across this PHP script

http://127.0.0.1/badging/person_funct.php

It’s a file upload function that validates size to prevent DOS attack and name the file with the time of uploading the file to prevent XSS in the filename and force “.jpg” file extension to prevent uploading malicious extension

there are some best practices at this PHP script but let’s focus on more important things

Now we need to upload our exploit.xml file but the application force a jpg extension so how we will do it

Actually, it doesn’t matter what is the file extension because the XML parser used by simplexml_load_file() doesn’t care about the file extension all it cares about is the file syntax so we will upload our exploit using the “http://127.0.0.1/badging/person_funct.php” script

Our exploit is uploaded at “http://127.0.0.1/user_img/20220830152741.jpg”

Now we will request it using the tpl parameter at “http://127.0.0.1/badging/badge_template_print.php” script

but our exploit in “user_img” directory and the vulnerable function load files from a different directory “/badging/tpl/” directory, so how we can load our exploit?

we will need to get our exploit from user_img directory so we will do directory traversal “../../user_img” to get out from “http://127.0.0.1/badging/tpl/” directory to “http://127.0.0.1/user_img” directory where our exploit is located

http://127.0.0.1/badging/badge_template_print.php?idt=1&tpl=../../user_img/20220830152741.jpg

We got our stored XSS

Automated Exploit Script:

https://github.com/omarhashem123/Security-Research/tree/main/CVE-2022-42710

Twitter: @OmarHashem666

Linkedin:https://www.linkedin.com/in/omar-1-hashem

Youtube:https://www.youtube.com/@omarhashem7351