Comments 33
UFO just landed and posted this here
Буква S в IoT обозначает Security
Если на IoST надежды мало, нужен SIoT x)
Разработал бы кто-нибудь коммуникационный фреймворк для умных вещей: адаптеры (проводные/беспроводные), какие-нибудь микроплаты с чипом, со стандартным проводным интерфейсом, которые можно объединить в безопасную сетку, настроить доступ, там, облако — а через стандартный интерфейс к ним подсоединяется само умное устройство. Т. е. безопасная коммуникация стандартизирована, а дальше уже функционал реализуется конкретными железками
Разработал бы кто-нибудь коммуникационный фреймворк для умных вещей: адаптеры (проводные/беспроводные), какие-нибудь микроплаты с чипом, со стандартным проводным интерфейсом, которые можно объединить в безопасную сетку, настроить доступ, там, облако — а через стандартный интерфейс к ним подсоединяется само умное устройство. Т. е. безопасная коммуникация стандартизирована, а дальше уже функционал реализуется конкретными железками
Это называется TLS и железку ради этого никто ставить не будет, тем более для физической защиты нужно эту железку-интерфейс в устройство как можно глубже запихать и эпоксидкой залить.
Будет, если это даст преимущества. TLS — это протокол, который иногда меняется, соответственно, меняется реализация, надо писать новые прошивки для умных устройств, кто-то должен их перепрошить, ну и тут кто во что горазд. С «SIoT Framework» производитель адаптеров максимально концентрируется на сетевой безопасности, инфраструктуре управления сетью и обновления прошивок, ну и над самими прошивками. Адаптер перепрошивается по сети (с ограничениями доступа, криптоподписью обновлений и т. п.), можно заливать эпоксидкой. В случае отсутствия железных уязвимостей, умная сеть максимально оперативно приводится в безопасное состояние (если обнаружена уязвимость в прошивке). Т. о. коммуникации централизованно, с известной степенью гарантии поддерживаются секьюрными.
… все действия злоумышленник может выполнять без журналирования действий. То есть, грубо говоря, можно открыть любое помещение, взять там или сделать все, что нужно, выйти, и никто и никогда об этом не узнает.
Руководство считает, что уязвимость никто не использовалЛогично.
То есть сисадмины загнали трафик АСКУД в общую сеть IoT, к которой есть доступ у «программистов», полагаясь на стандартное враньё инсталляторов «мамой клянусь, зашифровано!», но они тут ни при чём?
Я не знаю, какой надо иметь опыт, чтобы не понимать, что, к сожалению, самая худшая ситуация с безопасностью всегда у так называемых «безопасников», от СКУД и до систем сетевой безопасности. «Шифрование» в каком-нибудь 8-битном контроллере двери оказалось фальшивым! Surprise-surprise! Да слава Богу, если там Ethernet+UDP/IP смогли реализовать! Такие системы всегда, что бы ни говорили инсталляторы, выделяются в изолированную подсеть, трафик защищается по максимуму как plain text sensitive data, доступ строго регламентируется.
Даже если мы говорим о системах, которые передают шифрованные данные и не могут быть изолированы, как можно принимать систему, по которой идёт sensitive трафик с «каким-то» шифрованием? Что было задокументировано? Какой алгоритм, как и где хранятся ключи, какой график их ротации? Что значит программист «выяснил, что ключ шифрования вообще зашит в память всех устройств указанной компании», а тот, кто систему принимал, выставляя её в недоверенную подсеть, этого не выяснил?
Собственно, вопрос только один: у них в «облаках» тоже такой же уровень компетенции, или для обслуживания внутренней инфраструктуры они отобрали худших?
Хочу заметить, что я не оправдываю фирму-изготовителя и инсталлятора: да, у них у всех бардак с безопасностью, и говорить об этом нужно, но это — известная беда, а вот про сисадминов Google можно было раньше только догадываться.
Я не знаю, какой надо иметь опыт, чтобы не понимать, что, к сожалению, самая худшая ситуация с безопасностью всегда у так называемых «безопасников», от СКУД и до систем сетевой безопасности. «Шифрование» в каком-нибудь 8-битном контроллере двери оказалось фальшивым! Surprise-surprise! Да слава Богу, если там Ethernet+UDP/IP смогли реализовать! Такие системы всегда, что бы ни говорили инсталляторы, выделяются в изолированную подсеть, трафик защищается по максимуму как plain text sensitive data, доступ строго регламентируется.
Даже если мы говорим о системах, которые передают шифрованные данные и не могут быть изолированы, как можно принимать систему, по которой идёт sensitive трафик с «каким-то» шифрованием? Что было задокументировано? Какой алгоритм, как и где хранятся ключи, какой график их ротации? Что значит программист «выяснил, что ключ шифрования вообще зашит в память всех устройств указанной компании», а тот, кто систему принимал, выставляя её в недоверенную подсеть, этого не выяснил?
Собственно, вопрос только один: у них в «облаках» тоже такой же уровень компетенции, или для обслуживания внутренней инфраструктуры они отобрали худших?
Хочу заметить, что я не оправдываю фирму-изготовителя и инсталлятора: да, у них у всех бардак с безопасностью, и говорить об этом нужно, но это — известная беда, а вот про сисадминов Google можно было раньше только догадываться.
Всё что вы пишите в принципе очень правильно, но есть простое объяснение — доверие. Если вы покупаете сейф от известной фирмы, вы не будете лично проверять его надежность, так как знаете что сейфы этой фирмы надежны. Через время может оказаться что это не так, и вы примете меры — а пока этого не случилось — вы вряд-ли будете прятать его в бункере и нанимать «медвежатников» для его проверки.
Когда вы поднимаете у себя SSH сервер, вы вряд-ли расчитываете что у него где-то дыра — и также вряд-ли проверяете его код (и код всех используемых им зависимостей), плюс все используемые алгоритмы шифрования и аутентификации. Нет, конечно, можно ещё для «надежности» завернуть его в VPN, но — а вдруг у этого VPN тоже дыра (особенно если это закрытое решение)? Завернете его в другой VPN или построите свои каналы связи, охраняемые собаками Баскервилей по всей протяженности?
До какого уровня вы готовы (и способны) всё проверять и прятать?
Когда вы поднимаете у себя SSH сервер, вы вряд-ли расчитываете что у него где-то дыра — и также вряд-ли проверяете его код (и код всех используемых им зависимостей), плюс все используемые алгоритмы шифрования и аутентификации. Нет, конечно, можно ещё для «надежности» завернуть его в VPN, но — а вдруг у этого VPN тоже дыра (особенно если это закрытое решение)? Завернете его в другой VPN или построите свои каналы связи, охраняемые собаками Баскервилей по всей протяженности?
До какого уровня вы готовы (и способны) всё проверять и прятать?
Именно для того, чтобы исключить субъективные факторы, такие как «доверие бренду» и существуют наилучшие практики индустрии и регламенты. Был бы нормальный регламент, была бы графа «шифрование», в которую нужно было бы что-то вписать. Был бы график ротации ключей, было бы необходимо составить инструкцию по ротации. И никакое доверие тут бы не помешало.
Кроме того, я не предлагаю обязательно реверсить систему, эти вопросы задаются и документация запрашивается на этапе выбора поставщика. Именно на этом этапе все поставщики (особенно, если вы выгодный заказчик, а Google кроме непосредственно прибыли приносит и свой мега-бренд в портфолио на страницу «нам доверяют») готовы дойти по цепочке до самого последнего своего разработчика, информацию получить и вам предоставить, даже если её нет в стандартном буклете. Нет ответа — система считается передающей информацию открытым текстом и принимаются соответствующие меры безопасности, такие как дополнительное шифрование, изоляция, отказ от закупки. Более того, отсутствие изоляции, судя по описанию, уже само по себе — неоправданное нарушение наилучших практик.
Опять же, идёт оценка рисков, которая и показывает, до какого уровня в каждом конкретном случае стоит доходить в дополнение к базовым практикам. «Дыры», в смысле программных ошибок, могут учитываться как фактор оценки рисков, но в данном случае не было «дыры», насколько можно судить. Было нарушение базовых наилучших практик, и, вероятно, отсутствие регламента при настройке sensitive систем.
Кроме того, я не предлагаю обязательно реверсить систему, эти вопросы задаются и документация запрашивается на этапе выбора поставщика. Именно на этом этапе все поставщики (особенно, если вы выгодный заказчик, а Google кроме непосредственно прибыли приносит и свой мега-бренд в портфолио на страницу «нам доверяют») готовы дойти по цепочке до самого последнего своего разработчика, информацию получить и вам предоставить, даже если её нет в стандартном буклете. Нет ответа — система считается передающей информацию открытым текстом и принимаются соответствующие меры безопасности, такие как дополнительное шифрование, изоляция, отказ от закупки. Более того, отсутствие изоляции, судя по описанию, уже само по себе — неоправданное нарушение наилучших практик.
Опять же, идёт оценка рисков, которая и показывает, до какого уровня в каждом конкретном случае стоит доходить в дополнение к базовым практикам. «Дыры», в смысле программных ошибок, могут учитываться как фактор оценки рисков, но в данном случае не было «дыры», насколько можно судить. Было нарушение базовых наилучших практик, и, вероятно, отсутствие регламента при настройке sensitive систем.
Было нарушение базовых наилучших практик, и, вероятно, отсутствие регламента при настройке sensitive систем.Это не было «sensitive» системой. Обычные двери в офисе. Их в офисе Гугла может быть не одна сотня. И да, они физически в отдельной сети, но для обхода этой проблемы применяется уже обычный (и неуничтожимый) «social engineering». Отсюда, собственно, и уверенность в том, что никто этим не воспользовался…
Не понимаю, как по-вашему команды системы СКУД могут быть не sensitive. Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Что касается сегментации, насколько я помню, изначально в статье на Хабре было написано про «программиста», который в общей сети IoT эти контроллеры увидел и трафик с них разбирал. Сейчас статья подкорректирована, «программист» превратился в «специалиста по компьютерной безопасности», а если заглянуть в первоисточник, то предлагаемый вектор атаки — включение MiTM в патч-панель, которая доступна только местным электрикам и связистам (что тоже не совсем хорошая практика, если нет запрета таким контракторам работать без надзора). Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
На англоязычных ресурсах есть практика, когда об изменениях в статье пишут внизу приписку, мол, то-то и то-то было исправлено. Комментарий на Хабре изменять можно только первые 5 минут, а саму статью можно незаметно править хоть через год, а ведь после этого комментарии теряют актуальность!
Что касается сегментации, насколько я помню, изначально в статье на Хабре было написано про «программиста», который в общей сети IoT эти контроллеры увидел и трафик с них разбирал. Сейчас статья подкорректирована, «программист» превратился в «специалиста по компьютерной безопасности», а если заглянуть в первоисточник, то предлагаемый вектор атаки — включение MiTM в патч-панель, которая доступна только местным электрикам и связистам (что тоже не совсем хорошая практика, если нет запрета таким контракторам работать без надзора). Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
На англоязычных ресурсах есть практика, когда об изменениях в статье пишут внизу приписку, мол, то-то и то-то было исправлено. Комментарий на Хабре изменять можно только первые 5 минут, а саму статью можно незаметно править хоть через год, а ведь после этого комментарии теряют актуальность!
Не понимаю, как по-вашему команды системы СКУД могут быть не sensitive. Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Замки ставят даже на комнатки для уборщиков и кухни, где нет абсолютно ничего sensitive.
Я подозреваю что там действительно нет ничего настолько важного чтобы заморачиваться драконовскими методами защиты — то есть при установке риск был оценен как «низкий», со всеми вытекающими. Но разумеется, когда обнаружилась «дыра», это нельзя было просто так оставлять.
Самая банальная причина, кстати — это просто учёт кто куда и когда ходит, для статистики.
Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
Зачем устраиваться? Заплатить уже действующему работнику (или шантажировать его), и всех делов. Для особо продвинутых — подменить его кем-то своим в нужный момент (да, это бывает и в реальной жизни, а не только в фильмах). Впрочем, это всё будет иметь смысл только если там (за дверями) реально что-то исключительно важное, иначе игра не стоит свеч.
то что замки ставят на каморки уборщиков не значит что такие же замки не ставят на серверные, вряд ли там эксплуатируется несколько разных систем вместо одной «мегабезопасной». итого мы получаем уже дыру не только в никому ненужную комнату уборщика, но и в серверную/машинный зал и прочие чувствительные места, да хоть в комнаты для совещаний — для установки жучков.
то что замки ставят на каморки уборщиков не значит что такие же замки не ставят на серверные, вряд ли там эксплуатируется несколько разных систем вместо одной «мегабезопасной».Зависит от того, какая серверная. Для доступа к тем серверам, где данные пользователей хранятся, точно нужен другой бейдж другой системы. Всякие локальные сервера — по общему, но с дополнительными правами.
да хоть в комнаты для совещаний — для установки жучков.Комнаты для совещений тоже пару уровней имеют. В частности совсем большие, куда иногда сотни партнёров приходят, считаются «небезопасными» по умолчанию.
Если за этими дверьми нет ничего sensitive, то зачем систему покупали?Затем, что если бомжи зайдут и унесут несколько компов — это уже убыток. Но с учётом того, что все данные на всех компьютерах зашифрованы и для расшифровки нужен ещё и аппаратный ключ… всё не так плохо.
Места, где можно найти что-то сильно «вкусное» (какие-ниудь новые железяки, которые не зашифруешь и прочее) — физически в отлельном здании. С более жёсткой системой охраны всех этих свитчей, в частности.
Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.Можно не устраиваться на работу, а одеться в спецодежду и найти местео, где что-то монтрируется (когда у вас порядка 100 зданий на кампусе, то где-нибудь что-нибудь монтируется почти всегда).
Вообще у Гугла есть команда, которая оценивает вероятности подобных взломов. Флешки всякие подкидывают, лампы с питанием от USB и секретом и прочее. Они как-то делали презентацию. Краткое содержание: мы сделали 100500 атак и в довольно большой части случаев (больше половины) нас поймали — но, тем не менее, XX% атак были успешными. Однако кроме нас служба безопасности не поймала никого, кто смог бы пройти дальше самого первого «уровня обороны» (собственно вот те самые двери, которые можно обойти известным способом). Возможностей две:
1. Китайские террористы гораздо более умные, чем наша команда.
2. Возможно людей, пытающихся вломиться на кампус реально нет, а ломают где-то в других местах.
Из всех моих интервью я два раза заходил в компании, минуя секурити и закрытые двери.
Просто так оказалось, что я входил в тот момент когда из нее кто-то выходил.
И оба раза это были компании, занимавшиеся криптографией. После моего входа в
компании начинался грандиозный шухер.
Мораль — какие криптозамки не навешаешь — социальную составляющую никак не отменишь.
Просто так оказалось, что я входил в тот момент когда из нее кто-то выходил.
И оба раза это были компании, занимавшиеся криптографией. После моего входа в
компании начинался грандиозный шухер.
Мораль — какие криптозамки не навешаешь — социальную составляющую никак не отменишь.
Ну блин. Такое даже в некоторых простых московских подъездах не прокатит — тамбур с двумя дверями и окошком в караулку. Не для хайлоада, конечно, решение, но такие простые трюки как «пятеро по одному пропуску» и «один вышел трое зашло» уже не прокатывают.
Если у вас «тамбур с двумя дверями и окошком в караулку», то вам нафиг не нужны «умные» двери. Их применяют, когда у вас десяток входов-выходов в здание и ещё внутри на каждом этаже по десятку. Потому что это удобно. Гугл — не «зона», с вышками и колючей проволокой, а кампус, где десятки домиков разбросаны по Mountain View (хотя бы на Street View посмотрите). Держать сотни оранников в караулках — слишком накладно.
Эка невидаль. Я с гостевой карточкой по всему зданию прошелся, многие офисы открывались.
Был я на деловой встрече у безопасников. Видеть их взгляд бесценно.
Был я на деловой встрече у безопасников. Видеть их взгляд бесценно.
Прочитав статью, я вспомнил как в далеких 90-х мы интегрировали системы контроля доступа (СКД) с системами защиты от несанкционирванного доступа (НСД) к компьютерам. Системы мы тогда назвали "Броня-ОТМ" — Система контроля несанкционированного доступа к компьютеру, совмещенная с системой контроля доступа в помещения "Броня-ОТМ". Система хорошо работала: вышел через турникет, не выключив компьютер, он автоматически выключался (и в БД все заносилось), пробрался на рабочее место минуя СКД — компьютер не загрузишь:
Система хорошо работала: вышел через турникет, не выключив компьютер, он автоматически выключалсяНо ведь остаётся еще кучка кейсов, когда за компьютер может сесть злоумышленник. Ваш кейс предполагает, что злоумышленник знает пароль от компьютера (т.к. компьютер не загрузишь). Это значит, что как только сотрудник отошёл за кофе или на кухню злоумышленние уже взломал его комп.
И опять-же утверждение Система хорошо работала напрямую зависит от количества предотвращенных и нет атак :)
как только сотрудник отошёл за кофе или на кухню злоумышленние уже взломал его комп.
Если сотрудник отошел за кофе или на кухню через турникет, то его компьютер автоматически выключится или заблокируется (как настроить систему), если он этого сам не сделал
Ваш кейс предполагает, что злоумышленник знает пароль от компьютера (т.к. компьютер не загрузишь).
Это откудово такой вывод? Зачем ему пароль, он и без него справится
В июле этого месяца некий хакер смог найти уязвимость в системе управления автоматическими дверями офиса Google. Он смог открывать двери без использования ключа RFID. К счастью для самой компании, хакером оказался ее собственный сотрудник, который выполнял работу на благо своего работодателя, а не стремился навредить ему.
Нич-чего не понимаю. © :)
Google's Doors Hacked Wide Open By Own Employee
Отрывок (на английском)
(подчеркивание мое)
<...> Sep 3, 2018, 08:02am
<...>
Last July, in Google’s Sunnyvale offices, a hacker found a way to trick doors into opening without the requisite RFID keycard. Luckily for Google, it was David Tomaschik, an employee at the tech giant, who only had good intentions.
<...>
Last summer, when Tomaschik looked at the encrypted messages the Software House devices (called iStar Ultra and IP-ACM) were sending across the Google network, he discovered they were non-random; encrypted messages should always look random if they’re properly protected. He was intrigued and digging deeper discovered a “hardcoded” encryption key was used by all Software House devices. That meant he could effectively replicate the key and forge commands, such as those asking a door to unlock. Or he could simply replay legitimate unlocking commands, which had much the same effect.
(подчеркивание мое)
Если я правильно понял, речь идет об июле прошлого года.
P.S. Поправка: похоже, речь идет об июле этого года.
P.P.S. Я задал вопрос насчет Last July на известном международном сайте переводчиков:
www.proz.com/kudoz/6559807
Мнения разделились. Особо подчеркну, что оба варианта (июль этого года и июль прошлого года) предложены профессиональными переводчиками с большим — более 20 лет — опытом работы, каждый из которых вдобавок является носителем английского языка (по крайней мере, де факто).
Сам пока склоняюсь к варианту «июль этого года», полагая, что Дэвид взломал систему открывания дверей в июле, а уже в начале августа рассказал об этом на хакерской конференции IoT Village в Лас-Вегасе.
Иначе получается, что Дэвид прождал целый год, прежде чем поделиться своими изысканиями с другими хакерами. :)
Возможно, кто-нибудь предложит другое объяснение?
www.proz.com/kudoz/6559807
Мнения разделились. Особо подчеркну, что оба варианта (июль этого года и июль прошлого года) предложены профессиональными переводчиками с большим — более 20 лет — опытом работы, каждый из которых вдобавок является носителем английского языка (по крайней мере, де факто).
Сам пока склоняюсь к варианту «июль этого года», полагая, что Дэвид взломал систему открывания дверей в июле, а уже в начале августа рассказал об этом на хакерской конференции IoT Village в Лас-Вегасе.
Tomaschik talked with Forbes about what he'd done following a talk he gave on this in early August at the DEF Con Internet of Things Village in Las Vegas.
Иначе получается, что Дэвид прождал целый год, прежде чем поделиться своими изысканиями с другими хакерами. :)
Возможно, кто-нибудь предложит другое объяснение?
ну так себе хак конечно. все равно что говорить о взломе компьютера при наличии физического доступа.
СКУД должен быть вынесен в отдельную подсеть/вилан, физического доступа к езернету СКУДа быть не должно.
а так помоему продолжает нагнетаться тенденция шифрования end2end, потому что если не имеем доверия к своей локалке, то других вариантов безопасной коммуникации у устройств нет.
Это в свою очередь на порядки поднимет требования и соттв стоимость конечных устройств, потому как устройство теперь должно не только уметь езернет и tcp/ip, но и поднять по этому tcp/ip свой шифрованный протокол, при этом иметь стабильность работы на уровне cisco, тк это потребуется как минимум для соблюдения той же пожарной безопасности (например «зависший» замок не выпустит людей в нужный момент), не говоря уж о дискомфорте при «зависшей» двери в обычных ситуациях.
СКУД должен быть вынесен в отдельную подсеть/вилан, физического доступа к езернету СКУДа быть не должно.
а так помоему продолжает нагнетаться тенденция шифрования end2end, потому что если не имеем доверия к своей локалке, то других вариантов безопасной коммуникации у устройств нет.
Это в свою очередь на порядки поднимет требования и соттв стоимость конечных устройств, потому как устройство теперь должно не только уметь езернет и tcp/ip, но и поднять по этому tcp/ip свой шифрованный протокол, при этом иметь стабильность работы на уровне cisco, тк это потребуется как минимум для соблюдения той же пожарной безопасности (например «зависший» замок не выпустит людей в нужный момент), не говоря уж о дискомфорте при «зависшей» двери в обычных ситуациях.
а так помоему продолжает нагнетаться тенденция шифрования end2end, потому что если не имеем доверия к своей локалке, то других вариантов безопасной коммуникации у устройств нет.Дык собственно это всё со Сноудена началось. Когда выяснилось что никто сеть Гугла не взламывал, а просто роутер подменили у провайдеров, сдающих в аренду оптику — а поскольку Гугл доверял «своей локалке» и ничего «внутри» не шифровал… то и всё.
например «зависший» замок не выпустит людей в нужный моментНет, тут всё просто: если ваше здание так устроено, что из него при «зависшем» замке не выйти, то никакой пожарник вам на это «добро» не даст. Больгинство дверей открываются наружу просто кнопкой, а там где нужна повышенная безопасность есть красная аварийная кнопка под стеклом (это плюс к тому, что замки обесточивается, то они открываются — так-то они от UPS'ов питаются, чтобы всё-таки безопасность какая-то была, но если кабель перегорит, то… выйти можно будет).
Один из участников темы, ссылку на которую я добавил выше, указал на следующую техническую информацию:
NVD — CVE-2017-17704
Возможно, кому-нибудь пригодится.
NVD — CVE-2017-17704
Возможно, кому-нибудь пригодится.
Sign up to leave a comment.
Сотрудник Google смог управлять системой открытия дверей в офисе компании из-за уязвимости в ПО