Все по-често се сблъскваме с "умни" и не толкова "умни" решения за нашето ежедневие - от тостери и бойлери до сградна автоматизация (тук бих обърнал особено внимание на "very smart" щорите в стария ни офис, които се вдигаха почти всеки път когато слънцето започне да пече точно в лицето ти). Представете си следната ситуация - след тежък работен ден се прибирате към дома. Информацията за вашата позиция и дестинация се обработва в облачна платформа и от там се изпращат данни към "умния" ви дом, който непосредствено преди да се върнете пуска осветлението с подбрана цветова температура, звучи ваша любима мелодия, разбира се, съобразена с настроението ви, климатикът е създал оптималната за вас температура, а хладилникът ви показва кои продукти ще се изчерпят скоро. Звучи примамливо, нали? Въпреки че разполагаме с необходимите технологии, подобни решения все още не са масови, но концепцията буди интерес и кара много инженери и любители да опитват да създадат подобни домове използвайки достъпни IoT модули и софтуерни продукти с отворен код.

Преди месец попаднах на интересно видео в YouTube, озаглавено "Don't let the cuteness fool you - Exploiting IoT's MQTT protocol + DEMO", което разглеждаше някои от проблемите, свързани с протокола MQTT. Неведнъж сме коментирали, че именно IoT технологиите ще се явят много проблемни от гледна точка на киберсигурността и този факт ме накара да направя няколко кратки и бързи теста, но преди да ги опиша, нека да дефинираме най-важните характеристики на MQTT.

Протоколът MQTT и Mosquitto

MQ Telemetry Transport или накратко MQTT е специализиран протокол за пренос на данни между системи (Machine to Machine), често използван при IoT решения. Базиран на идеята за максимално олекотена комуникация (важно за IoT) и малките системни изисквания, MQTT бързо се приема от разработчиците.

Основната структура на MQTT включва:

1, Клиент

2. Брокер;

3. Механизъм за публикуване и вклюване към теми.

В своята основа MQTT е протокол, базиран на обмяна на съобщения, а използваният модел е от тип "publish and subscribe". Тук е важно да се отбележи, че няма директна връзка между системата, изпращаща данни към брокера и тази, която ги изисква и след това обработва. За целта се използва междинно устройство, наречено брокер.

Няколко други важни характеристики на протокола са:

  1. От гледна точка на MQTT, клиентите не използват адреси;
  2. Съобщенията се публикуват към брокера в дадена тема (Topic);
  3. Една от най-важните задачи на брокера е да филтрира съобщенията от дадена тема и да ги препрати към заявилите ги клиенти (Subscribers);
  4. Клиент може да получи съобщенията, след като ги заяви от конкретен брокер и точно определена тема;
  5. Всеки клиент може да публикува информация и всеки клиент да я заяви;
  6. В общият случай брокерът не съхранява съобщенията.

За повече информация бих ви препоръчал да прегледате краткия, но много добре структуриран "Beginners Guide To The MQTT Protocol".

Eclipse Mozquito или само Mosquitto е MQTT брокер с отворен код, който е много популярен поради неговата надеждност, лекота при инсталиране и конфигуриране и не на последно място факта, че е безплатен.

Пеглеждайки броят CVE за Mosquitto останах приятно изненандан - открих само 5 и то с най-висок приоритет "medium". Разбира се, това не означава, че няма да има "zero day" проблеми или неоткрити уязвимости.

Един прост python скрипт за заявяване на достъп до MQTT брокер и всички теми е (б.а. извинявам се за изображението, но все още се боря с възможността блог платформата да осигури качествено маркиране на код):

MQTT системи у нас

Беше ми интересно доколко MQTT е популярен у нас и доколко е защитен. Отново използвах Shodan и в търсенето зададох най-тривиалния стринг "mqtt country:bg". Бяха открити 126 публични адреса.

Числото 126 може да звучи сравнително малко, но справка за MQTT системите в цял свят, индексирани от Shodan, показва 65887  резултата.

Нека да се върнем към ситуацията у нас. Започнах да преглеждам адресите и попаднах на няколко, които определено приковаха моето внимание - не поради факта, че използват публични IPv4 адреси, а от гледна точка на MQTT темите и тяхното съдържание.

Използвах безплатния клиент MQTTfx и се свързах към една от интересните системи. Заявих всички теми (използвайки #) и започнах да получавам информация от множество сензори.

Тук определено ме впечатлиха данните за:

  1. "Покълване.темп.1";
  2. "Хладилник.влажност.1";
  3. "Стая.1.влага.6 - 50 - 57";
  4. "П.1.градина.темп.5" и др.

Предполагам, че ползвателят на системата отглежда орхидеи, които наистина са изключително капризни растения (на следващата снимка е показана IoT система за наблюдение на условията при орхидея).

"IoT - Monitoring Plant Health"

Продължих да разглеждам получените данни от темата domoticz/out.

От тук си направих два извода, първо, че са използвани сензори LaCrosse TX3 и второ - инсталирана и конфигуриана е системата Domoticz.

Проверих отворените портове на публичния IPv4 адрес и открих следните - 22, 443, 1883 (MQTT) и 8080. На порт 443 работи Web интерфейса на Domoticz.

Изкушаващо беше да опитам да се логна със стандартните за системата потребител и парола, но това не е етично и прецених, че няма да предприемам това действие. Дори да не са използвани парамтерите по подразбиране, подобен отдалечен и публичен достъп е предпоставка за атака на пароли, базирана на редица методи и инструменти, например hydra, nmap, sqlmap, dirbuster, owasp и много други.

Нека се върнем на модела на MQTT. Освен заявяването на определена тема е възможно да се изпратят и съобщения към брокера. По подобен начин във видеото от началото на статията, авторът на изследването успешно изпрати съобщение за OTA обновяване на фърмуера на система и чрез зададения адрес изпрати и инсталира модифицирана версия. Това е предпоставка за успешно интегриране на задни врати (Back Doors) или дори за създаване на бот мрежа.

Вижда се, че системите могат да бъдат атакувани по две направления (attack vectors):

  1. През MQTT/Mosquitto;
  2. През Web интерфейса на Domoticz.

Само за изчерпателност проверих и версията на Mosquitto, която се оказа 1.4.14, при актуална 1.5.4.

Бърза справка в CVE Details показва, че CVE-2017-7651 описва уязвимост в използваната версия на MQTT, позволяваща DoS атака, чрез изпращане на множество заявки за връзка с голям обем от пренасяни данни.

Колко е влажно в хладилника?

Да се замислим - защо е важно да знаем каква е влажността в хладилника? Може за мен и за вас това да не е от значение, но съм сигурен, че все някой има нужда от тази информация, при това чрез достъп до нея от интернет.

Разбира се подобни IoT системи ще стават все по-разпространени, но ако те не са защитени, броят на бот мрежите и включените в тях устройства ще расте.

Личното ми мнение е, че винаги при изграждане на IoT системи за домашни или корпоративни цели те трябва да бъдат защитени, при това с адекватни мерки. В разгледаният пример ясно се вижда, че изградената система използва множество датчици и предлага графичен интерфейс за управление и наблюдение, което ме кара да мисля, че нейният разработчик и/или ползвател има знания в областта, но не е запознат с рисковете при публичния достъп.

И ако направим аналогия с превода на "Mosquitto", то трябва да обявим "комарра" за защитен вид...

Източници

  1. http://www.steves-internet-guide.com/mqtt/
  2. https://www.shodan.io
  3. https://www.cvedetails.com/cve/CVE-2017-7651/
  4. https://mosquitto.org