Creating seb configuration using an external .NET application

[t00]

About 2 years ago I made a fork of SEB then still SVN repository to adapt it slightly to my employer's requirements and ended up in creating https://github.com/t00/seb and https://github.com/t00/seb-mac repositories. Almost at the same time SEB got it's own Git repository and the changes never ended up in the mainstream repo.

Main changes include:

1. Extracting SEB configuration code to a separate SebShared.dll so that an external application (in our case ASP MVC app) can generate exam configuration files to make the exam configuration easier
2. Making windows and mac configurations compatible - I changed windows code to generate exactly the same plist xml file as mac version would (that required some shuffling of missing options between win and mac, fixing line endings and indents, using SortedDictionary to hold configuration values etc). This allowed using same c# dll to generate seb files recognised by both win and mac.
3. Created a working wix installer for SEB
4. In win and mac versions made some strings configurable to allow rebranding / URL changing by swapping resources/locale/consts/image.
5. Moved and refactored SEB initialization code from Form to Main, it is always executed before even showing any windows so that configuration can be loaded from file/command line/url or single instance check can be made before anything else happens
6. Added option to ask for configuration location dialog when no configuration is present.
7. Fixed single instance controller - custom mutex + pipe for configuration passing
8. Removed IconLib and Metro libraries - "downgraded" to using .Net classes to extract icons and using WPF dialogs as opposed to default WinForms, instead of custom metro.
9. Changed configuration classes to use single instance configuration (SebInstance) or provided as an argument - for 3rd party use.
10. Changed exe hash generation code to include SebShared.dll. It's now working in a more predictable way when scanning for files to be included in hash calculation.

Our company have very limited resources to work on SEB but we still need to keep our build updated and at the same time I wish to contribute to mainstream SEB and would like to apply the changes again but this time against the mainstream repository.

There is a complication though - you seem to be rewriting the windows SEB version.

Before I will proceed with doing the update may I clarify few things so that contributions I will make can be more valuable to SEB and hopefully end up in the official repository?

1. What state the current refactored windows app is in? How much work is there to be done?
2. Was there any effort in the past 2 years to make configuration files compatible between Windows and Mac/iOS or are there any plans about it? From my perspective it is critical to use a single exam configuration across all devices.
3. Is the current Mac build checking it's own hash to make it more secure and allowing control of which SEB version is allowed to take the exam? Last version we used created a hash only from the configuration file plist xml without adding the exe hash or even a const at the end.
4. How currently do you circumvent a potential attack vector of say writing a browser plugin which will add a HTTP header to every request containing a correct hash created by merging a configuration file + exe hash (grabbed from the original exe by a small tool) with the URL hash?
5. Are there any plans to use mshtml.dll web browser in win application to make browsing smoother (not necessarily better HTML support) and avoid lags when opening settings from within the browser due to another SEB process launching in the background? Or just intercepting seb(s) links within the browser.
6. Do you have plans for Android version?

[danschlet]

Hi, sorry, I don't have time to answer all your questions extensively right now, but we will follow up. Just to clarify some points:

• The Windows, Mac and iOS configuration files are perfectly compatible in the official SEB versions and are used all over the world in mixed environments. Maybe there is a misunderstanding on your side, SEB Config Files have to allow to use platform specific keys together with common keys. This should be obvious, as also new SEB versions will likely introduce new keys and the current format makes config files downwards- and upwards compatible, exactly because they don't need to contain all the same keys. You can still generate config files containing all the platform specific keys, but we can't enforce this unless we are able to sync the releases on all three platforms perfectly, which we probably never will (as some features make only sense on some platforms, for example supporting third party applications in a VDI environment).

• The only thing not being compatible is the generation of the Browser Exam Key (BEK). But that was never intended, the BEK wasn't designed to be server generated. The idea was that the BEK can only be generated inside of an (unmodified) SEB client and therefore should make it harder to perform an attack which you mentioned in your question number 4. For the same reason the plan also was to move generating the BEK into a module distributed only in binary and code obfuscated form. We had to put this aside as we had to focus on some other improvements, security and bug fixes. But we will start work on this early next year again, although there will be two new keys to later replace BEK and allow to be server generated without the disadvantage to be easily generated by an external tool or an easily available DLL. I will make the specifications for these keys public early next year, there is already a Mac branch implementing one of these key, the Config Key.

• In the refactored SEB version we are using the Chromium browser engine (CEF3/CefSharp). IE/Edge browsing components are not very well compatible and embedding Chromium is mostly used nowadays for embedded browsers on Windows.

