Безопасность средств безопасности: СКУД

Тогда вообще зачем два пароля? Достаточно одного?

Можно вообще без пароля - по маркеру чиста дискреционно! Но надо знать материал :-).

Начнем по порядку.

2 Troll :

Вот никогда я не мог понять, что такое "уязвимость СКУД" в принципе?

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

Уязвимость СКУД - это возможность заставить работать СКУД не так как планировалось. Например, если программист не хотел, чтобы любой мог зайти в панель администрирования - он сделал авторизацию на панель администрирования. А возможность любого узнать действующий пароль от панели администрирования - нарушение изначальной логики планируемой программистом. Поэтому возможность получения пароля от панели администрирования для обхода авторизации и получения доступа к панели администрирования -- уязвимость. Причина уязвимости -- это сторонний вопрос. Неправильно настроенное приложение или уязвимость заложена программистом – это не имеет значения для злоумышленника и не имеет значения для самого термина "уязвимость".

Уязвимость к кому и к чему?

Понятия "Уязвимость к кому" и "Уязвимость к чему" применительны только тогда, когда есть модель угроз для конкретной организации и модель потенциального злоумышленника. Представьте, что у вас банковское хранилище на первом этаже вашего здания. Вы планируете систему безопасности, расставляете охрану, крепкие двери, системы идентификации, реализуете пропускной режим и т.д. И человеку, даже вооружённому, не получится проникнуть в ваше хранилище несанкционированно. Но у вас есть риск, что проезжающий мимо бульдозер снесет стену между улицей и банковским хранилищем и тогда все остальные средства защиты будут не эффективны. Это реальный риск, и вы вынуждены от него защищаться! Безопасность вашего банковского хранилища имеет уязвимость в виде слабой стены и легкой доступности 3х лиц к этой слабой стене. Другими словами, можно сказать: Безопасность вашего банковского хранилища уязвимо к атаке бульдозером. Поэтому особо важные помещения располагаются или высоко или в подвалах и как правило внутри здания окруженными только контролируемыми соседними помещениями. Есть ли такой риск, скажем, для KFC или офисного здания? У них своя модель угроз и своего потенциального злоумышленника. Этот риск они или принимают, или компенсируют, например, страховкой. Они не рассматривают его всерьез и бесполезно идти к ним со словами "я нашел у вас критическую уязвимость!". Поэтому в данной статье, я рассматриваю уязвимости в общем - то что можно сделать в нарушение изначально задуманной логики. А каждый уже сам должен решать - приемлемы для него эти риски, реализуемые через эти уязвимости или нет. Опять же привожу тот же пример из статьи второй раз:

Парковка под жилым домом, два охранника в одной комнате. Есть ли у них риск что кто-то из их локальной сети, где только они вдвоем, воспользуется уязвимостью СКУД несанкционированно узнать пароль администратора СКУД? Хотя они и так, сами по себе, являются администраторами СКУД. Вот для них такого риска нет, даже узнав о нем они не будет волноваться по этому поводу. У других будет другая ситуация и их это будет волновать.

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

