Journey over unsecured IoT devices with Kamerka — RTSP and MQTT.

Wojciech
Wojciech
Jul 20 · 6 min read

Introduction

In previous versions of Kamerka you could visualize cameras, social media photos, printers or Industrial Control Systems of any country. Now two more services have been added.

First of them is MQTT (Message Queue Telemetric Transport) which is widely used to manage IoT (Internet of Things) devices. You can spot it in different places: offices, universities or even power plants.

For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios

~ https://mqtt.org/

RTSP (Real-Time Streaming Protocol) as name explains, it gives real-time feed from IP camera, including sound. The main use case for RTSP is to be independent with possibility to implement it directly into your application. That means, if stream is not secured enough, someone can hijack it. Most of these devices are surveillance cameras and you can meet them near or inside buildings that require additional security.

Moreover, couple new features have been added. From now you can look each host up recursively and display theirs ports and hostnames directly on the map. More information about host can be gathered from newly added „Check ownership” link, which redirects to bgp.he.net and shows you details about owner of the netblock. This update also allows you to show only open assets and choose how many pages you want to retrieve.

https://unsplash.com/@danlefeb

Message Query Telemetric Transport

MQTT is very known from it’s lack of security, article from 2016 confirms that even at that time it was a problem. It is based on M2M (Machine to Machine) protocol and operates on port 1883.

Worth to highlight is that security of MQTT should be followed together with hardening other services running on the machine. The biggest and most common mistake is to leave other services running on the same machine completely unsecured. Almost every MQTT server, serves additional dashboard on different ports, depending of product manufacturer. Dashboards can give visual insight about actual devices behind MQTT, it might be lights in office, temperature sensors or sprinklers.

Example of dashboard for MQTT devices

In addition, some of the dashboards give you full access to every sensor, which means you can take control over whole building.

Nowadays, lot of MQTT run in the cloud and do not reveal their location so it’s hard to map it, however there are still some servers and infrastructure that might be visualized and potentially hijacked.

MQTT devices near Sacramento

Without proper security in place, everyone can connect to device and subscribe to every topic, that’s how MQTT works. List of accessible topics is listed after clicking on one of the open devices.

There are lot of free tools to manage Message Queue Telemetry Transport devices, one of the most known is mqtt-spy, Mosquito MQTT or my favorite MQTT.fx. When attacker start subscribing to specific topic he gets data in return. The information depends of the usage, it might be air humidity, phone locations or power command in Area51.

MQTT.fx interface

Real-Time Streaming Protocol

Another service that can be abused for spying on people and buildings is RTSP. It usually operates on port 554 (sometimes 8554) and supports VHS like commands: PLAY, TEARDOWN, RECORD, SETUP or PAUSE. Together with Real-Time Transport Protocol (RTP) and Real-Time Control Protocol (RTCP) they create team for media delivery.

Real Time Streaming Protocol cameras in Copenhagen

Attack vectors remain the same as for the rest of typical HTTP cameras, i.e. weak/default credentials or lack of authentication. To actually retrieve the stream, attacker needs to known or bruteforce path to the video, you can find full list here. There is already Nmap script for detection RTSP paths and more advanced tools like cameraradar. The simplest way to play the stream is with VLC player.

If you set up recursive mode, additional ports will be shown on the map. It’s really helpful to determine if there are more services running, most common it’s other IoT device with special dashboard. Quite often happens that MQTT and RTSP operate on this same host, which opens a lot of new possibility for spying.

Example RTSP stream

Easier management

There are a lot of results for any urbanized place in the world and it’s hard to keep the track of all type of exposed devices, their ports and potential vulnerabilities. Right now, ꓘamerka supports Elasticsearch output and with help of Kibana you can create awesome visualizations and dashboards. It includes ports, products, vulnerabilities, device types, ASN and much more. If you have to manage exposed devices on particular territory like cities or ICS devices in country, it’s perfect, elegant and the simplest way to do that.

Kibana visualizations

Case study — Power plant

I am aware that ꓘamerka can be abused by bad guys to find vulnerable device and extend their botnets or just by people violating others privacy. Keep in mind that it depends from you what you will do with the finding. During tests of new ꓘamerka features I came across something interesting which looked like power plant.

Power plant MQTT

“Check ownership” link gave me information about owner of the subnet but unfortunately, data was outdated and there was no additional contact. It’s another proof that keeping whois information up to date is very helpful in case of fast reporting and mitigating any type of vulnerabilities.

Exposed topics indicate that it is actually power plant with various type of sensors publicly accessible. With no luck with whois information, I reported issue to the CERT-US and was very surprised with their fast reaction. After couple days, I’ve got information about my submission and that they will contact responsible company. Two days later access has been restricted.

If you want to help in some way, it is easy as that.

https://github.com/woj-ciech/kamerka

Conclusion

Usually, most of IoT devices weren’t made with security in mind. Almost everyday you can spot headlines about vulnerabilities in surveillance cameras, cardiac devices, baby heart monitors or other “smart” devices. However, described cases it’s not even fault of producer but the culprit is user that leaves his device open or with default/weak credentials. As you might see, this problem lasts from the beginning of Internet of Things era and it seems that it won’t stop soon.

Wojciech

Written by

Wojciech

@the_wojciech

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade