NEW API: Enable Telnet!!

[ArcAIN6]

While i haven't been able to determine the username / password credentials as of yet, this is interesting: You can enable a telnet server on the device, and connect to it: /adm/file.cgi?todo=inject_telnetd

No joy on actually logging into it yet, i've tried the default user/pass combo's and quite a few untraditional one's...

If anyone manages to get in please post the user/pass, or walkthrough if you had to alter data to get in.

[edent]

Cool! Could you please let us know what cameras you've tried it on?

[ArcAIN6]

I only have access at the moment to an iControl iCamera-1000, most of the api listed here are useful with this camera, i found this page while googling around for the default pass (just in case :D) and somewhere along the lines, i dumped the sercomm name out of the camera (can't seem to find it in my notes at the moment)

There are some funcional differences between camera's you've listed, and this camera, namely, this camera doesn't have pan/tilt, nor does it appear to have samba, other than that, it's appearing that there is quite a few firmware similarities, and shared API commands.

As soon as i get around to it, i think i'll do a binwalk on the dumped fw.bin, and see if there's anything else...

Also, i'm looking into a possible exploit of the FTP server, whereas the password field can be used to execute commands on the camera (the goal at this point is to pen-test it and find a leak, or exploit where i can gain the telnet credentials)

As far as i can tell ,there's a pretty backdoor on these firmwares, i have tested other similar cameras, and found that if you can get telnet going the default user/pass seems to be root:123456

On this particular camera however, this isn't the case, so i'll have to find a way of coaxing the passwd file out of it, and check the hashed pass against johntheripper.

[ArcAIN6]

just ran binwalk on the dumped firmware, looks like they are stripping the passwords from the passwd file :( Booo... but now i've got a decent idea about the folder / file structure, i'll keep posting updates until i get in, or you guys tell me to shut up, or i reach an impassable dead end.

:p

[ArcAIN6]

Well.. I'm note sure what i borked, but i did.. The first run of binwalker extracted the etc, var, and tmp directories intact, one of which had a backup of passwd, however, my vm crashed, and it was all lost, subsequent attempts to unpacking the squashfs, and bin have not been good, the var, tmp, and etc folders now unpack with symlinks to /mnt/ramdisk/* wich leaves them dead ends..

The bin consists of a combination of gzip, and lzma compressed files, easily dumped with binwalker, but unless i can get my hands on a full clean firmware, and can find a way of mounting, rather than dumping the squashfs, i don't think i can go too much further with this...

Since the firmware can be dumped, it may be possible to edit, or add some scripts to it, repack it, and upload it back to the device to gain root access that way, who knows, i only have one of these, so i'm not too eager to brick it just yet :D

I tried to throw firmware-mod-kit at it, just to see if anything would stick to the wall, no joy, it spit errors, and warnings at me, and i'm a little too tired to trudge through the source to narrow down the issue.

[ArcAIN6]

If anyone wants to tinker around, i found somewhere that had a list of firmware updates for the icamera-1000, here are the first, and last of that list (because no one like middleware :p)

I may open the device later and see if there's a jtag or a known IC i can pin into to dump the full contents of the device..

ComcrapFirmware.zip

[edent]

People have left links to firmware on my blog post about these cameras - https://shkspr.mobi/blog/2013/11/hacking-around-with-network-cameras/

You may find some to be useful.

[ArcAIN6]

Thanks, i've looked over that once before at a cursory glance, seems everyone is pretty much at the same stage i am, trying to repackage the dumped firmware to enable, or extend the feature set of the device..

I've also run into an issue, where linux distro i'm using has squashfs 4.0, which annoyingly enough, doesn't deal well with older versions (namely, it simply won't mount the squashfs)

My hopes is to find the firmware source somewhere, or perhaps, if i can tinker it out, do a complete dump of the device, ramdisk and all, and try to pick it apart that way...

Still have my hopes up that i can wade through all the comcast / adt nonsense, and "user" manuals using google-fu and find something useful.

If all else fails, i may try to slip stream a shell of my own into the firmware dump somehow, just have to figure out what mechanisms are used to protect the bin (crc checksums, naming etc etc.. )

[ArcAIN6]

Yea, after looking closer, there's really no way for me to reverse this firmware at the moment.. If i get some free time later this month, i'll build a bus pirate and go in and dump the chips, and have a look..

From what i'm seeing, Sercomm like every other mass-producer, is using "tinkered with" or non standard squashfs settings, but on top of that, there are several version checks to keep someone from simply opening the bin, editing the squash, and repackaging everything..

I would be really interesting to see the source stack, and procedures they use to build these firmwares and updates... In all honesty, it probably isn't that difficult to build the updates if you have the source, because Comcast is able to, and from my experience with their hacked up one off firmwares, this is a step or 300 above their usual standard of quality, and security.

shrugs

at this point, i don't really need to keep going, but interest has been piqued, and i'm really quite interested in why there's a telnet backdoor, and what other nefarious odds and ends are packed into this little device.

[ArcAIN6]

Because i can't leave well enough alone, i pulled the sucker apart, good thing too, there's an unpopulated jtag header on the bottom PCB. I'm a little too drunk to dink with it tonight, but looking over the passives, it appears it can handle 3.3v - 5v on that header (DON'T QUOTE ME ON THAT!!)

