Trusting local root certificates allows proxies to inject data into SEB

[dcronqvist]

Injecting data

When using Safe Exam Browser (not specific to the windows version), it is possible to inject data/information into the browser during an exam. Even though the process of setting it up is relatively difficult, it is more than feasible for someone who knows what they are doing.

An example scenario

Let's assume that we are an examinee that has installed SEB on our own host computer. We, as an examinee, will be doing an exam where SEB will be configured to open up https://generic.lms.com/exam-id through the startUrl in the configuration file. Since generic.lms.com is configured to use HTTPS, it therefore serves Safe Exam Browser a certificate that it can trust or not. It is however likely that it is trusted, given that the certificate was created and signed by a largely trusted CA, as most legitimate certificates are.

So, if we made no modifications on our host computer before the exam, SEB would open up https://generic.lms.com/exam-id and the given certificate will be checked for trust before accessing the page. Since it likely has a legitimate certificate, it will be trusted and the examinee should see their exam. All is well.

However, let's say that an examinee does the following:

1. Create their own new CA with a corresponding root certificate.
2. Create a certificate for generic.lms.com and signs it with the CA from step 1.
3. Create a proxy server that serves the certificate created in step 2, and is made to simply forward requests to https://generic.lms.com
4. Modify their DNS settings on their host (through the hosts file for example) to route generic.lms.com to 127.0.0.1.
5. Install the root certificate for their newly created CA in their operating system.

What would happen?

Well, since SEB uses the operating system's root certificate store to check for certificate trust, the certificate served by the proxy is trusted by SEB. And that is to be expected, since SSL certificates aren't really supposed to cover the fact that one can attack themselves like this, by installing a malicious root certificate. However, this allows an examinee to make sure that the proxy server between SEB and their legitimate LMS has full control and access to the requests and responses going in and out of SEB.

Let's assume that https://generic.lms.com/exam-id simply serves you basic HTML content that is displayed by SEB, then injecting additional HTML content into the response before passing it to SEB is trivial. Even if the LMS was more complex, say with serving questions or other content through the means of API endpoints etc., such API requests can simply be filtered out to have their responses be modified with additional content before sending it to SEB.

How can this be solved?

An idea to solve this is to simply make sure that SEB never trusts operating system level root certificates. The configuration file for an exam should contain the minimally needed trusted root certificates instead, and SEB should then use this supplied root certificate storage to check for certificate trust. If this is done, then step 5 in the above list of steps will not actually make SEB trust the given certificate by the proxy - ultimately leading to the attack not working. It is important to note that this mitigation relies on the fact that the running configuration of SEB is properly checked for integrity. An examinee might otherwise be able to modify the configuration file to include a root certificate of their choosing, allowing the attack once again.

Since the Windows and MacOS version use different browser engines (Chromium vs. WebKit), the implementation of forcing a certain collection of root certificates to be used will likely be different.

[danschlet]

SEB for macOS and iOS already support embedded certificates, which can be pinned. The feature is nevertheless not regularly tested, as we don't have capacities to set up a test system right now.

What you're asking for, that SEB would never trust operating system level root certificates is nevertheless completely out of reality of most exam use cases:

• Most SEB users don't have the knowledge to deal with custom certificates and likely wouldn't be willing to invest time/resources to set this up. Trust me, we know how little most users are willing to invest in (for their understanding) abstract improvement of security...
• This would create extreme support effort, as many (at least) Windows users have anti-malware software installed which replaces root certificates to inspect https network traffic. Most users don't have a clue about that and struggle very much to disable such a (very stupid and dangerous feature). Sometimes the entire anti-malware solution needs to be uninstalled (at least when we last dealt with that), as the https MITM feature cannot be separately disabled (or the custom root certificate isn't removed by disabling the feature).
• We have experience with the latter problem, as SEB 2.x was using a Firefox-based browser engine with its own root CA store. Many people had a lot of support cases because their anti-malware MITM tool caused their exam servers not to be accessible for Windows SEB users.
• As you wrote, "this mitigation relies on the fact that the running configuration of SEB is properly checked for integrity". By increasing the security with embedded CA certificates, a rogue SEB user will use another strategy to circumvent this. We are constantly improving integrity checks, but the best practically achievable security requires to use the Browser Exam Key, SEB Verificator and/or SEB Server, which only SEB admins do which are willing to invest time/effort for enhanced security. Therefore it doesn't make sense for SEB demanding by default to use custom trusted root certificates (which also requires additional effort).
• It makes sense for the Windows version to also support embedded server/CA certificates and certificate pinning. This feature is on the roadmap, but had to be deprioritized for (amongst others) improving the overall integrity checks.

[danschlet]

Btw. if you make embedded, pinned server certificates mandatory, this will be hard to set up for users which rely on an assessment solution which is hosted on a cloud service. You need to be very sure that you embedded all required certificates and your solution can still break any time if a provider suddenly switches to use another root CA.

[dbuechel]

@danschlet I also do think that implementing such a feature is not realistic at the moment, although the above certainly is a legitimate security concern. Would you thus suggest to mark this as "won't fix" for the moment, as we indeed already have the certificate pinning specified as part of the feature parity?

[dbuechel]

We'll try to implement countermeasures for version 3.8.0 (if time and other priorities permit so).

[dbuechel]

Most unfortunately, and due to other (unplanned and/or higher prioritized issues) we have to postpone this issue for a later version.