Conceptronic XSS


I didn’t write this post to aid hackers, but to make sure all these cameras are taken offline as soon as possible. I don’t accept any responsibility for hacks committed with this information, nor do i endorse malicious use of this information. Remember that wrongly used this information, depending on where you are could be a federal offence that lands you some serious prison-time. Additionally, all the tests i did was on my own equipment, running a battery of different firmwares.


I bought a Conceptronic CNETCAM (Embedded linux web-based security camera) some years back. After a burglary in my place it gave me that extra feeling of security to be able to login and see that all was good at home if i ever was worried. It was cheap but lacked a lot in the web-design-department. I figured if i changed the firmware, it could look nicer and run a fullscreen picture instead of the sorry ass borders created by conceptronics. I downloaded the firmware and started to analyzing the binary file using strings and greping for html-tags. I could see html pore by my screen in clear-text, meaning no compression was used on the binary file that constituted the firmware. Great, this simplified the process a lot.

I started by changing the colours around, uploaded the firmware, rebooted the camera and it all worked fine, my colours were applied. “Awesome”, i thought.. This will allow me to mod the webpage without extracting and re-compiling a working firmware file as long as my HTML code could fit the same space as the old code used. I did a few more changes but this time uploading it gave a error message indicating that the firmware checksum was wrong.

While trying to find the checksum that must have caused the update error, i looked around the web for people that might have done this before i found almost nothing for this specific camera.

I decided i might get lucky with a google-dork and searched for part’s of the html-title, some distinct text on the page where the camera could be viewed and added parts of the url to the document in the query. Bingo! Around 75.000 hits. While looking through the results i fast realized that google removed part of my query, namely “Conceptronic” and 99% of the results had everything my dork demanded but the name of the vendor. Some cameras where D-link DCS-900, some SparkLAN CAS-330 and about 5 other vendors, all using the same basic html-code. But none of them had a tool embedded in their GPL-code which allowed me recompile a new firmware from scratch.

I figured maybe another vendor had the tool so I turned the process around. The camera i bought had a really distinct look. It was thin, wide and long, with a large screw around the lens to adjust focal length. I googled “Ip web camera”, choose “Images” and started looking around. I found another 5 vendors with very similar design while going through the hundreds of images in the search, and started mapping them out. As a test I downloaded  the Sparklan CAS-330 firmware, uploaded it to my camera, rebooted…. and it just worked. My camera just changed interface to the classical blue sparklan interface, but every function worked. I was surprised because i kind of expected to brick it.

This is where it all took a sharp turn. While playing around with my own camera, flashing it with loads of different firmwares from a heap of other cameras with same appearance, specs and functions i accidentally broke a script i wrote and managed to flash the device with an error. I actually flashed it over and over and just saw a error flashing by the CLI that didn’t seem to matter as the camera rebooted and came back again with the changes i made in place. I started debugging the script, found my typo and realized with this bug in place, there was NO WAY it should would have managed to authenticate to the camera, it just firmware flashed without caring who i was.

I wrote a simple html document


and loaded it in my webbrowser, and clicked Save. The camera died for a few seconds then prompted me to login again. I entered the same username and password as i just saved. It worked!

I could not believe my eyes. Looking at all possible html documents in the webroot, i realized most of the documents on the embedded webserver was susceptible the same XSS-attack. I could not view many of the html-pages without being authenticated, but i could do a POST-GET and apply new values as long as all input-strings needed were there. I could change the password, flip the image upside down, set the capture resolution and all other functions in the camera.

I started compiling a list of my finds, mostly cameras that looked alike it, had similar paths in the webUI and the size of the firmware. Flashing my own camera over and over with all these different cameras firmware i confirmed that this bug could be found in most of the cameras i suspected had the same initial manufacturer. I turned my eyes back to Conceptronic again. Turns out that Cellvision (a Chinese OEM-vendor, now owned by Sparklan ) made the original code and OEM-sold it to Conceptronic but that tons of other companies also did the same. All of them just branded them with their own logos, without changing anything but the webUI.

I figured i could not be the first to have made this find and it turns out some people had found a XSS exploit on a single make or model, but no-one seem to have understood they were actually all the same camera. I was amazed.

Did i just find a way to get root on 75.000 cameras?

It seems i had. I started realizing how bad this was. 75.000 people had trusted these devices to the extent that they port-forwarded them through their DSL-modem or corporate firewalls, right into the inside of their networks. As this hack actually allowed me to upload a new firmware that seemed to work cross all these cameras, i could have written a firmware that allowed me to nmap their whole infrastructure and display this information to me on the outside. Once i had this information another firmware could route the webserver to an hardcoded internal IP and port, actually granting me access to ANY of their internal services, just like i was in their network. Needless to say this could all be scripted and automated, making the collection of information and routing more or less instantaneous.

At the point of this discovery most of the cameras were at or near their end of life by the vendor, but still actively used by people and companies so i decided to sit on the information rather than sharing it with the world. Today all of the cameras are EOL’ed, but quite a few are still out there. As i don’t want to help people abusing this, i will not share the complete list of models and makes but rather say:

If you have a camera that looks something like this


i strongly suggest you write a html-document like the one above, change the hostname to it’s IP (and :port if you don’t run it on port 80) and see if it is vulnerable. I would also like to point out that none of the firmware updates available to any of the different camera firmwares i was playing with actually solved this specific issues, and as of today i doubt anyone will.