Это называется «рынок информационной безопасности». Согласно оценкам аналитического центра TAdviser, объем рынка информационной безопасности в России по итогам 2014 года составил 59 млрд рублей. Мы ничего не производим, основная наша задача - мыслить деструктивно и ломать все что попадается под руку для того что бы обезопасить заказчиков от мотивированных профессиональных злоумышленников и предложить решение и защиту от таких рисков. Это имеет смысл только для среднего и крупного бизнеса с большими ресурсами и активами. Мелким компаниям это вовсе не по карману, да и злоумышленники охотятся только за "вкусными" целями. «Хактивизм» мы не берем в расчет, мелкие компании и так ломают в массовом порядке, часто об этом факте даже не узнают мелкие компании. А промышленный и государственный шпионаж процветает и точкой входа для таких злоумышленников и являются продукты которые мы исследуем наравне со злоумышленниками. Может быть, с точки зрения некоторых разработчиков, ИБ-ресерч абсолютно бесполезное дело и никому оно не нужно. Компании, которые заказывают тестирование на проникновение своих сетей и аудиты своих продуктов диаметрально противоположного мнения. Не одна компания была очень благодарна мне за обнаруженные уязвимости сторонних продуктов, которые они используют в своей инфраструктуре. И многие компании отказались от использования тех или иных продуктов, в том числе и СКУДов из списка, приведенного мной, после предоставления отчета о тестировании на проникновении их периметров сети. Да, часть ваших клиентов отказались от ваших скудов в пользу других производителей СКУД после пентеста, это факт. И все эти компании крупные и каждый из вас не редко пользуется услугами этих компаний и часто бывает на их территории как физ.лицо. И многие обращаются за такими услугами после инцидента ИБ, т.е. тогда, когда у компании украли очень много денег, или когда компания понесла большие репутационные риски или в момент шантажа злоумышленником, который воспользовался недостатками ИБ их сети или отдельных продуктов сторонних производителей. И да, у меня есть опыт расследования взлома компании, сделанного через один из исследуемых мной скудов. Естественно, что за СКУД и что за компания и когда про это писали новостные сайты я разглашать не буду. Полезным для общества, является не только исследование чего-либо по запросу заказчика, но и бесплатные исследования для дальнейших публикаций в СМИ. Так как это позволяет привлечь внимание общественности к существующим проблемам и повлиять на разработчиков которые имеют отношения к появлению тех или иных уязвимостей. Простое обращение к производителю или разработчику не всегда имеет положительный результат. И именно после громких публикаций или взломов разработчик начинает что-то менять в своих процессах. И это безусловно полезно для общества и потребителей. Если бы не крики в интернете и конференциях, не было бы встроенной защиты от переполнения в Windows типа DEP и более современных механизмов защиты. Не велись бы разработки замены уязвимого ADS-B, с помощью которого можно разбивать самолеты, вносить неразбериху в диспетчерские станции аэропортов и угонять самолеты на автопилоте в условиях невозможности визуальной ориентации по местности. Не прикрывались бы массовые уязвимости SCADA систем критической инфраструктуры заводов. А случаи эксплуатации уязвимостей SCADA систем происходят регулярно и со взрывами и с остановкой реакторов и турбин, в том числе с подачи иностранных разведок. В прошлом декабре, например, была атака на энергетическую систему Украины ( http://www.securitylab.ru/news/478193.php ). Большинство таких уязвимостей SCADA систем прикрываются как раз за счет бесплатного ресерча заинтересованными исследователями и некоммерческих организаций типа SCADASOS, которые занимаются исследованием этой проблемы и призывают всех отправлять им обнаруженные бреши безопасности SCADA-систем. Так что полезность бесплатного ресерча не переоценить. Просто не всем это понятно. Это незаметно для повседневной жизни рядового человека. А умные компании, которым есть что защищать, объявляют о BugBounty программах и сами платят за обнаруженные у них уязвимостей и призывают всех "ковырять" все их продукты и сайты. И они не стесняются сами публиковать что их продукт, оказывается, был уязвим и благодаря кому-то они успешно исправили эту уязвимость. И для клиента это сигнал, что компания не на шутку заботится о своей безопасности, раз предлагает всем проверить себя на безопасность и платит за это хорошие деньги.

2 Андрей Бухаров:

Три раза прочел, но не понял основного: в чем уязвимость то?

1. После установки по умолчанию СКУД уязвим для несанкционированного доступа по локальной сети. Будьте реалистами, не будут все пользователи менять все пароли, особенно от внутренней БД, о которой большинство ваших потребителей даже не знает. Я видел случай, когда СКУДом управлял юрист, просто немного разбирающийся в IT из-за нехватки кадров. Как вы ему объясните, что такое Firebird и открытый порт компьютера? В силах разработчика, сделать обязательную смену пароля при установке. Вот и все.

2. Используется привилегированная учетная запись СУБД для доступа клиентов. Это не безопасно. Погуглите "безопасность СУБД". Например, через SYSDBA можно захватить весь компьютер целиком. Например, установив новый пароль администратору системы и включив удаленный доступ к компьютеру.

3. Используется одна учетная запись СУБД для прямого подключения к БД разными пользователями. Это небезопасно. Как вы будите выяснять кто из пользователей удалил всю базу данных или внес злонамеренные правки в неё? Подключаться к СУБД он будет не через ваш клиент, а через клиент СУБД.

4. Нет вообще защиты от снифинга.

5. В некоторых случаях, СКУД сам разглашает пароль в открытом виде любому желающему.

К тому же, некоторые СКУД перестают работать если поменять пароль от SYSDBA, т.к. в клиенте нет возможности указать новый пароль от SYSDBA. А это значит, что потребитель не в состоянии самостоятельно избавится от уязвимости. Только другой СКУД или ожидать патч от производителя.

2 Troll:

Видно, не привыкли мы на СКУДы смотреть с позиций айтишки. Которая, кстати сказать, абсолютна лишена какой бы то ни было безопасности чуть более, чем полностью :-))).

