Уязвимости в безопасности IP устройств различных брендов. Hikvision. Часть 1

SysBez, Вы сами то верите что покупки через инети ividion и ГХ безопасно?

Когда мне понадобится отправлять услуги веры, я пойду в храм. А покупки я практически делаю посредством облачных технологий. Уже давно. Еще не разу ни у меня ни у моих знакомых денег не было украдено.

На момент написания этого поста, не работает.

и если задуматься, по сути совокупности даже озвученных всего лишь трёх уязвимостях, то даже штатное устранение их производителем повлечёт очень большие изменения!!!

ШЗ-камера в отдельности (т.е. без клиентской стороны) - не нужна ни одному пользователю.

Видео, это всегда система: - передатчик-приемник (в случае стандартных CCTV систем) и сервер-клиент (в случае ШЗ-систем).

А по этому, решение производителем (НО единолично) хотя бы одной из перечисленных уязвимостей - повлечет не просто сильные изменения, а подобные изменения - просто убьют рынок IP-камер данного бренда потому как:

- в этом случае они не будут пригодны (не будут совместимы ) для работы со сторонним клиентским ПО и/или сторониними DVR (NVR).

Так что не стоит ожидать что тот или иной производитель пойдет хоть на какое-либо телодвижения в сторону устранения этих или других уязвимостей. В их интересах как раз упорно замалчивать подобные вещи.

Ну а если даже какой либо из производителей и сделает что-либо по защищенности передачи - то сделать он это сможет - только для персональной связки для единого бренда (ШЗ-камера + WEB-клиент), или + ПО от производителя, ну или + DVR(NVR) именно от этого бренда и только именнос ВК этого же самого бренда.

Но даже сделав всё это, производитель всё равно должен будет оставить в своём оборудовании некую совместимость - а-ля общеизвестный ONVIF посредствам RTSP - со всеми известными и пока еще неизвестными дырами-уязвимостями.

И подобное сохранение всех уязвимостей - производителю будет просто необходимо для того чтобы некие "Сус-о-Без-ы" могли поскоренькому (живинько так- на скорую руку) подключить камеру от этого бренда - к облаку - но от другого, стороннего бренда.

Только в этом случае объемы производимых ШЗ-камер останутся на достигнутом уровне продаж и способствовать этому будет - исключительно техническая безграмотность и слепое уверовавание в защищенность коммутируемых ШЗ-каналов огромнейшей армии пользователей, да еще и жаждущих некой безопасности, правда жаждущих её исполнения - за три копейки.

Ни одну из камер, предлагаемых в их "маазине" я бы не купил. Поскольку их фукционал меня, как пользователя, не устраивает, да и цены не маленькие.

;-)

Может конечно слегка сгущаем тут краски и производителю достаточно выпустстить свежие библиотеки SDK, исправив ряд уязвимостей, а также выпустив в связи с измененим в SDK всё прошивки, а всё остальное предыдущий версий и релизов объявить проблемами пользователя, если они сами не сделают необходимые обновления, в мягкой форме конечно же ;) ;) ;)

Вроде как и проблема решена на тогда низком уровне у некоторых уязвимостей, что концептуально верхний уровень использования не затрагивает у всех остальных приложений в связи с новыми библиотеками SDK и делать надо не так много и поднимать вокруг этого много шуму и пыли. Тихонько, так сделают свежие релизы, да и вообще скажут, что про всё и сами знают и в планах было у самих это сделать и незачем тут открывать Америку и колесо изобретать ;) ;) ;)

Однако не так всё просто, как уже написано мной да и отметил Вадим!

Читаю я, читаю, и всё более удивляюсь. Об чём вообще разговор? 1) Об уязвимостях, 2) о потенциальных проблемах, с ними связанных, 3) о средствах закрытия показаных дырок или 4) о страхах слабо ориентирующихся в сетевых вопросах потенциальных клиентов? Странный какой-то разговор, такой, знаете ли, чудесатенький, когда все мелют своё и никто не слушает собеседников.

