K12 Tech Departments Respond to SH1MMER

All the stars aligned in January for SH1MMER, a big stinkin’ problem for schools and organizations managing Chromebooks from select vendors and select chipsets. SH1MMER allows end users to unenroll their assigned devices from organizational management and ultimately avoid device restrictions applied by their institution. You might think of it like a jailbreak for school devices. And it was created by a group of… you guessed it: teenagers. Specifically high schoolers and one middle schooler, who call themselves the Mercury Workshop team (MW). This group reached out to the K12 Tech Talk Podcast last week to clear the air on a few things. Now that we’ve had the opportunity to talk to some of the people at MW, and had a few days to download and try SH1MMER ourselves, we have a better understanding of the implications of this Chromebook vulnerability turned exploit. So, let’s talk about how we got here and what we can do moving forward. 

A big deal or nah?

First off, is this actually a big deal?

Some schools have said they can mitigate the exploit through network access controls and by creating alerts for inactive devices. These mitigations may discourage students from using it on their school-issued Chromebooks. But in the sense that an institution’s ability to control its devices, at the most fundamental level, has been compromised — yeah, it’s a really big deal. All it takes is a person with a little know-how to unenroll a device. If a student doesn’t bring a device back or it goes missing, an individual just needs SH1MMER to set it up as their own.

We’ve spent a lot of time debating how much airtime to give this topic for fear that it would shed more light on a situation that we’re trying to control. Ultimately we’ve recognized that this is an inflection point and a learning opportunity for all involved. But who is involved, and who needs to learn a lesson here? Let’s unpack that.

The proverbial finger-pointing game

Ultimate blame

To paraphrase Josh from the K12 Tech Talk Podcast: Every device has a vulnerability. But how easy that vulnerability is to exploit is another discussion.

In this instance we are dealing with what appears to be a security-by-obscurity setup. And guess what: in any instance where students are involved, they will find that obscure method to get around it. This is not to call MW’s exploit elementary; we’ll continue to unpack that at a later time after we’re able to analyze the exploit in more detail.

The fact that the exploit was created is huge. It will draw ire from some, brings up legal questions for others, and ultimately lands us in an ethical conundrum. As Mark from the K12 Tech Talk podcast said, just because you found an unlocked door does not mean you should open it. So to MW: we see you and know that what you did to open that door was creative and innovative —- but tread very lightly. Just because you found a way in doesn’t mean you should be there. Again, to quote Mark: “Please use your skills for bettering yourself and bettering your community. Be very careful going down this pathway. Because your skills have clearly opened up a lot of doors, they will open up a lot of doors. You can quickly close those doors.”

So much to say, ultimate blame for the exploit does lie with MW, but we’ll talk more about motives and reasoning later when we get to lessons learned. 

More blame

The second layer of blame here lies with the creators of the hardware and the software/OS. In this instance it appears to be Lenovo that had shims available for this group to find, then Google for creating a boot system that could be compromised with access to and modification of shims. 

MW indicates that they found the shims on a publicly indexable site. Rafflesia of MW mentioned to K12 Tech Talk that “Lenovo kept all their shims public and we found them indexed on Google.”

Whoa. If this is true, whoa, Lenovo. And even though it might have been on Lenovo’s site, those shims apply to all Chromebooks using the same boards as Lenovo. Again, Rafflesia mentions, “The shims aren’t manufacturer-specific, they are board-specific, meaning a Lenovo shim for Octopus will work on a Dell Octopus Chromebook.” A full list of affected boards can be seen by accessing the public file share published on SH1MMER.me.

You can reference these board names to see if they apply to your model of Chromebook on Chromium.org.

To date, Google has not done anything more than release statements that they are working on fixes for this. We found the statement along with some remedial steps by Google on edugeek.net.

Google is aware of an issue affecting a number of ChromeOS devices, which requires Google to collaborate with ecosystem partners on a fix. User data on impacted devices is not exposed. As a security best practice, we recommend Enterprise and Education administrators monitor for unenrolled and inactive ChromeOS devices.

 Our exchanges with MW indicate they believe there will be nothing Google can do for current hardware, only hardware moving forward. To quote MW’s Rafflesia: “While Google is working on a fix, the fix is likely going to take a while and only affect models released from today onwards, existing models will continue to be affected, as this is a bootrom exploit basically.” She also points out that “the actual exploit itself takes advantage of a flaw in the initramfs.”

So this is a flaw in how Google has set up the boot security of the Chromebooks. Rafflesia says, “Shims aren’t actually supposed to boot for enrolled Chromebooks, and it checks for that, but the check passes since the check in the shim initramfs doesn’t mount crypto home which stores the enrollment information.”