Maybe tomarrow, if i'm not in too bad shape, i'll take a stab at it.. that JTAG header means i can more than likely bypass the root login credentials, and have unfettered access to the device, if so, maybe i can dump the entire system to an external device over the network, if there's not enough on-system space to create a proper dump, i may have to tinker around, and see what tools are available... busybox and all that, no clue what tools are available. secretly hopes for rsync

[ArcAIN6]

oh.. just a heads up... it appears there are backdoors on older sercomm firmware for some of their devices, so if you have a really old one, with factory firmware on it, you might want to look into it.

[ArcAIN6]

Well.. Looks like that 4 pin header is [5v] [TX] [RX] [GND] Serial coms connected at 115200 baud.

and dammit.. it's password protected...

Bootup infor tho :D

`DM36x initialization passed! TI UBL Version: 1.51 Booting Catalog Boot Loader BootMode = SPI DONE Dump mem - 0x81080000: 0xEA000012. 0xE59FF014. 0xE59FF014. 0xE59FF014.

Jumping to entry point at 0x81080000.

U-Boot 1.3.4-svn4286 (Jun 7 2013 - 11:06:42) DM365

DRAM: 128 MB SF: Got idcode c2 20 18 SF: Detected MX25L12845E with sector size 4096, total 16777216 bytes *** Warning - bad CRC, using default environment

In: serial Out: serial Err: serial ARM Clock :- 297MHz DDR Clock :- 270MHz Ethernet PHY: GENERIC @ 0x01 SF: Got idcode c2 20 18 SF: Detected MX25L12845E with sector size 4096, total 16777216 bytes

========================================== Neutral Bootloader V3.08

address = 0x0006FFFA MAC address 94:4A:0C:0C:18:B2 Calculate checksum chksum=0xCFC88185, chksum_in_flash=0x30377E7B, 0x0 Done: 0x0.

Booting kernel from Legacy Image at 80700000 ...

Image Name: Linux-2.6.18_SC-DM365 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1304788 Bytes = 1.2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK

Starting kernel ...

Uncompressing Linux....................................................................................... done, booting the kernel. Linux version 2.6.18_SC-DM365 (selina@ISBU-Compiler-B1) (gcc version 4.2.3) #1 Tue Dec 6 17:26:07 CST 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci DM365 IPNC Memory policy: ECC disabled, Data cache writeback DaVinci DM0365 variant 0x8 PLL0: fixedrate: 24000000, commonrate: 135000000, vpssrate: 270000000 PLL0: vencrate_sd: 27000000, ddrrate: 270000000 mmcsdrate: 135000000 PLL1: armrate: 297000000, voicerate: 20482758, vencrate_hd: 74250000 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists. Total pages: 14336 Kernel command line: console=ttyS0,115200n8 noinitrd rw root=31:5 rootfstype=squashfs mem=56M PID hash table entries: 256 (order: 8, 1024 bytes) Clock event device timer0_0 configured with caps set: 07 Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 56MB = 56MB total Memory: 53888KB available (2097K code, 527K data, 172K init) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 DaVinci: 104 gpio irqs MUX: initialized GPIO20 MUX: initialized I2C_SCL Generic PHY: Registered new driver ch0 default output "COMPOSITE", mode "NTSC" VPBE Encoder Initialized SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 2048 bind 1024) TCP reno registered VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) squashfs: version 3.1 (2006/08/19) Phillip Lougher Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) LTT : ltt-facilities init LTT : ltt-facility-core init in kernel DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfbc20000 (irq = 40) is a 16550A RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize PPP generic driver version 2.4.2 PPP Deflate Compression module registered NET: Registered protocol family 24 netconsole: not configured, aborting Linux video capture interface: v2.00 Trying to register davinci display video device. layer=c0476000,layer->video_dev=c0476160 Trying to register davinci display video device. layer=c03cfe00,layer->video_dev=c03cff60 davinci_init:DaVinci V4L2 Display Driver V1.0 loaded i2c /dev entries driver SPI FLASH: 94:4A:0C:0C:18:B2 block erase size=0x10000 SPI FLASH: kernel offset=0x128000, kernel size=0x140000, fs offset=0x268000, fs offset=0x970000 Creating 7 MTD partitions on "Macronix": 0x00000000-0x01000000 : "ALL" 0x00068000-0x00070000 : "MAC" 0x00070000-0x00090000 : "CONF" 0x000e0000-0x00128000 : "RESERV" 0x00128000-0x01000000 : "NORMAL" 0x00268000-0x00bd8000 : "FS" 0x00090000-0x000e0000 : "DEBUG" dm_spi.0: davinci SPI Controller driver at 0xc4002000 (irq = 42) use_dma=0 musb_hdrc: version 6.0, cppi-dma, host, debug=0 musb_hdrc musb_hdrc: No DMA interrupt line musb_hdrc: USB Host mode controller at c4004000 using DMA, IRQ 12 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected rtc_davinci_dm365 rtc_davinci_dm365.0: rtc intf: proc rtc_davinci_dm365 rtc_davinci_dm365.0: rtc intf: dev (254:0) rtc_davinci_dm365 rtc_davinci_dm365.0: rtc core: registered rtc_davinci_dm365 as rtc0 Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC). davinci_interrupt 354: VBUS error workaround (delay coming) ASoC version 0.13.1 CQ0093 Voice Codec 0.1 asoc: cq93vc <-> davinci-vcif mapping ok ALSA device list:

0: On-chip voice codec (cq93vc)

IPv4 over IPv4 tunneling driver ip_tables: (C) 2000-2006 Netfilter Core Team TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Time: timer0_1 clocksource has been installed. Clock event device timer0_0 configured with caps set: 08 Switched to high resolution mode on CPU 0 rtc_davinci_dm365 rtc_davinci_dm365.0: setting the system clock to 2000-09-14 01:01:01 (968893261) VFS: Mounted root (squashfs filesystem) readonly. Freeing init memory: 172K Warning: unable to open an initial console. init started: BusyBox v1.16.0 (2011-12-06 17:09:33 CST) starting pid 229, tty '': '/etc/init.d/rcS' Starting the boot scripts... insmod: can't insert '/lib/modules/io_expander.ko': No such file or directory MUX: initialized PWM1 Pin PWM2_G87 already used for GPIO87. reset init reset_init(241) rtc-s35390a 0-0030: rtc intf: dev (254:1) rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc1 insmod: can't insert '/lib/modules/echo_cancel.ko': No such file or directory /etc/init.d/rcS: line 183: /usr/local/bin/gpio_listen: not found /sbin/ifconfig lo rtusb init ---> rtusb init out--> rtusb exit ---> <--- rtusb exit cp: can't stat '/usr/local/bin/CAcerts.pem': No such file or directory /etc/init.d/rcS: line 205: /usr/local/bin/io_init: not found CSL: Module install successful, device major num = 253 CSL: Module version 0.10.00, built on Dec 6 2011 17:32:22 I2C: Module install successful, device major num = 252 DMA: Module install successful, device major num = 251 DRV: Module install successful DRV: Module built on Dec 6 2011 17:32:29 DRV: EDMACC.QUEPRI = 00000777 DRV: SYSTEM.MSTPRI0 = 00440022 DRV: SYSTEM.MSTPRI1 = 00000244 DRV: ISP.BCR = 00000002 DRV: SYSTEM.MISC = 00000399 CMEMK module: built on Dec 6 2011 at 17:30:44 Reference Linux version 2.6.18 File /home/selina/icontrol_icamera_english_all_105_1002R08/source/src/kmods/uopen/cmem/cmemk.c allocated heap buffer 0xc5000000 of size 0x4800000 CMEM Range Overlaps Kernel Physical - allowing overlap CMEM phys_start (0x1000) overlaps kernel (0x80000000 -> 0x83800000) cmemk initialized EDMAK module: built on Dec 6 2011 at 17:30:46 Reference Linux version 2.6.18 File /home/selina/icontrol_icamera_english_all_105_1002R08/source/src/kmods/uopen/edma/edmak.c IRQK module: built on Dec 6 2011 at 17:30:47 Reference Linux version 2.6.18 File /home/selina/icontrol_icamera_english_all_105_1002R08/source/src/kmods/uopen/irq/irqk.c irqk initialized /etc/init.d/rcS: line 210: /usr/local/bin/listen_input: not found daemon init ok! killall: sensor_daemon: no process killed DavinciDisplay DavinciDisplay.1: Before finishing with S_FMT: layer.pix_fmt.bytesperline = 736, layer.pix_fmt.width = 720, layer.pix_fmt.height = 480, layer.pix_fmt.sizeimage =529920 DavinciDisplay DavinciDisplay.1: pixfmt->width = 720, layer->layer_info.config.line_length= 736 Davinci EMAC MII Bus: probed TI DaVinci EMAC Linux version updated 4.0 nt_services/460[CPU#0]: BUG in local_bh_enable at kernel/softirq.c:196 rtusb init ---> rtusb init out--> rtusb exit ---> <--- rtusb exit Ethernet link is ready now mDNSResponder: _http._tcp. service renamed from "iCamera-0c18b2" to "iCamera-0c18b2 (2)" /etc/init.d/rcS: line 227: /usr/local/bin/nc_qset: not found /etc/init.d/rcS: line 234: /usr/local/bin/jabberlog: not found

SinfulCNC login: rtusb init ---> rtusb init out--> Davinci EMAC MII Bus: probed TI DaVinci EMAC Linux version updated 4.0 rtusb exit ---> <--- rtusb exit rtusb init ---> rtusb init out--> : Starting lighttpd mDNSResponder: _http._tcp. service renamed from "iCamera-0c18b2" to "iCamera-0c18b2 (2)"`