Об уязвимостях всё сказано в оригинальной статье. О потенциальных проблемах - ну, в принципе, там же. Средства закрытия дыр знает любой сисадмин. А со страхами - в другое учреждение, здесь не белые халаты в чести.

Однако не так всё просто, как уже написано мной да и отметил Вадим!

Да ну, херь, и Вадим какую-то чушь написал на этот раз. Всё не просто, а очень просто. Позволю напомнить участникам сей дискуссии, что стек TCP/IP используется широчайшим образом отнюдь не только в видеонаблюдении. И никаких особых проблем совместимости контента и клиентского ПО как-то не возникает при любом априорно данном уровне защиты соединений.

Вот, например, пассаж Вадима об уязвимости № раз:

Чёй-та не будут? Типа, стороннее ПО SSL не поддерживает, штоле? Дык фтопку такое ПО, мало ли его хорошего, чтоб ишо гафно всякое юзать? Или поддержку HTPPS слабо внедрить в DVR? Аффигеть какая сложность! Правда, и нужна она там, аки у телеги зеркало заднего вида.

Ну а если даже какой либо из производителей и сделает что-либо по защищенности передачи - то сделать он это сможет - только для персональной связки для единого бренда (ШЗ-камера + WEB-клиент), или + ПО от производителя, ну или + DVR(NVR) именно от этого бренда и только именнос ВК этого же самого бренда.

Приколись, а как же это клиент-банковские системы прекрасно себя чувствуют на всех популярных браузерах, да притом ещё и на разных OS-платформах? Наверное, их разработчики Тюрина не читывали... с-поутру.

Не говоря уж о том, что всяким там DVR'ам и NVR'ам вовсе не нужен доступ к настройкам видеокамеры. А видеопоток в шифровании не сильно нуждается, его и в анонимном виде передавать не трабла; а можно и в неанонимном, кому он нах упал?

Уязвимость №2 вообще представляется мелкой халтуркой производителя: "крепкое" хэширование прекрасно можно наблюдать во всех версиях Винды после Винтукея, да и в нём никто не мешал прибить Ланманагер и наслаждаться безуспешными потугами терпил вскрыть пароль перебором. Подразумевается, что и юзер должен быть не совсем уже лох, но это вторично :-))).

А уж про №3 и говорить как-то смешно: эти "фишки" любой админ прибивает сразу для и у всех юзерей. В исходной статье:

Для тех, кто хоть раз открывал telnet/ssh cессию на IP камеру Hikvision по делу

Ну и кто, кроме автора, открывал? Реально: не могу представить, зачем бы в 21-м веке понадобился telnet. Ну, правда, кто из присутствующих юзает telnet хоть в локалке, что ли? Накидайте примеров?

Что производители IP-приложений сохраняют совместимость по этому старью, понять, в принципе, можно - мало ли конченых шизиков среди фриков? Но расчитывать на шизофричество в физзащите - увольте. Или сразу ехайте в дурдом - о каких применениях-то разговор? Где мы вообще?

Да и допущения какие-то странноватые в оригинале, например:

пресечь данную ситуацию из локальной сети будет нельзя.

Из какой локальной сети, клиентской или той, в которой камера? Насчёт клиентской - раньше надо было закрывать дырки, а где камера - только если эта сетка полностью открыта вовне, но лично я не встречал локальных сетей, по крайней мере, российских, не ограждённых рутерами. Рано как и не знаю ни одного рутера, в котором telnet был бы разрешён по умолчанию.

Посему вся эта шняга относительно гипотетических последствий и несовместимостей представляется тем, чем и является - трепотнёй без выраженного предмета дискуссии.

Troll!

Благодарствую за отзыв и Ваше мнение!

