Open dcronqvist opened 1 year ago
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:
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.
@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?
We'll try to implement countermeasures for version 3.8.0 (if time and other priorities permit so).
Most unfortunately, and due to other (unplanned and/or higher prioritized issues) we have to postpone this issue for a later version.
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 thestartUrl
in the configuration file. Sincegeneric.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:
generic.lms.com
and signs it with the CA from step 1.https://generic.lms.com
hosts
file for example) to routegeneric.lms.com
to127.0.0.1
.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.