I'll keep cludging away at this over the next week or so while i have free time.. i also odered a buspirate (too lazy to build one) so i should be able to just dump the chip to gain access to the contents of ramdisk.

[ArcAIN6]

Unfortunately, i simply won't have any time for the forseeable future to keep at this. New job mandates i never eat or sleep... friggin heathens!

Anywho...

As i see it, there's several possibilities here, both force us to unpack and repack the bin and include the following precursory steps: Download the FW.bin, use DD to pull out the squashfs part, decompress it,

Once done, you have several methods of attack: 1) edit the RC script to copy /etc/passwd file to a location you can grab it from. 2) edit the RC script to change the root password (might be derpy.. duno) 3) use RC script to change permissions of executables, as well as add shell script frontend web page(s) 4) precompile rsync for the busybox version on the hardware, and add it, then edit rc file to rsync entire live system over to an external device / drive...

all of these attack vectors present a couple of major obstacles, and forces us to ask a few tough questions: 1) Does the protected portion of the OS prevent any of the measures from working? If so, how do we circumvent it? 2) The FW upload cgi checks the uploaded file, but what is it checking? Name? embedded version number? bin in etc? CRC? If so, we need to understand how this mechanism works, and what we can do to fool the system into accepting our modified FW bin. 3) What exact squashfs settings are being used? This may require quite a lot of trial an error extracting, and repacking the squashfs filesystem, without editing it, until you can get a filesize and CRC match.. once you've accomplished that, you'll know how to edit the squashfs and have it match the format used by the original dev's.

I think it's in everyone's best interest if we all continue to poke, prod, and probe these ubiquitous devices. They not only pose privacy concerns, but security concerns as well. Who knows what is being done with the backdoors present in these devices? It's especially repugnant that these devices usually come with secondary "middle-ware" devices that serve no other purpose other than further obfuscating the mechanisms working behind the scene. Case in point, the Xfinity, and ADT versions of these particular devices are often bundled with a "home security router" that is also locked out from the user, and performs several hidden functions, as well as contain several hidden back door access points.

The fact that people are using these devices in the privacy of their homes, and businesses should shock us all. They grant unfettered access into every moment of our lives to large corporations most of whom have a less that stellar history when it comes to privacy, and maintain a reputation of collecting, and utilizing private information for monetary gain.

[techleprechaun]

URL http://[IP]/adm/file.cgi?todo=inject_telnetd Telnet username: root Telnet password: Aq0+0009

[edent]

Sorry, I should have added this last year. https://shkspr.mobi/blog/2017/11/telnet-and-root-on-the-sercomm-icamera2/