To Care or Not to Care

by deadbeat0

Sometimes, the most irritating about a school's informatic system is not its weakness, but the state of mind of its administrators that it shows.  A while ago, during high school, because of a timetable oddity, I had two hours to kill each week that I spent in the computer lab.  It allowed me to discover some impressive vulnerabilities in my school system, and it made me ask myself some important questions.

First, the school was monitoring each computer activity using software called iTALC.  A huge problem was that every student had access to the C:\Program Files directory, hence to iTALC's directory.  The only solution the system administrator found to prevent students from tampering with it was to deny student sessions the privilege to delete the main executable...  But it was the only file of the installation directory that was protected, so delete the .DLL, and voilà!

Then, being curious about how the whole system worked, I started digging around my school session's filesystem.  All of the school sessions were stored as directories on D:\USERS\ and each session's privileges made it so one could only access his folder.  But what bugged me was that, at the root of my session, there was a .CFG file named after my username.  Once opened, it displayed the following structure (translated from French):

STUDENT session_username,,session_password, SURNAME FIRST_NAME D:\USERS\STUDENTS\username

From there, a simple .BAT script copying any .CFG file found on a computer could allow you to automatically copy any opened session's credentials on a USB key and create yourself a huge database of sessions.  Of course, the trick also worked on teachers, giving you access to their shared drive, and also the school marks and test subjects.  The most ridiculous thing about this one was the way to prevent it.  All it would have taken was simply to ask students and teachers to change their passwords at the beginning of the year, as the one that was in the .CFG file was the default one.  But not a single person in the school had changed theirs.

Finally, the worst vulnerability.  After exploring a bit more of the D:\ drive contents, I came across another folder containing the programs that were launched each time someone logged in.  The whole startup sequence relied on a huge list of .BAT scripts, one for each session.  They called binaries and other scripts used to set up the environment for the session to log in, assign the IP, assign the privileges, and the home directory.  So by analyzing one of the scripts and understanding how it worked, you could forge your own session with its own username and password and decide on your privileges: student, teacher, or admin.

After all of this, I asked to see the administration and system administrator to inform them of these extreme vulnerabilities.  During the meeting, they only showed annoyance and disrespect, which was not exactly the logical state of mind I would have expected.  Such were the vulnerabilities that you could bring the whole structure to its knees after having used their tools to create yourself an admin account, or take control of any computer in the school by using iTALC with a teacher session!  The only knowledge you had to have was a single line of batch to copy files.  That's it.  No Kali Linux thumbdrive, no Metasploit.

In the end, the only answers I received were a threat of exclusion from the administration and being told by the system administrator that students were "too dumb to find this' and that simply protecting more directories would be "too much work."

This left me with a bitter taste - and a question: how can you expect people to respect your rules if you show them that you are not interested in their safety and do not care about them?  It is one of the strongest values of the hacker community to question the authority, and show its weaknesses to everyone.