Вы не были в компаниях, работающих с большими деньгами и имеющих квалифицированных специалистов.

Эх вот же были времена педальных турникетов и бумажных СКУДов. И - ни уязвимостей, ни заморочек... ляпота :-))).

Только методы социальной инженерии. Только хардкор.

2 Андрей Бухаров:

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

Но на то она и база, чтобы сохранять данные и изменения.

О чем тогда речь? Что порт "торчит" в сети? Дык они у всех сетевых служб торчит.

Именно! Потому что он торчит в сеть и с общеизвестным всем паролем. Сделайте принудительную смену пароля при установке. Откажитесь от root и SYSDBA, разграничивайте доступ пользователей БД или мигрируйте на API, шифруйте трафик, реализуйте грамотный механизм авторизации.

Вы говорите, как подчиненные одного из моих клиентов. У них делаются бэкапы всей почтовой переписки всех сотрудников компании, включая топов и гендиректора. Бэкапы они хранят на SMB-шаре во внутренней сети компании доступной любому пользователю домена. На мое указание на этот факт они буквально взорвались возмущенными возгласами примерно такого содержания: "Вы хоть знаете что такое бэкап? А где нам его хранить, как не на сервере внутри компании? Вы что предлагаете нам вообще не хранить бэкапы?". Тот факт, что любой сотрудник компании может читать почтовую переписку любого другого сотрудника компании, в том числе руководства, они как будто не заметили или, может быть, просто не осознали. Или не захотели осознавать, т.к. были аффилированными лицами к этой проблеме. А мысль, чтобы как минимум ограничить доступ к шаре только нужным для бэкапа учеткам домена им в голову не пришла. Хотя это решение простое и быстро реализуемое. Смотреть на свое творение, будь то сеть компании или разработанный продукт, "не замыленным" и трезвым взглядом с точки зрения безопасности -- сложная способность. Реально, это сложно. Поэтому отделы ИБ и IT разделяют, поэтому проводят независимые ИБ-аудиты и пентесты сторонними профильными компаниями.

Хотите обезопасить себя от непрошенного доступа из сети? Так используйте готовые решения защиты сетей и данных. Это несложно.

Хватит типовых решений ОС, даже денег не надо.

Может быть просто сменить общеизвестный пароль от БД при установке? Это не сложно. Или вы, говоря про типовые решения ОС имеете ввиду закрыть порт фаерволом? Так от этого отвалятся все клиенты скуд и к нему не подключиться. Или вы про смену пароля SYSDBA средствами Firebird? Тогда пишите большим красным шрифтом, что его ОБЯЗАТЕЛЬНО нужно сменить и пусть это мигает при каждом подключении СКУД вместе с инструкциями как это сделать. Или может всё-таки просто принудительно его меня при установке?