Hope someone finds this information useful.

Adding abilities to Sony HDR-AS30V

I recently purchased a new camera for my motorbike. What made the Sony HDR-AS30V stick out, beside all the regular stuff such as full HD on 60 fps, remote control via Android and IOS-devices was that it has a GPS device that stores all data and allows you to overlay this information on the final rendered video. I tried doing this collecting data from a GPS device with decent results, but figured a all in one solution was a better deal in the end.

I added a 32 gb micro-SD to be able to record hours of driving but soon noticed some very annoying limitations with the camera. The first one being the internal microphone which picked up more wind than motor noise. The camera has an external microphone-jack, but with the water-proof casing on (which by the way is the ONLY way to mount this camera anywhere), the microphone connector was hidden under the casing, and it’s locking mechanism.

The second thing that really annoyed me was that the camera could not be charged while recording, as the camera went in to a USB-mode which disables the recording feature. Not only was the connector hidden under the waterproof case, but even when out of the case the USB overrode all internal functionality. Using a USB test-block i built a while back for sniffing the USB-protocol, i disabled the two middle-pins (data+ and data-) hoping that this workaround would allow the camera to ether charge or run off external power, but the camera insisted USB was connected.

Solving the mic-issue:

I don’t really need a waterproof camera so getting a hole trough the case that could allow the external mic to be connected was not a great concern to me. Worst case scenario i could always bring a roll of duct-tape to cover the holes if i ever wanted to go diving with it. But as the locking mechanism was just above the jacket, i had to substitute this with some form of lock. Not to waste to much time on this, i removed the lock and replaced it with a rubber-band. To see the difference between a external vs. internal microphone i cut this clip together:

Sorting out the power issue:

As for the charging part i figured i would build a tiny lithium-ion charger that could fit somewhere in or on the camera. With a camera that measuring 6.5cm x 4cm x 2cm which is jam packed with electronics already i decided the circuitboard needed to be housed in a tiny space between the camera and the casing, on the front of the camera as this would be the only place it fitted. Using a dremel i removed enough of the plastic casing to make it fit. Only problem was, this was also where the external microphone cable was connected. Looking around the net i stumbled over the MCP73831T charger circuit. The smallest package i could find was the SOT23-5 measuring about 2mm x 1mm. Since it was just 3 euros i figured i get a few. Things this size tends to get lost never to be found again. After building a few prototypes the first one went toast in just a second, while the second one seemed to indicate that things were working. Measuring voltage however gave very weird results i still to this day can not explain so i started looking for another charging circuit. After a little googling around i found the MAX1555 also contained in a SOT23-5 encapsulation, however this demanded less surrounding components and became the semiconductor i decided to go with in the end.

I started learning the PCB (open source software for circuit-board manufacturing) but for some reason all circuits i made and all example circuits i opened was giving me an vague error about not all objects being defined. Since my use-case worked fine with the typical application-setup and i took the chicken-shit way out of this. Learning PCB still remains high on my to-do-list. Like most other things in this world, i was not the first to attempt something similar, and looking around further i found this drawing (credit to Hugo for his great work):


This little bugger might look tiny with a mini-usb covering 1/8th of the board, but fitting it into the Sony HDR-AS30V as was would be like trying to fit a loaf of bread through a key-hole. In lack of better PCB knowledge i loaded it up in Gimp and started removing stuff i didn’t need. I didn’t see any reason to include the USB-power LED, so this could go, and so could the resistor in front of it, all the screw-holes and unnecessary GND copper surrounding the board, resulting in this design:


If i would have printed this as is, it would never fit the camera either. It needed a 10mm hole in the middle so the microphone-jack was still reachable, and even my SMB-mounted 1uF capacitors measured 1/3 of the size of the USB connector, and on my tiny board i needed 3 of them. Saying i had a space issue was just the start of it, but i would not let this deter me. The caps had to be inserted into the board to fit. It does not look nice, but it works so don’t start hating on me now :) The tiny 330 Ohm smb-resistor to the left of the board was the next component to be added.


Next component to go on is the tiny MAX1555 SOT25-5. Measuring a tiny 1×2 mm, this component needed to have all 5 legs soldered, a task that took “some” fiddling around before getting it all in place. As this board only has copper on one side, all legs are actually soldered to tiny cables fed through and around the board to connect it with the backside of the board. At this point it was a few hours after midnight and i wanted to finish it up, so not many pictures are taken of the MAX1555, but you can see it pretty okay in this shot taken during the initial charge tests. The battery in was just soldered there for the load-tests, and yes.. This did happen around 03.40am. Sorry about the late night Dremeling, neighbours.


After making sure it all worked, and fitted the waterproof casing i used a 2 component epoxy to add the module to my Sony camera. I also switched the yellow LED to a green one, just for the look of it.


Late this morning i made a test-recording, and for the first time made an 1.5 hour recoding in Full-HD without consuming the battery, making this camera the first Sony HDR-AS30V that can record more than 1 hour. Beside mixing up a batch of polyester that i will submerge the whole circuit-board into to make sure it becomes as rugged as the rest of the camera, not much remains to be done to this projects.


This was a funny hack that only cost a few euro’s but added the features that i did not want to be without. The fact that Sony could have saved me these hours spent by incorporating this feature themselves kind of annoys me. Why Sony allowed the camera to be able to create way longer videos, when there was no way of recording over an hour i guess i will never know. Needless to say this was a good day with another warranty voided. :)