Об уязвимостях всё сказано в оригинальной статье. О потенциальных проблемах - ну, в принципе, там же. Средства закрытия дыр знает любой сисадмин. А со страхами - в другое учреждение, здесь не белые халаты в чести.

;)

Да ну, херь, и Вадим какую-то чушь написал на этот раз. Всё не просто, а очень просто. Позволю напомнить участникам сей дискуссии, что стек TCP/IP используется широчайшим образом отнюдь не только в видеонаблюдении. И никаких особых проблем совместимости контента и клиентского ПО как-то не возникает при любом априорно данном уровне защиты соединений.

Вот тут, про стек, Вы явно не подумав вкрутили т.к. не в нём и дело! Речь шла только про открытые и слабо незащизенные данные внутри пакетов на сегодняшний день. И не более ;)

Конечно, Вадим сам прокомментирует, если сочтёт нужным, однако...

Чёй-та не будут? Типа, стороннее ПО SSL не поддерживает, штоле? Дык фтопку такое ПО, мало ли его хорошего, чтоб ишо гафно всякое юзать? Или поддержку HTPPS слабо внедрить в DVR? Аффигеть какая сложность! Правда, и нужна она там, аки у телеги зеркало заднего вида.

По-видимому, Вы не в курсе про какое ПО идёт речь, поэтому так и швыряете в топку и с лёгкостью решаете обозначенные проблемы. ;)

Тут Вы тоже, как и некоторые другие участники, опять ушли в сторону от сути. Ну не писал я про SSL и HTTPS в данной статье и не рассматривал пока, применительно ни к данному бренду ни какому-то другому. Когда дойдёт именно для рассмотрерия именно данного вопроса, я тогда не знаю как Вы будете выкручиваться, но думаю выкрутитесь сказав, что это надо в топку, а клиент-банки у других работаю стабильно!!! ;)

Уязвимость №2 вообще представляется мелкой халтуркой производителя: "крепкое" хэширование прекрасно можно наблюдать во всех версиях Винды после Винтукея, да и в нём никто не мешал прибить Ланманагер и наслаждаться безуспешными потугами терпил вскрыть пароль перебором. Подразумевается, что и юзер должен быть не совсем уже лох, но это вторично :-))).

Про халтурный подход - согласан тут с Вами ;)

А уж про №3 и говорить как-то смешно: эти "фишки" любой админ прибивает сразу для и у всех юзерей. В исходной статье:

Ну и кто, кроме автора, открывал? Реально: не могу представить, зачем бы в 21-м веке понадобился telnet. Ну, правда, кто из присутствующих юзает telnet хоть в локалке, что ли? Накидайте примеров?

Про уязвимость №3 Вы ничего, к сожалению, не поняли, т.к. невнимательно прочитали саму статью. Еще раз повторю, т.к. уже разъяснял. Телнет доступ приведён лишь как пример чтобы указать на результаты тем кто там был, а тем кто не был просто указать, что есть такое, при наличии авторизации и есть те кто в курсе про телнет доступ. Суть уязвимости в том, что Вам не удастться это прибить ни на раз-два, ни на три-четыре.

Не нужно иметь доступа в телнет и тем более не нужно иметь авторизацию на устройстве. Можно и без этого и получить авторизацию, как по умолчанию при завоодских настройках, и даже без этого изменить любые настройки в оборудовании, а также вывести его из строя, опять же без всякой авторизации на устройстве.

Что производители IP-приложений сохраняют совместимость по этому старью, понять, в принципе, можно - мало ли конченых шизиков среди фриков? Но расчитывать на шизофричество в физзащите - увольте. Или сразу ехайте в дурдом - о каких применениях-то разговор? Где мы вообще?

Видимо вам как-то знакома или близка это тема, раз Вы неоднократно проводите параллели с ней ;)

Написали Вы много, а вот сути не уловили. Бывает и такое. Если Вам сложно понять, что такое локальная сеть, то упомянутые Вами ранее широкие возможности TCP/IP стека, мне кажется, что это не Ваши слова вообще. Рассматривайте эту ситуацию с точки зрения трояна у Вас на ПК и все те открывающиеся ему возможности и доступы.