А что за готовые типовые решения ОС, которые компенсируют нешифрованность трафика при передачи его по сети? Или имеется ввиду использовать для шифрования трафика продукты типа VipNet или самостоятельно прокладывать vpn-туннели между клиентом и сервером? А говорит ли такой разработчик покупателю купить еще и эти продукты, что бы СКУД безопасно работал? Да, нужно устанавливать СКУД только в изолированной сети -- согласен. К сожалению, не все так делают и не все так могут делать. Я конечно, утрирую, но не безосновательно. Без многих этих вещей можно успешно жить, но раз мы начали разговор о том: "Так в чем же здесь уязвимость?" надо показать на все выявленные недостатки. Или позиционируйте СКУД, как пригодный для работы только в изолированной сети и делайте акцент на то что разделение пользователей СКУД условное, реализуемое только интерфейсом программы, а не по сути.

Т.е. мы опять имеем банальную ситуацию: безопасность - это комплекс мер.

Да. Как со стороны пользователя, так и со стороны разработчика.

А нам автор рассказывает, как в лабораторных условиях он зашел на базу и теперь может похерить ее. В каком месте тут уязвимость то? Уязвимость чего?

Я так делал и не в лабораторных условиях, а на живых объектах. И в рамках пентеста с санкцией на это у заказчика, и без санкций как физ.лицо для своей личной выгоды. Уязвимость в том, что я это смог сделать, являясь "никем" в этих организациях.

Если в приложении вы введете пароль умолчательный фаерберда, то, скорее всего, получите отлуп.

Не "скорее всего", а в 100% случаев. Его нужно вводить в клиент СУБД для этой СУБД. А там вы уже можете сами себе добавить еще одного администратора приложения СКУД, или узнать пароль или хеш-пароля существующего администратора СКУД. И вот уже тогда его вводить в приложение СКУДа, и вот тогда вы залогинитесь в 100% случаев.

Не надо путать пароли доступа к базе и пользовательские пароли доступа к данным.

Вот именно.

Стоит ли здесь рассматривать вопросы распределения прав в СУБД FireBird? Мне кажется, не стоит. В СУБД FireBird этот вопрос решен не менее просто и надежно, чем в любых других базах данных.

Авто пока озвучил одну проблему: мол, порт открыт, и пароль умолчательный не изменен.

Я для того и пытался уточнить: о какой такой уязвимости идет речь?

А частных случаев (открыл у себя на виртуальной машине и т.п.) может быть масса.

Хочу отметить, что ни на одном серьезном объекте я не встречал СКУД, включенный в общую сеть. Начальники служб безопасности достаточно четко понимают опасности и решают эти вопросы просто, эффективно и комплексно.

>; Стоит ли здесь рассматривать вопросы распределения прав в СУБД FireBird? Мне кажется, не стоит. В СУБД FireBird этот вопрос решен не менее просто и надежно, чем в любых других базах данных.

Так почему это не используется в рассмотренных СКУД ? =) Я не "гоню" на Firebird, я "гоню" на исполнение.

>; Авто пока озвучил одну проблему: мол, порт открыт, и пароль умолчательный не изменен.

Вы или невнимательны или намеренно пропускаете остальные описанные мной.

>; А частных случаев (открыл у себя на виртуальной машине и т.п.) может быть масса.

И они же прослеживаются в реальности. За год я аудирую несколько десятков внутренних сетей разных компаний. Выборка, вполне репрезентативна.

>; Хочу отметить, что ни на одном серьезном объекте я не встречал СКУД, включенный в общую сеть. Начальники служб безопасности достаточно четко понимают опасности и решают эти вопросы просто, эффективно и комплексно.

Сплошь и рядом.

О, мы почти одновременно писали ответ.

Вы прояснили кое-что, теперь разговор может быть более аргументированым.

Сделайте принудительную смену пароля при установке. Откажитесь от root и SYSDBA, разграничивайте доступ пользователей БД или мигрируйте на API, шифруйте трафик, реализуйте грамотный механизм авторизации.

Дальше можно и не продолжать, ибо паролями СУБД должен управлять администратор СУБД. Если его нет - разговаривать об информационной безопасности нет смысла. Нет администратора СУБД - значит, заказчика этот вопрос не волнует. Хоть какие ему пароли ставь.

