I am sure you have already thought of this, but what about remote desktop access?
Here is the scenario someone suggested to me today:
1. Student installs SEB, goes to the exam, runs SEB, etc. as we expect.
2. Studen't friend, outside the exam room, makes a remote desktop connection to the student's laptop, and with the help of Google, answers all the questions, while the student in the exam room pretends to be typing and moving the mouse.
I assume SEB blocks remote desktop access, but I wanted to confirm that.
SEB on Windows checks some Windows flag which indicates that the display data is streamed over a remote connection. I guess that should prevent the case you're mentioning, but maybe not all remote desktop clients set that flag. Feel free to test how well this works.
In OS X there isn't such a flag as far as I know. I will investigate how I can programatically turn of specific network services like screen sharing, remote management, remote login and VNC. Another way would be to implement advanced system-wide filtering of network access, similar like Little Snitch does, but this is not trivial to manage (which network access from what application/process is ok or not) and to implement.
With the advanced process monitoring in SEB 2.0 it should be possible to stop undesired services like remote desktop clients etc. by not allowing that applications or helper processes to run (killing them). One problem is: if only blacklisting would be possible, then we would need to build up a large database of potentially risky applications. At least on OS X, blacklisting should only be necessary for blocking unwanted system services like Apple Remote Desktop, because I'm working on checking code signatures of the binaries belonging to running processes and allow only those which are signed by Apple. All third party applications and services will be blocked by default and need to be added to the whitelist if you want them to run together with SEB. Testing this in practice will be necessary though. In Windows 7 only drivers (and installers) seem to be signed, so there it will harder to identify them properly and to distinguish between processes which belong to the system and third party stuff. Next week we will find out more about the brand new .NET Windows SEB version (which was refactored externally) and start testing, also that process monitoring.
In general I would say we will never be able to block everything. On properly managed systems this wasn't necessary until now, we don't know about cases where students would have tried to cheat like that (we're using SEB since 2008 for exams). The game will most probably change when such big universities like OU will start using SEB on student computers. So in future we will have to put more effort into closing possible security holes (and to identify them). And we will need hints about new security problems, testing and feedback from the community using SEB…
We're also working on the specification for the SEB Server, a third component in addition to the examination computer and the LMS server. Besides managing exams and the SEB exam clients, this will include logging of all activities on the exam clients, which will help to discover and avoid such fraud.
And as we always tell people: Good proctoring and supervision during the exam by humans will always be most important, as there a many ways of cheating which cannot be stopped only by software…
Thanks. It looks like you are aware of the issues, and will have a reasonable solution for this in due course, even if there are issues now. Thanks.
Has there been any update on how SEB on OS X will deal with this?
Just tested it out with windows/mac remote desktop clients connecting to windows server and running seb there. There the virtual machine check works fine.
But doing a quick test with vpn towards another user account on my own OS X computer, I was allowed to open seb without any warnings.
When SEB 2.0 is finally released on OS X, will using the prevent applications (or event the allow run inside virtual machine checkbox) be able to stop scenarios like this on OS X?
I'm aware of not everything being stoppable by software, just wanting to hear if there are any thoughts on my exact test as it works quite differently on mac and win.
Please describe closer what you were doing on your Mac, do you mean VNC (not VPN)?
I will investigate how to stop network services like VNC while SEB is running, also the future prohibited applications feature will be helpful in future, as third party remote access solutions may use their own protocol and stopping known services like VNC would not stop these.
As soon SEB 2.0 is finalized, we will work on hardening its security. On the Windows side we are already on this point, RC6 will bring significant improvements and new features. Thanks to the new Windows developer I'm now also able to again work on the Mac version.
yes, the Windows version is starting to rock now, so getting the mac version up to speed would be great :-)
Yes it was vnc, not vpn! I installed realvnc (didn't test remote management which is more enterprise and expensive) as the cheapest virtual machine test I could do.
In security on my mac, I turned on screen sharing added another user account for that, and opened vnc viewer connecting to the vnc account.
This is a quite fast way to get virtual machine up and running towards your own computer to have a cheat account.
The reason I did this is that on a test exam done on a University with BYOD SEB, a mac user was able to get around this virtual machine test, and this was one way I reproduced it. We haven't gotten the full detail on what was actually done.
I have just tested if it was possible to remote-control a Windows (7) PC running SEB 2.01 with TeamViewer. Unfortunately, that was possible. Is there any news on when/if this security-hole can be remedied?
Or is at ways to get around this problem, using e.g. the "Applications -> prohibitet processes" functionallity?
Some remote desktop and screen recording tools don't work with SEB when the "Create new desktop" kiosk mode is used (see Security Pane in SEB Config Tool). SEB also sets a Windows environment variable which disallows remote desktop connections, I guess TeamViewer doesn't respect that.
Those remote desktop solutions which still work could only be stopped with the prohibited processes monitoring. Try to find out how the TeamViewer background process is called (probably it is a Windows Service, see the according tab in the advanced view in TaskManager). Then add this background process executable name in the Prohibited Processes tab in the Applications Pane.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.