>>   Good morning and welcome.  I know this is kind of early Sunday morning.  Appreciate you guys all being here.  Today we're going to be talking about hacking and implanting a DropCam.  So we both work at the R and D team at Synack and does crowd source vulnerability discovery for embedded security researchers. My name is Patrick Wardle.  I worked at various acronymed places.  I'm the Director of Research at Synack.
>>  I'm Colby Moore.  I work at Synack as a Research Engineer.
>>  Security ninja I think.
>>  First a brief overview of DropCam then how we got a root shell on the device.  Following we'll talk about some vulnerabilities we found and then finally we want to present a persistent implant that we designed for DropCam.  First let's talk a little bit   ‑  ‑   get a little bit of overview talk about some background information, talk about what DropCam is.  Before jumping in I think it's a good idea to concisely define any possible ambiguous terms especially since it can be confusing.  When we talk about implants we're talking about persistent code that is malicious.  Intercepting function calls by installing a hook or a detour.  A Trojan is malicious piece of software that pretends to be something legitimate.  Injection is about getting code into a process and finally a back door is some code that provides, you know, undetected remote control.  So what is a DropCam?  Well, as you can see from their definition it's a cloud based video wifi solution.  The core of it is the camera.  So besides incredible simple setup, it features cloud recording night vision, two way talks and intelligent alerts.  Now one of the main appeals of DropCam is its trivial set up.  All the camera needs is the name and password of your wireless network.  There's two ways to do this.  This configuration can be done by plugging the camera into a commuter with a USB or a smart phone that has bluetooth.  The camera will be connected to their wifi network.  From then on its fully autonomous.  It will stream audio and video to the cloud and beacon to the DropCam server for updates.  So a lot of IT based video solutions out there so what's special about DropCam.  Well now DropCam is owned by Google and Google has indicated it will become the core of their push to connect at home.  Soon there will be DropCams everywhere.  When we started this research we didn't know Google was going to buy DropCam.  It's really popular, a top seller on Amazon..  You see it all over.  Secondly it shows up in interesting places like homes and offices.  Again, the bay area, all the startups use DropCams for their security solutions and finally it's kind of a juicy target that has some really cool capabilities that we thought were pretty powerful and were begging to be abused.  Now we'll talk about rooting a DropCam. 
>>So, based on the network, it's.  The first thing to do is get the camera opened.  Conveniently DropCam left us this mysterious header right here.  Probing around revealed what looks like the 3.3‑  volt UR on there.  So, hooked it up to the FTD serial to USB connector you guys are all familiar with and here's a little photo showing our ground connection.  So after a quick reboot, DropCam through the, Admin, admin, the standard but  really no luck.  So, I suppose I should probably mention the DropCam is running on a Linux system on chip from a company called Amberela based in the bay area.  We figured we would take more of a Linux view approach.  So, we started to go up to the bootloader.  If you hold enter on power on or you short the transmit and receive line when you power on the device it should drop you to the bootlegger.  Now, looking at the bootloader we got a couple operations.  The set didn't look too promising.  Looks like there's an operation to change the boot parameters.  So, we went ahead like with a standard linux, and changed the input parameter.  And that yeah, that worked .  
(Laughter).
>>  Now we got to get rid of that password.  So, we checked out etc shadow and it wouldn't open so looks like it was   ‑  ‑   it gave us the necessary information needed.  We mounted it up and now we have access to the file, went ahead and just knocked out the hash and saved, went ahead and rebooted and reset the boot parameters in the boot loader and rebooted the boom. We have a full feature root shell.  We kind of have a little bit of a different opinion.  So we're going to talk a little bit about the  vulnerabilities first let's talk about the environment.  Since we have a root shell we cannot poke around in explore.  The DropCam is running armed 32 bit Linux and the heart of the DropCam is this connect executable.  We'll talk about that a lot later.  Also left all sorts of goodies on the device for us, drop bear, FTP, GB server.  So, overall, DropCam is decently secured.  There were open ports and no exposed network services.  All communications were SSL drop load.  And the DropCam employs device specific provisioning from the factory and that's likely why we couldn't drop the boot password.  It employs automatic updates and the push cam hold devices request so it's pretty row bust in that sense.  But let's take a look at the first bug.  
The camera is using open SSLs for coms dropcam service. It's running on an old version o f software so it's exposed to heartbleed.  So, what can we do with that?  DropCam says our cameras communicate with anyone only DropCam services.  That's not true.  It will download the camera's private and public to use among other applications.  So, realistically now that we have these what can we do.  Normally the DropCam talks to the cloud by SS and will user devices gets the video from the cloud.  You should know it authenticates the same feed we stole.  Provide false video to the cloud DVR.  Should the user really trust what they're seeing?  We notified DropCam of this bug and they patched it.  If anybody happens to have a certificate, we don't, there's nothing the consumer can really do at this point.  So then for most of its functionality DropCam, the version is outdated.  Basically it's an old bug there allows command injection via malicious cve response.  Use area assembly to inject commands using the host name parameter.  This is only triggered if the host name is used by another utility.  But we checked out the vulnerable source code and compared it to the disassembly from DropCam and it definitely matches.  So, we weren't able to trigger this bug right now about DropCam isn't using the host name in a way that would trigger this.  So, all those bugs are pretty cool.  We had to open up a camera.  Wouldn't it be nice if we could implant the device without opening it up.  Luckily there's an app for that.  It's called Direct USB.  We found a copy somewhere on the dark part of the internet, especially Russia.  If you hold down the button on the back of the cam remark the button DropCam swears does nothing, if you hold it down, there's a firmer update code and we believe this was how the device was commissioned at the factory.  Ultimately we were able to read and write unsigned data together.  (Inaudible) we call that   ‑  ‑   
>> So there's more to Dropcan than just the software that runs on the camera. So recall  a user may use their computer -- to this to do this the camera is plugged into the computer and then it mounts part of the camera.  Its utility which requests root privileges to run gets the SSID and password at the wifi network and then pop gates that back to the camera.  The end result is a connected and configured camera.  Unfortunately this application which runs the boot is writable so an approval concept a n nprivileged hacker can wait until any DropCam is plugged in.  It can inject a malicious pay load into the mounted DropCam setup utility.  Now when the application is run an elevated and so is the hacker code.  Dropcam is still patching that at this time so cannot go into it. The Windows installer set up privilege has a considerable vulnerability as well.  CEO of DropCam said their cameras only talk to DropCam servers which is discounting things like heart bleed is true.  SSL pining is a extra layer of security that ensures a client will only communicate with a well defined set up service.  Since the DropCam iOS application does not use SSL pining is an extra layer of security….. of  man in the middle attack can occur.  If an attacker has compromised root certificate or coerces the user to install a certificate sending them E‑  mail connection can be man in the middle.  So here we have a capture showing a man in the middle attack action actually against my own phone.  It reveals a user name and password for a DropCam account.  Now since DropCam does not use dual DropCam or as session alerts an attacker can surreptitiously spy on the user at any time.  This is really good for the bad guys, not the good for the rest of us.
>>  Now that we have a good way to implant the camera let's have some fun.  Introducing our full featured implant, cuckoo's egg. For those that are not aware, he cuckoo lay's it's eggs in others nests. Giving the robust capability of the DropCam as malicious software should you want to be able to intercept a room, here you want to hot‑  mic a room, propagate, we want to infect other hosts when they are plugged in. We wander to be able to Geo locate the DropCam so we send a bunch out in the wild.  We want to be able connect a basic serve an device.  We need a method for other devices on DropCam's network.  We also need a method   ‑  ‑   sorry.  Okay.  Any way.  So, our implant, cuckoo's egg, comes with a slogan.  It's easy when you're sleeping, he knows if you're awake, he knows if you've been bad or good like the NSA.  So in a real world scenario how do we install our software.  Currently we don't have remote code execution but there's a lost options.  We can intercept the package in transit, we could maybe give the DropCam to somebody or we could break and enter and modify in the house.  Realistically that stuff never happens, right?  No further comment.  We approach DropCam about this and they were convinced an adversary wouldn't be able to reach a DropCam.  Then alone would be an inappropriate anti‑  tampering mechanism.  What do you guys think?  Now what about sending one as a gift.  Incubator space was broken into.  Security cameras implement?  Probably not.  Breaking entering scenario plausible?  Only one third of user sign up for DropCam's depository.  Even then if you showed up with a wifi camera the camera doesn't patch into the video local.  So what makes DropCam a good target?  The DropCam CEO said all software products are susceptible to jailbreaking.  That's true.  We tend to agree with that.  The DropCam really is low hanging fruit.  Here are the other options.  Someone can go after a computer, they can go after   ‑  ‑   you got to crack it opened and you can't see it, can't hear it there's a lot of things.  It can go after a gaming console, go after a mobile phone, run time code and it's off person.  So the DropCam you don't need to open it up.  No password, no signed code, the operating system is open source, its always on, there's tons of capabilities and who is going to suspect a security camera is spying on you?  So.
>>  So in order to create an advanced implant.
REPORTER  Plant we need to fully understand how the DropCam works.  In other words we had to answer questions such as how does it hear see or think, what is its core logic, the main module and finally can this be manipulated or rewired.  The DropCam has many hardware and software components.  However these all kind of come together in the connect wire, which we'll be talking about lot.  The brain of the camera, it contains most of DropCam specific operations such as talking through the audio and video devices, streaming content from the cloud and also handling or executing command that are received from DropCam service.  The connect binary is hacked, UBX which is not normally a problem.  When we tried to unpack it, it failed.  Since we wanted a full unpack that would make everything easy from the bugging to the analysis we decided to look into this a little more.  Now the unpacker stub matched the UBS source code indicating it wasn't custom version.  Single step through unpacking self instructions and follow it along in UBX source code which wasn't fun.  The code was checking a value within the binary and then branching into a code path or a hacking shared library that unfortunately errored out.  Now connect is a normal executable, it's not a shared writable code.  We decided to write a small Python script.  Once we did this we then reinspected UBX and that works.  Connect was fully unpacked and fully runnable, which was really nice.  Using the inverse of this technique, so setting that member in the elf header we were able to create unpackable binaries as well.
>>  So now that we've talked about capabilities we'll talk about the core of our impact.  We wanted to create something simple and have the ability to leverage third party libraries.  So, high functioning.  Cross compiled and stripped down Python.  And then Python then extracted the ram, boot and implants and descriptor.  It's great we have an implanted camera but how is it going to talk to us?  All coms are done over HGTPS and go out over the secure spiral.  Our command and control and streaming data are set on separate channels and CNC services  are set on the same as DropCams.  Given the nature of our com's wouldn't be that easy to tell the difference between a drop   ‑  ‑  (?) our   ‑  ‑   regular DropCam traffic and our implant or even create appropriate IDS rules.  Connection's legit.  What about if we wanted to ship a ton of these cameras out into the wild?  How will we know where they'll end up?  Cuckoo's egg  server and ships it back to the CNC server.  The CNC then send it back to Google and returns the device location.  Thanks Google.
>>  We also wanted our implant to autonomously to Windows and Mac.  Since we (Inaudible) we actually controlled the setup application as well so we simply replaced it with a malicious.  Now whenever the user runs the implant or the setup application they're actually running the implant first, executed with root.  We often use a holograph attack so it's hard to tell which binary is the malicious one.  We also made sure to disable the bluetooth setup feature so the user was forced to plug the camera into the computer in order to couldn't figure us which insured they would infect their computer.  Apple   ‑  ‑   some of these are triviallybypassable while others can be avoided altogether which allows our implant to execute freely.  So if you want more information we gave a talk about this stuff at Shock a con.  This talk describes bypasses for Apple's anti‑  virus component, gatekeeper, the sand box and even sign coding on fios unsigned kernel module   ‑  ‑   so sorry apple.  A major component of our implant is the ability to grab and manipulate audio and video.  Data is read from these devices streamed to the DropCam cloud servers where it is consumed by the user.  First I want to talk about how our implant is able to hot‑  mic the camera.  Since the connect binary exclusively opens the audio card it has to inject a module into the connect process.  Here are the various relevant components.  The connect binary is continuing reading the audio stream.  Injected module can install a hook and gain access to the audio stream and then install it to our command and control.  Our DropCam uses a standard (Inaudible).  So to get the audio it invokes suspend MCM read end function which retrieves audio framed audio.  This is where the implanter installs its audio.  Again the goal is to clone the audio and stream to the server while letting it use parallel up to DropCam.  So here's the code that is inserted as an auto hook.  This code gets appointer to the original send PCM read function invokes it and exfiltrates any data or audio that's captured so pretty straightforward.  
Now, on to the video.  By disassembling the connect bindery we were able to control how the video accesses and streams.  You can see it opening the video which is 
/dev/iav.  This device is backed by a chip that does all the video processing in h264 hardware for  obviously hardware performance.  Second disassembly snippet shows connect binary talking to device to get the actual video via an octal. The an octal are undocumented and many take the documented structures.  L uckily there were some comments or error message in the disassembly so we could maybe kind of get the name of the an octal which gave us some insight into what it was doing.  We wanted to clone the video and stream it to the implant servers.  Undo you mean (?) octal resulted in a ton of reverse engineering.  We got it all figured out and we want to describe that here.  So.  So first you open the slash tab slash IAD device.  You then match the bit stream buffer memory and a digital signal process.  Now after you check that the video is actually up loaded the video stream can be read with IAD read bit stream   ‑  ‑   bit stream EXIoctal.  It actually allows you to stream the video to a server or DVR of your choice.  Save your money so you don't have to pay DropCam $30 a month to store your video and it also prevents Google from seeing what's going on inside your house.  That's kind of a   l feature.  I don't want Google to see what I'm up to.  Now we could clone the video feed send it to our implant server parallel to DropCam but we thought we wanted to take this a step farther and actually manipulate the live video screen on the device.  To do cool things in the movies for example making an attacker invisible.  Here are the various relevant components.  The video card is going to generate frames which will in this example show the attacker breaking in or doing some bad things.  We really don't want that.  However the injected module will intercept each frame and inject other frames.  These injected frames will then be streamed to the cloud instead and actually back which will hide the attacker.  Take a little bit of a closer look.  Here's the video device and the connect binary which is reading frames.  The injected module installs another hook this time it's an IOCTAL and watches for the IOC read bit 16's IOCTAL.  It populates a structure with various values.  Through reverse engineering we were able to determine what the values were.  Some of the relevant ones include the frame number, the address to the frame's raw encoded data, the frame type and finally the frame size.  Now the easiest way to manipulate the video screen is just to wait for frame type and then moving forward you can either just replay the frame or actually inject other full screen frames as well.  Other frames are not ideal because H26 encoding pretty just encodes Deltas.  These JPEG full frames happen every second, so it's pretty easy to wait for them and then use them moving forward.  So, video demo time I'm wanted to show you how we can transparently lock the video stream.  If you look at the top left is the DropCam feed so this is what the user's going to see and this is what we're manipulating.  The top right is a shot from an external camera, bottom left is a CIS log output.  All right.  Sorry, this is a little... all right, so you see a mom coming to tuck her kid in, so if you look at an attacker's window they're going to then run the unable command to activate the video log.  You then see   ‑  ‑  
(Laughter).
>>>  And attacker that somehow looks like Colby.  The video now is lost frame, injecting the frame.  You can see the camera is still.  Then we run the disable command which tells the camera to resync and then it's going to flip back.  Now I'm sure the mom is going to accept this child as one of their own.
(Laughter).
>>>  All right.  Okay, so we've built this awesome implant that does everything an attacker could dream of. How do we control it?  So, naturally a sleek main screen all the cameras call back with their name locations so targeting is super easy.  From there it's easy to select a target to be sent down to the drop kit.  The camera calls home to the CNC server at a standard interval, to report job results and get new jobs from the queue.  If a series of completed   ‑  ‑   here we have a series of completed and unsent jobs cued up as an execute  (?) tasks where as there are several completed surveys. Reports are reported in a convenient (?) format.
For the next part we need a bit of a disclaimer.  What we're about to do is theoretically possible on any process not just DropCam.  Easy enough and there's lots of free space inside of DropCam it's conceivable.  Someone turn this device into a server weapon.  Most embedded systems contain a GPI.  Since we don't have the device schematic generally founded on wanted to use a   ‑  ‑   in this case decided interface with the DropCam status.  Stats LAD hides.  We need add way to do this intelligently because the light comes on randomly and we didn't want to be setting off whatever we're doing intermittently.  So, here's some pseudo code do show what we D we figured out how to separate in the a loop up there.  Then we installed the mic to listen to the square wave of what we're generating.  It's looking for that frequency.  When the microphone gets the frequency something happens.  If the camera starts blinking get out of the way.  Here's one possible scenario.  Please note that the following was performed in  compliance with all local laws and you should not try this at home.
>>  ¶¶
>>  Tragic. 
(Laughter).
>>  That's a wrap.  You probably heard the beginning of things is blowing up.  Again I'm Patrick and this my co‑ worker Colby.  Feel free to contact us.  Probably won't plug in any devices you send us.  Yeah, are there any questions now?  We have a few extra minutes.  Yes, in the front.
>>  (Inaudible).
>>  So the question was while we're hooking the video and audio up did we see any degradation in the performance of the device.  Since we were hooking pretty well level, we pretty much them copying them off and putting that in a shared buffer where code would take it off and do there.  In our testing we didn't see any specific degradation or anything.  Sometimes the video stream goes in and out anyway, so, it's independent of us.  Any other questions?  Awesome.  Thanks again.  Remember, don't trust cameras from strangers.
(Laughter).