Вот Вам лакмусовая бумажка Вашего совета: на компьютере уже установлен FireBird. Следуя Вашему совету, СКУД сменила пароль sysdba при установке на другой. К чему это приведет? Говорит, что Вы - специалист по информационной безопасности?

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

Вот это дело меня давно интересует. Расскажите хотя бы схему: как СКУД может привести к потере денег? Как это хоть в принципе возможно?

Естественно, что за СКУД и что за компания и когда про это писали новостные сайты я разглашать не буду. Полезным для общества, является не только исследование чего-либо по запросу заказчика, но и бесплатные исследования для дальнейших публикаций в СМИ.

Уважаемый Соболев Евгений, а можно мне (как бывшему сотруднику ниже упомянутой фирмы) поинтересоваться:

- А какой же уязвимостью страдает СКУД компании, упомянутый Вами вот тут, третья строчка снизу, под номером 87, если в офисе данной компании никакого сетевого СКУД нет вообще, как и впрочем нет - просто СКУД-а, а всего лишь есть пара контроллеров ТМ, на паре дверей?

;))

Полезный совет: для цитирования - веделяем нужную часть текста и кликаем по ссылке Цитировать (справа внизу под текстом).

Тюрин ВВ, вас скопировали с нашего сайта.

Там еще пара десятков фирм, которые совершенно незаслуженно попали в этот лист.

Я, кстати, писал Евгению об этом 15 февраля. Но, не настаивал на чистке списка, да и сейчас как-то отношусь к этому спокойно.

>; Дальше можно и не продолжать, ибо паролями СУБД должен управлять администратор СУБД. Если его нет - разговаривать об информационной безопасности нет смысла. Нет администратора СУБД - значит, заказчика этот вопрос не волнует. Хоть какие ему пароли ставь.

У вас, наверняка, есть либо iOS или Android, а вы знали, что почти каждое приложение для них использует БД? Скажите, а у вас есть администратор СУБД, который админит эти базы данных ваших мобильных приложений вашего телефона? Наверно нет.

Вы, наверняка, даже не думали об этом. Так почему покупатель СКУД должен догадываться что в купленном им продукте есть БД для которой нужно что-то дополнительно делать?

Когда СКУД отдельно, а СУБД отдельно -- другое дело. Вы отдельно поставляете покупателю СКУД, а он сам отдельно устанавливает СУБД или использует уже существующую. Тогда ответственность на нем. Но тут есть и минусы - завышается порог необходимых знаний для сопровождения такого СКУД -- нужно иметь администратора СУБД или человека, способного безопасно настроить СУБД разово. Для некоторых это может быть критично, и, возможно, они бы отказались от такого СКУД в пользу более простого для сопровождения.

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

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

Я вообще не понимаю, о чем так долго можно говорить -- неужели так сложно не использовать пароли по умолчанию от СУБД, которая является частью продукта?

>; Вот Вам лакмусовая бумажка Вашего совета: на компьютере уже установлен FireBird. Следуя Вашему совету, СКУД сменила пароль sysdba при установке на другой. К чему это приведет? Говорит, что Вы - специалист по информационной безопасности?

Ну смотрите. "сменила пароль sysdba при установке на другой": Если такая возможность была при установке СКУД, значит СКУД должен продолжить работать исправно. А если перестал, например, потому что клиентская часть не знает новый пароль -- косяк разработчика.

Вы наверно хотели описать ситуацию с "подвохом", когда на компьютере со СКУД уже установлен FB от другого приложения, и мол при его смене отвалится это стороннее приложение. Так? Тогда вопрос: Что на этом компьютере делает это строннее приложение? Вы говорите, что СКУД это особо важная система, настолько важная, что ее нужно выносить в отдельную физически изолированную сеть. И при всем этом, у вас нет отдельного компьютера под СКУД?)

К томуже, если быть внимательным, перед этим советом я писал про проблемы с работоспособностью некоторых экземпляров СКУД, неспособных работать с другим паролем.

>; Вы - специалист по информационной безопасности?