Final —- and initial —- blame

But where did it all start? How did these high school students even get this idea?

Well, it was us and our naïveté, collaborating in an open forum on Reddit.

From the SH1MMER credits page: 

Just a few techs talking about the Chromebook repair menu, and they started talking about shims. These kids were lurking there and realized this was the real starting place. If they could just get a hold of some shims, they might be able to engineer the process further. And the rest is history.

Lessons learned

We can play an entire game of what-ifs here. If it wasn’t MW, it might have been someone else. If Lenovo hadn’t (allegedly) had the shims available publicly, would we be here? If Google had just engineered its boot process differently for enrolled Chromebooks, would it be a different situation? If these techs hadn’t been talking about this in a public forum, would these teenagers have found their starting point?

Yeah, we can play that game, but it does us no good. Clearly all the stars aligned and MW was able to create this exploit. There’s not much that can be done other than set up alerts to let you know when a Chromebook is showing inactive, follow Google’s remedial steps, and hope and pray that Google comes up with some means to reverse this problem on the affected boards. 

But there is more to this situation than taking the sit-and-wait approach, playing the blame game, or asking what if. There are plenty of lessons to be learned. We’ll address them by each party involved.

School technology departments, administrators and teachers:

MW wanted us to know they created the exploit because they believe their privacy is being infringed upon. When pressed on why MW created the exploit, Rafflesia said, “Well, it’s a bit complicated on that front; the purpose is not for theft, but rather more so for student privacy.” She said she felt uncomfortable to have ”something watching me 24/7, especially when it’s the only device we are allowed to have in a place we are forced to go.” She also mentioned that schools should do more to help students be safe through self-reporting programs as opposed to using technology-monitoring software. 

We’ll all go through disagreement with what level of monitoring is acceptable, but the reality is this: students need us to take their safety seriously, and they want us to take their privacy seriously. Students are legitimately asking us to ensure that their right to privacy is protected and that they are kept safe in our schools. 

We hear you loud and clear. We can’t promise that you’ll have invisibility on our networks, but we can promise you that we’ll take your concerns seriously, and we will do our best to ensure your security/privacy and to involve you in conversations around those topics.

Mercury Workshop team (and all students):

School technology departments care about you. Genuinely. We don’t set up restrictions because we want to spy on you or make your day more difficult. We’re genuinely concerned for your safety and trying to ensure that you are able to do the things you need to do in school to keep learning to the best of your abilities. Many of us are required by federal law (CIPA) to filter the content on your devices. This is to ensure that objectionable and obscene content doesn’t come through to you while you are using a school device. We have to abide by this law. With regards to monitoring software that monitors for sentiments, we employ this to ensure that we are doing everything within our power to get you help when you need it. In my school alone, I have been able to use our monitoring software to catch suicide ideation, bullying and other threats. 

When something bad happens in a school, one of the first things people ask is: “Could the school have done more?” We’re always trying our best to do all we can, and you know as well as we do that technology can be used for bad and it can be used for good. We try our best every day to use it for good and to give you the best experience. Many of us around the country and the world working in school technology are underpaid, overworked and, as a whole, undervalued — but we do it for you. We truly care. 

MW, and all students, your technology department would love to work collaboratively with you. We would love to help you find avenues into the career of your dreams in cybersecurity or the tech field. Let’s harness your endless creativity and ingenuity to do great things for your community and your country as a whole. Please, let us work together. 

Google, Lenovo, et al.:

Please, pretty please, come up with something better to ensure institutional devices can’t be unenrolled. And as far as shims go, maybe make access to these not so ubiquitous or (allegedly) publicly available. 

All K12 tech pros:

We need to find a better way to talk about sensitive topics, including device repair, content filtering and network security. Public forums are where many lurk to find our vulnerabilities. Here at K12TechPro we’re dedicated to helping techs find this avenue for secure communication, and we’ll be trying our best to develop something in the near future. Because we all need a place to be able to collaborate and become the best professionals possible, but we need to do it in a place where we can verify identity and control access. 

While all the stars have aligned to SH1MMER, not all hope is lost. We have much to learn, and I hope we can keep an open line of communication between all parties involved — to make a better future for device security, for student data privacy and student safety, better communication with our students, and more secure communication about sensitive topics school techs need to talk about. 

We’ll revisit SH1MMER in the coming weeks. A big thanks to Chris from the K12 Tech Talk podcast for facilitating the email exchange with MW this week. And to Josh and Mark, thanks for taking my incessant questions and calls for information and opinions. 

We at K12TechPro are committed to helping empower school technology personnel to learn, communicate and collaborate in a secure manner.