"IServ Schulserver" [1] is a commercial school server developed by a company in Braunschweig, Germany. The "IServ Schulserver" is a product based on Debian. The whole project started as a students' project.
The "IServ" is an insular school server (one machine for everything + backup server) that provides a web portal / communication platform for the school (reachable from the internet), manages the school's MS Windows® clients via OPSI [2] and provides other features like chatrooms, mail accounts, etc.
The "IServ Schulserver" has written quite a success story in various areas of Germany, recently. IServ has been deployed at many many schools in Northrhein-Westfalia, Lower Saxony and Schleswig-Holstein. You can easily find those schools on the internet, if you search the web for "IServ IDesk".
The company that is developing "IServ" has various IT partner businesses all over Germany that deploy the IServ environment at local schools and are also the first point of contact for support.
It's all hear-say...
So, last night, I heard about a security design flaw not having been fixed / addressed since I had first heard about it. That was in 2014, when one of the Debian Edu schools I supported back then migrated over to IServ. At that time, the below could be confirmed. Last night, I learned that the following is still an issue on an IServ machine deployed recently here in Schleswig-Holstein (its deployment dates only a few weeks back). It's all hear-say, you know. But alas, ...
Mass User Creation Modes
If IServ admins mass create user accounts or (updated 20190930) perform user import from CSV-like data following the product's documentation [3a, 3b], they can opt for user accounts to be created and made active immediately, or they can opt for creating user accounts that are initially deactivated.
If the site admins uses the user import tool on the other hand, they also can opt for activated or deactivated accounts ot be created and they can choose one of the available password creation strategies (password := login (default), password from CSV, password generated via pwgen).
The password creation strategy of the local supplier of IServ Schulserver in Schleswig Holstein (around the area of city of Kiel) seems to be creating these initial user accounts (that is, all contemporary teachers and students) with immediately activated accounts and the default password creation strategy (password := login). (Cough cough...)
Initial Login
If you are a teacher (or student) at a school and have been notified about your initial IServ account being set up for you, you will get the instruction to initially log into the IServ web portal. The school provides each teacher with a URL and a login name. The default scheme for login names is <firstname>.<lastname>.
The password is not explicitly mentioned, as it is easy to remember. It is also <firstname>.<lastname> (i.e. initial_password := login_name). Conveniently as it is, people can do these logins from anywhere. When doing the initial login, the users are guided to a change-password dialog in their web browser session and finally, they can set their own password.
Pheeeww.... one account less that is just too dumb easy to hack.
Getting to know People at your New School
Nowadays, most schools have a homepage. On that homepage, they always present the core teacher staff group (people with some sort of a leadership position) with full names. Sometimes they even list all teachers with their full names. More rarely, but also quite common, all teachers are listed with a portrait photo (and/or the subjects they teach). Wanna be a teacher at that school? Hacky-sign up for an account then...
Update (20190930): To be fully clear on this: IServ does not provide a Sign-Up Feature byitself, all user accounts get created via an import of school data taken out of the school's administration database. However, picking an existing account that is likely to be still fresh and untouched by its user, is pretty much as easy as signing up for an account on.
How to Get In
If you are a nasty hacker, you can now go to some school's homepage, pick a teacher/face (or subject combination) that makes you assume that that person is not an IT-affiliated-kind-of-person and try to login as that person. If you are a neat hacker, you do this via Tor (or similar), of course.
Seriously!
If our imaginery hackers succeed with logging in using initial credentials, they can set a password for the impersonated teacher and they are in.
Many schools, I have seen, distribute documents and information to their teachers via the schools communication platform. If that platform is "IServ Schulserver", then you can easily gain access to those documents [4].
My personal guess is, that schools also use their school communication platform for distributing personal data, which is probably not allowed on the educational network of a school anyway (the "IServ Schulserver" is not an E-Mail server on the internet, it is the core server, firewall, mail gateway, Windows Network Server, etc. of the school's educational network).
Now, sharing those information via a system that is so easy to get unauthorized access to, is IMHO highly negligent and a severe violation of the GDPR.
Securing Mass User Creation
There are several ways, to fix this design flaw:
- mass create users with accounts being initially deactivated and come up with some internal social workflow for enabling and setting up accounts and user passwords
- talk to the developers and ask them to add credential imports (i.e. mass setting passwords for a list of given usernames)
- Obsolete 20190930: use some other school server solution
- Update 20190930: the previous statement about just using another school server solution is not really leading to better security by itself. The problem here in this blog post is not so much about IServ's user import code, but about the combination of software-featured setup strategies and that service providers deploy IServ in such an insecure manner (although more secure features are available, but not the default). So, I could also say: get another service provider. People who, when setting up school IT, are aware of the security impact of their doings.
Other Security Issues?
If people like to share their observations about school IT and security, I'd be interested. Let me know (see the imprint page [5] on my blog for my mail address).
light+love
Mike Gabriel (aka sunweaver at debian.org)
References & Footnotes
- [1] https://iserv.eu
- [2] https://www.opsi.org/
- [3a] https://iserv.eu/doc/manage/user/multiple/
- [3b] https://iserv.eu/doc/manage/user/import/
- [4] ...assuming that the mass user creation created initially activated accounts.
- [5] https://sunweavers.net/blog/node/69
Update 20190930:
Last Friday, I received feedback from Sören Wendhauen (IServ GmbH). He provided some more background information about IServ user import. Thanks a lot for that.
Admin coaches at IServ GmbH do in fact make there service partner businesses aware of what I have depicted above. So, service providers should be in the loop of the security weakness (and act accordingly, I'd expect).
However, (and that was the essence of my reply), they (IServ GmbH developers) nonetheless developed this "password := login" feature in the first place, made it the default password generation strategy and even now that they have more secure password creation methods at hand, they leave the "password := login" method the default method.
Another alternative: If user accounts are activated at creation time and if the "password := login" password creation method had been used during creation, the IServ WebUI could e.g. prohibit a world-wide login, but restrict the user login to the computer labs of the school. Not a good solution, but drastically shrinking the attack vector, while keeping the wanted usability. However, this only works at schools where computer lab access is always monitored by teacher staff.
With Dürrenmatt's "Die Physiker" in mind, as a software developer I am responsible for the features I give people at hand to use and/or misuse.