Не имея прямого отношения к теме, всегда сложно что-то сказать, тем более, что-то по делу, а гораздо проще, назвать всё шнягой и трепотней.

Как Вы заметили в статье я и не собирался мусолить о последствиях или давать оценки и предложил это сделать каждому заинтересованному читателю самостоятельно.

Ваше личное мнение, тоже полезно, как и мнения других участников дискуссии, в которой Вы не видите смысла ;)

Трефилову

Евгений Юрьевич - а Вы то как давно стали заниматься ШЗ-видеонаблюдением? ;-))

А сколько Вы Евгений Юрьевич - за это время инсталлировали реально работающих ШЗ-видеосисем?

А вам известно что самая главная проблема именно в том - что Вы с легкой руки отправили в топку?

И проблема эта именно - в передаче/приеме непрерывного ПОТОКА видеоданных - это первое, ну в связи с этим - второе:

стек TCP/IP используется широчайшим образом отнюдь не только в видеонаблюдении.

- видеопоток имеет жесткие временные рамки на время передачи - и если Ваша IP-система не всостоянии передать объем информации обо всех кадрах считанных за секунду с матрицы камеры - то в следующую секунду данные об этих кадрах - уже нах никому не будут нужны, и именно по этому, - для передачи видеопотока необходим протокол RTP (Real-time Transport Protocol)

RTP был разработан как протокол реального времени, из конца в конец (end-to-end), для передачи потоковых данных. В протокол заложена возможность компенсации джиттера и детектированию нарушения последовательности пакетов данных — типичных событий при передаче через IP-сети.

Протокол TCP, хотя и стандартизирован для передачи RTP, как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки. Вместо этого, большинство реализаций RTP базируется на UDP.

ну и третье:

Или поддержку HTPPS слабо внедрить в ......

А Вы в курсе для чего существует - RTSP (Real Time Streaming Protocol)?

По синтаксису и операциям протокол RTSP похож на HTTP (HyperText Transfer Protocol — «протокол передачи гипертекста»). Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется специальный порт с номером 554.

А может Вам Евгений Юрьевич - известно нечто такое, что скажем всем инсталляторам и разработчикам потоковых способов передачи видеоданных в среде IP не ведомо? :-))

Может у Вас есть какая информация по некому ШИФРОВАНОМУ протоколу а-ля по аналогии с HTPPS (HyperText Transfer Protocol Secure) - о неком секретном RTSPS (Real Time Streaming Protocol Secure)?

Так что проблемы с авторизацией - на фоне проблем с невозможностью шифрования (а значит и дешифрирования) ШЗ-ПОТОКА видео и мета данных - в принципе только лишь самая малая верхушка ШЗ-айзберга.

iTuneDVR

Вот тут, про стек, Вы явно не подумав вкрутили т.к. не в нём и дело! Речь шла только про открытые и слабо незащизенные данные внутри пакетов на сегодняшний день. И не более ;)

Как это не в нём? А что, типа не набор протоколов определяет способы упаковки и защиты передаваемых данных? Вот новость.

По-видимому, Вы не в курсе про какое ПО идёт речь,

Как я понимаю, речь про видеоклиенты? Их много разных. Браузеры, например, тоже ими являются.

Ну не писал я про SSL и HTTPS в данной статье и не рассматривал пока

Вы тёрли чуть выше про слабую защиту. Возникает закономерный вопрос, защищать ли "данные внутри пакетов" или собственно канал? Я забежал слегка вперёд, но почему бы нет?

Телнет доступ приведён лишь как пример чтобы указать на результаты

Результаты чего? Обнаружения дыры? Тут всё очевидно. Если подразумевается, что, кроме показанной, есть другие дыры, это тоже как бы предсказуемо. В чём пафос-то?