• For being able to develop, maintain and support an Android version, we would need two additional principal members in the SEB Consortium or accordingly more gold members or donors. Android is a messy operating system to support for security-relevant software and would need constant efforts to keep up to date. I know for BYOD Android support would be good to have, but in all other cases supporting just iOS as a mobile/tablet OS is enough (most other assessment solution providers also don't have Android versions). No reasonable institution will be so stupid to save a few bucks on some cheap Android tablets which probably will never get an OS update, have poor build quality and are poorly manageable by MDM. iPads get OS/security updates for 5-6 years at least and are used by all institutions which get the total cost of ownership math right...

[t00]

Hi Daniel,

Thank you for a really quick reply. Regarding the configuration incompatibility - you are right mentioning Browser Exam Key as it is exactly the compatibility issue I was referring to originally and which is fixed in our fork - so we are able to verify trustworthness of the SEB client by the IIS server application and include check for only supported executable hashes while invalidating others.

In general obfuscation will never stop attackers from getting around the security measure, I was hoping there is a plan for a better alternative to checksumming the executables - let it be mathematical, dynamic executable or some form of handshake - where the server hosting the exam will have a part in verifying client's identity.

I have not noticed Chromium change - there was some time since I looked into the code. It is great engine and regarding performance issues I only meant handling of seb(s) links inside the SEB by intercepting with navigate handler and loading new page (loading settings) without reopening the application - it may as well be all done already.

Android support is not essential although I somewhat disagree with claims about Andorid being messy OS to support (it has a clear lockdown features and code for these is open) nor about financial feasibility (you can but quality Android device for more money and have it supported for longer - usually applies to Google devices like Pixel) not to mention that Andorid code is constantly audited by multiple entities as opposed to Apple holding it internally except some handpicked libraries, open standard guaranteeing not being forced out of the store at Apple's discretion - just some security/business critical arguments.

If you will find some time, I am mostly interested in knowing when the new refactored windows application will replace the current one - and in which I should invest my time to (re)apply the changes. I am worried that if I will make the changes against current seb-win codebase, these will become obsolete as soon as a new application will be up and running. What is the driving factor of this refactoring?

[danschlet]

Obfuscation is no perfect solution, correct. But if your software runs on a system which is under control of the user (having administrator access or being clever and having physical access to the system), you can't find any perfect solution, regardless if you try it with "mathematical, dynamic executable or some form of handshake - where the server hosting the exam will have a part in verifying client's identity.". We are just starting a 2-years project for the SEB Server component, which will help to increase security when available, but as long as you use BYOD for the exam clients, you have lost in any case. You can only make it as hard and time consuming as possible to hack your security, and a obfuscated code module (combined with new keys similar to the Browser Exam Key, checking code signatures etc.) is one of the many elements to achieve this. With the SEB Server, we will also consider making this part dynamic, again to make it harder to hack it. One other element (already used by some of our SEB Consortium partners) is a small tool on a hardware write-protected USB stick with which the SEB version on a student computer can be checked, so with random checks of a few computers you can increase the risk for cheaters to be caught.

Android systems can easily be rooted, Jailbreaks on current iOS versions are no longer available since some time. Rooted systems require more security in a kiosk app (same problem as with Windows/macOS...). And Android is messy, as any developer developing for both systems, there are way to many different devices and OS versions which people will ask you to support. So we would really need a dedicated permanent developer for an Android version (development, maintenance, support, documentation etc.). If companies using SEB would contribute by becoming members of the SEB Consortium, we could finance this, but if companies just profit from our work without contributing, then this won't be possible.

And come on - aren't we past the silly discussion which system is more open source and therefore more secure? Any operating system contains that much code that it's impossible to ever audit everything (there are those coding contest where developers hide malware code in small open source code fragments and usually no one finds that code, even after auditing the code). And Android is just slightly more open source than iOS and macOS, which are based on Open BSD and a large number of open source libraries. Large and important parts of Android are not at all open source, as most Android users use all the Google apps and services which are closed source as well. You can't trust no operating system. And I definitely don't trust a company more which finances itself with advertising and by monetizing my data.

[danschlet]

Driving factor of the refactoring is that the current SEB for Windows code is messy and hard to maintain. But mostly we need an integrated browser engine (Chromium) and it's a good opportunity to refactor the whole bad code...

[t00]

That is great news you are implementing a server side part of SEB. In a month or two I will be looking into redoing some improvements I made against the 2 year old seb codebase and applying them to the current one - do you think it would be possible to include the seb-win and seb-mac compatible plist configuration library as a part of mainstream seb-win codebase with the current version of seb-win?

What I did was basically making Browser Exam Key hash identical on win and mac, generated using a separate C# library (I extracted configuration code from seb-win codebase) which can potentially be used by a refactored version of C# app and on server side. Most work involved formatting and sorting of plist keys and adding missing keys in both win and mac so both win and mac hash base is identical.

Rest of the changes involve configurable strings in win and mac apps and optional changes in handling of configuration loaded from command line. I can split these changes into smaller, relevant parts.

What is the ETA of the windows refactored app? I have a feeling it would be better off for me to extracting the configuration library with the current WinForms seb-win first allowing you to reuse it in the new app unless you plan to consolidate settings handling in the refactored app differently (instead of using plist-like config on both win and mac, serialize settings classes using protobuf or something similar).

Please let me know your thoughts as we need to update SEB in the next few months and I can help with the project.

[t00]

PS. I won't comment on Android anymore as currently lack of an Android version is not an important issue for us - I just shared some thoughts and experiences on the subject (I rooted Android phones in the past, there are numerous ways to detect root like many banking apps do and there are existing device lockdown apps which seem to work reliably which I also considered)

[danschlet]

SEB Server is now available as a first version: https://github.com/SafeExamBrowser/seb-server Refactored SEB 3.0 also available: https://github.com/SafeExamBrowser/seb-win-refactoring

SEB for Android is still not feasible, unless Google finally provides a single app kiosk/lockdown mode which works in BYOD scenarios. Existing kiosk solutions use tricks or work securely only on managed devices. Google could get some inspiration from Apple's Automatic Assessment Configuration / Assessment Mode, which works perfectly with BYOD and after iOS 9.3.3 or newer is now also available on Mac (since macOS 10.15.4). File a feature request for Android and if they implement such a mode, we can discuss an Android version again (as long as there are Consortium Members willing to pay for its development and maintenance).

[venkatonweb]

Hi,

I hope the plist xml needed to be encrypted and used. Please confirm. It will be great if someone can share or direct the code for encryption. I tried to use cryptography.cs for encryption and it didn't work. Not sure whether I made some mistake,

Thanks, Venkat