Суть уязвимости в том, что Вам не удастться это прибить ни на раз-два, ни на три-четыре.

Чего ж не удасться? Прибью как приложение, заблокировав порты, и всё.

Не нужно иметь доступа в телнет и тем более не нужно иметь авторизацию на устройстве. Можно и без этого и получить авторизацию, как по умолчанию при завоодских настройках,

А что мешает заводские настройки сразу же изменить, ещё до выставления камеры в сетку? Мало ли, где чего можно "по умолчанию", так для того администрирование существует, чтобы все умолчальные проблемы фиксить.

Видимо вам как-то знакома или близка это тема, раз Вы неоднократно проводите параллели с ней ;)

Да, запарили дураки, принципиально не изучающие матчасть. И достали жалобы от них же на несовершенство мира.

Если Вам сложно понять, что такое локальная сеть

Понимать тут вообще нечего. Сервер и клиент могут быть в разных сетях. Вы там про какую сетку рассуждаете?

Рассматривайте эту ситуацию с точки зрения трояна у Вас на ПК

При чём троян к сетевым проблемам? Ну вот просто интереса ради, если моя локалка изолирована от Inet'а, что сможет сделать троянец у меня на компе? Чудесатые сравненьица. А если у компа все порты торчат наружу без прикрытия, то и безо всякого трояна можно наворотить делов, даже не зная паролей, а просто используя хорошо известные уязвимости системы. Но кто мешает эти все уязвимости прикрыть хотя бы по портам?

Не имея прямого отношения к теме

К теме чего? Видео? Работаю с ним местами и временами. Сетей? Админю их. Так в чём дело? Дырки закрыть? Это задача, а не проблема. Вы до этого не дошли в данной статье, но кто-то у же дошёл... на практике.

Все эти дыры, вами указанные, есть не только в видеокамерах, понимаете ли. Они бывают в маршрутизаторах (ошибки прошивок), в операционных системах, в медиацентрах и т.п. Т.е., ничего такого эксклюзивного в проблемах неавторизованного доступа в камерах Hikvision нет.

Собственно, об этом писал Бухаров, употребив термин "болезни роста".

Troll!

Даже не стану утруждать себя комментированием Ваших опусов.

Те, кто хотят оставаться в неведении, пусть остаются в нём и остаются. Я ведь ни кого не уговариваю ;)

Я вёл речь про конкретные уязвимости, конкретного бренда и если Вы о них уже знали и тем более навесили ярлык неэксклюзивности проблемы, то это тоже Ваше дело!

Ваше отношение к теме безопасности мне стало понятным! ;) ;) ;)

Тюрину.

а Вы то как давно стали заниматься ШЗ-видеонаблюдением?

А как дешёвые китайские камеры нарисовались на горизонте, так и припёрло :-(.

А вам известно что самая главная проблема именно в том - что Вы с легкой руки отправили в топку?

В смысле - в софте? В его наличии или в его сырости/дыроватости? Дык, весь массовый софт такой, вообще. Что поделать?

А Вы в курсе для чего существует - RTSP (Real Time Streaming Protocol)?

В исходной статье речь шла о неавторизованном доступе к настройкам камер Hikvision. Внимание, вопрос: какое отношение RTP, RTSP и прочие потоковые протоколы имеют к копанию в настройках камер? О чём, вообще, разговор? Статью комментим или с проблемами видеопотоков разбираемся? Так это другая тема совсем.

Так что проблемы с авторизацией - на фоне проблем с невозможностью шифрования (а значит и дешифрирования) ШЗ-ПОТОКА видео и мета данных - в принципе только лишь самая малая верхушка ШЗ-айзберга.

Лично мне не очевидна надобность шифрования видеопотока - т.е., попросту говоря, картинки с камеры. Но статья всяко не о потоках. А всего лишь о дырках в протоколах идентификации/аутентификации пользователя. Что ни разу не ново в ITшке.