Если не заниматься вопросами информационной безопасности в компании, потом может быть мучительно больно
В июле этого месяца некий хакер смог найти уязвимость в системе управления автоматическими дверями офиса Google. Он смог открывать двери без использования ключа RFID. К счастью для самой компании, хакером оказался ее собственный сотрудник, который выполнял работу на благо своего работодателя, а не стремился навредить ему.
У корпорации есть внутренняя сеть, по которой передаются данные, генерируемые умными системами офисов и зданий компании. Дэвид Томашик, сотрудник Google, о котором идет речь, просто отправил созданный им код в эту сеть, после чего светодиоды на закрытых дверях сменили цвет с красного на зелёный — то есть двери удалось открыть. Сама программа оказалась не такой уж и простой в разработке — на ее создание было потрачено довольно много времени.
Изначально специалист по инфобезу нашел уязвимость в программном обеспечении компании Sofware House — партнера Google, разработавшего контроллеры безопасности для подразделения корпорации из Калифорнии.
Он изучал зашифрованные сообщения, которые отправляют устройства Sofware House (iStar Ultra и IP-ACM). Эти сообщения, как и говорилось выше, рассылаются по внутренней сети компании. Оказалось, что сообщения шифруются ненадежно, отправляются они с определенной частой, и это может использовать в своих целях злоумышленник. После детального изучения Томашик выяснил, что ключ шифрования вообще зашит в память всех устройств указанной компании. Это означало только одно — ключ можно скопировать и использовать в своих целях.
Его можно использовать не только для того, чтобы рассылать фишинговые сообщения, но и с целью выполнения любых команд злоумышленника. Они будут считаться оборудованием «легитимными» и выполняться без блокирования источника.
Но и это еще не все. Томашик определил, что все действия злоумышленник может выполнять без журналирования действий. То есть, грубо говоря, можно открыть любое помещение, взять там или сделать все, что нужно, выйти, и никто и никогда об этом не узнает. Еще интересный момент — злоумышленник, раздобывший ключ шифрования, в состоянии блокировать команды, которые подают сотрудники корпорации, а также держать любые двери закрытыми.
После того, как сотрудник известил руководство своего офиса, были приняты меры. В частности, сеть компании была сегментирована таким образом, чтобы взлом одного сектора никак не влиял на работоспособность других секторов. Кроме того, протокол шифрования iStar v2 Board был изменен на более надежный. Руководство считает, что уязвимость никто не использовал на этот раз компании повезло.
Тем не менее, оборудование Software House используют многие компании. И хуже всего то, что оно не перепрошивается — для этого у гаджетов просто не хватает памяти. И для перехода на новый протокол шифрования, например, TLS, компании, которая является клиентом Software House, придется покупать новые системы. Кроме денежных трат, это означает необходимость тратить время сотрудников на настройку новой инфраструктуры.
Уязвимость сотрудник Google раскрыл на мероприятии DEF CON Internet of Things Village, которое проводилось в начале августа. Всего участники этого мероприятия обнаружили 55 уязвимостей в оборудовании и ПО разных производителей, включая самых известных. Например, открытыми для злоумышленников оказались умные системы орошения, акустика Sonos и широкий спектр IoT-гаджетов от корейских производителей.
Компания Software House утверждает, что уже решает эту проблему со своими клиентами. Как бы там ни было, но сама ситуация подтверждает аксиому — производители IoT-систем больше заботятся о функциональности и дизайне, чем о безопасности своих устройств. И даже компании, которые занимаются производством девайсов и ПО для систем безопасности предприятия, в их продуктах часто встречаются крайне странные уязвимости, которые можно легко устранить еще на этапе разработки.
Пока производители устройств для умных домов и зданий не станут уделять внимание вопросу безопасности, злоумышленники могут безнаказанно использовать большое количество самых разных уязвимостей и дыр. Пример — червь Mirai, благодаря которому появилось большое количество крупных ботнетов.
Комментарии (33)
tikhenko
04.09.2018 18:21+4… все действия злоумышленник может выполнять без журналирования действий. То есть, грубо говоря, можно открыть любое помещение, взять там или сделать все, что нужно, выйти, и никто и никогда об этом не узнает.
Руководство считает, что уязвимость никто не использовал
Логично.
VitalKoshalew
04.09.2018 19:08+2То есть сисадмины загнали трафик АСКУД в общую сеть IoT, к которой есть доступ у «программистов», полагаясь на стандартное враньё инсталляторов «мамой клянусь, зашифровано!», но они тут ни при чём?
Я не знаю, какой надо иметь опыт, чтобы не понимать, что, к сожалению, самая худшая ситуация с безопасностью всегда у так называемых «безопасников», от СКУД и до систем сетевой безопасности. «Шифрование» в каком-нибудь 8-битном контроллере двери оказалось фальшивым! Surprise-surprise! Да слава Богу, если там Ethernet+UDP/IP смогли реализовать! Такие системы всегда, что бы ни говорили инсталляторы, выделяются в изолированную подсеть, трафик защищается по максимуму как plain text sensitive data, доступ строго регламентируется.
Даже если мы говорим о системах, которые передают шифрованные данные и не могут быть изолированы, как можно принимать систему, по которой идёт sensitive трафик с «каким-то» шифрованием? Что было задокументировано? Какой алгоритм, как и где хранятся ключи, какой график их ротации? Что значит программист «выяснил, что ключ шифрования вообще зашит в память всех устройств указанной компании», а тот, кто систему принимал, выставляя её в недоверенную подсеть, этого не выяснил?
Собственно, вопрос только один: у них в «облаках» тоже такой же уровень компетенции, или для обслуживания внутренней инфраструктуры они отобрали худших?
Хочу заметить, что я не оправдываю фирму-изготовителя и инсталлятора: да, у них у всех бардак с безопасностью, и говорить об этом нужно, но это — известная беда, а вот про сисадминов Google можно было раньше только догадываться.Tangeman
04.09.2018 20:35+1Всё что вы пишите в принципе очень правильно, но есть простое объяснение — доверие. Если вы покупаете сейф от известной фирмы, вы не будете лично проверять его надежность, так как знаете что сейфы этой фирмы надежны. Через время может оказаться что это не так, и вы примете меры — а пока этого не случилось — вы вряд-ли будете прятать его в бункере и нанимать «медвежатников» для его проверки.
Когда вы поднимаете у себя SSH сервер, вы вряд-ли расчитываете что у него где-то дыра — и также вряд-ли проверяете его код (и код всех используемых им зависимостей), плюс все используемые алгоритмы шифрования и аутентификации. Нет, конечно, можно ещё для «надежности» завернуть его в VPN, но — а вдруг у этого VPN тоже дыра (особенно если это закрытое решение)? Завернете его в другой VPN или построите свои каналы связи, охраняемые собаками Баскервилей по всей протяженности?
До какого уровня вы готовы (и способны) всё проверять и прятать?VitalKoshalew
04.09.2018 21:52Именно для того, чтобы исключить субъективные факторы, такие как «доверие бренду» и существуют наилучшие практики индустрии и регламенты. Был бы нормальный регламент, была бы графа «шифрование», в которую нужно было бы что-то вписать. Был бы график ротации ключей, было бы необходимо составить инструкцию по ротации. И никакое доверие тут бы не помешало.
Кроме того, я не предлагаю обязательно реверсить систему, эти вопросы задаются и документация запрашивается на этапе выбора поставщика. Именно на этом этапе все поставщики (особенно, если вы выгодный заказчик, а Google кроме непосредственно прибыли приносит и свой мега-бренд в портфолио на страницу «нам доверяют») готовы дойти по цепочке до самого последнего своего разработчика, информацию получить и вам предоставить, даже если её нет в стандартном буклете. Нет ответа — система считается передающей информацию открытым текстом и принимаются соответствующие меры безопасности, такие как дополнительное шифрование, изоляция, отказ от закупки. Более того, отсутствие изоляции, судя по описанию, уже само по себе — неоправданное нарушение наилучших практик.
Опять же, идёт оценка рисков, которая и показывает, до какого уровня в каждом конкретном случае стоит доходить в дополнение к базовым практикам. «Дыры», в смысле программных ошибок, могут учитываться как фактор оценки рисков, но в данном случае не было «дыры», насколько можно судить. Было нарушение базовых наилучших практик, и, вероятно, отсутствие регламента при настройке sensitive систем.khim
04.09.2018 23:40Было нарушение базовых наилучших практик, и, вероятно, отсутствие регламента при настройке sensitive систем.
Это не было «sensitive» системой. Обычные двери в офисе. Их в офисе Гугла может быть не одна сотня. И да, они физически в отдельной сети, но для обхода этой проблемы применяется уже обычный (и неуничтожимый) «social engineering». Отсюда, собственно, и уверенность в том, что никто этим не воспользовался…VitalKoshalew
05.09.2018 04:31Не понимаю, как по-вашему команды системы СКУД могут быть не sensitive. Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Что касается сегментации, насколько я помню, изначально в статье на Хабре было написано про «программиста», который в общей сети IoT эти контроллеры увидел и трафик с них разбирал. Сейчас статья подкорректирована, «программист» превратился в «специалиста по компьютерной безопасности», а если заглянуть в первоисточник, то предлагаемый вектор атаки — включение MiTM в патч-панель, которая доступна только местным электрикам и связистам (что тоже не совсем хорошая практика, если нет запрета таким контракторам работать без надзора). Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
На англоязычных ресурсах есть практика, когда об изменениях в статье пишут внизу приписку, мол, то-то и то-то было исправлено. Комментарий на Хабре изменять можно только первые 5 минут, а саму статью можно незаметно править хоть через год, а ведь после этого комментарии теряют актуальность!Tangeman
05.09.2018 16:54+1Не понимаю, как по-вашему команды системы СКУД могут быть не sensitive. Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Замки ставят даже на комнатки для уборщиков и кухни, где нет абсолютно ничего sensitive.
Я подозреваю что там действительно нет ничего настолько важного чтобы заморачиваться драконовскими методами защиты — то есть при установке риск был оценен как «низкий», со всеми вытекающими. Но разумеется, когда обнаружилась «дыра», это нельзя было просто так оставлять.
Самая банальная причина, кстати — это просто учёт кто куда и когда ходит, для статистики.
Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
Зачем устраиваться? Заплатить уже действующему работнику (или шантажировать его), и всех делов. Для особо продвинутых — подменить его кем-то своим в нужный момент (да, это бывает и в реальной жизни, а не только в фильмах). Впрочем, это всё будет иметь смысл только если там (за дверями) реально что-то исключительно важное, иначе игра не стоит свеч.balamutang
05.09.2018 17:46то что замки ставят на каморки уборщиков не значит что такие же замки не ставят на серверные, вряд ли там эксплуатируется несколько разных систем вместо одной «мегабезопасной». итого мы получаем уже дыру не только в никому ненужную комнату уборщика, но и в серверную/машинный зал и прочие чувствительные места, да хоть в комнаты для совещаний — для установки жучков.
khim
05.09.2018 21:41то что замки ставят на каморки уборщиков не значит что такие же замки не ставят на серверные, вряд ли там эксплуатируется несколько разных систем вместо одной «мегабезопасной».
Зависит от того, какая серверная. Для доступа к тем серверам, где данные пользователей хранятся, точно нужен другой бейдж другой системы. Всякие локальные сервера — по общему, но с дополнительными правами.
да хоть в комнаты для совещаний — для установки жучков.
Комнаты для совещений тоже пару уровней имеют. В частности совсем большие, куда иногда сотни партнёров приходят, считаются «небезопасными» по умолчанию.
khim
05.09.2018 21:36Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Затем, что если бомжи зайдут и унесут несколько компов — это уже убыток. Но с учётом того, что все данные на всех компьютерах зашифрованы и для расшифровки нужен ещё и аппаратный ключ… всё не так плохо.
Места, где можно найти что-то сильно «вкусное» (какие-ниудь новые железяки, которые не зашифруешь и прочее) — физически в отлельном здании. С более жёсткой системой охраны всех этих свитчей, в частности.
Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
Можно не устраиваться на работу, а одеться в спецодежду и найти местео, где что-то монтрируется (когда у вас порядка 100 зданий на кампусе, то где-нибудь что-нибудь монтируется почти всегда).
Вообще у Гугла есть команда, которая оценивает вероятности подобных взломов. Флешки всякие подкидывают, лампы с питанием от USB и секретом и прочее. Они как-то делали презентацию. Краткое содержание: мы сделали 100500 атак и в довольно большой части случаев (больше половины) нас поймали — но, тем не менее, XX% атак были успешными. Однако кроме нас служба безопасности не поймала никого, кто смог бы пройти дальше самого первого «уровня обороны» (собственно вот те самые двери, которые можно обойти известным способом). Возможностей две:
1. Китайские террористы гораздо более умные, чем наша команда.
2. Возможно людей, пытающихся вломиться на кампус реально нет, а ломают где-то в других местах.
BalinTomsk
04.09.2018 21:23Из всех моих интервью я два раза заходил в компании, минуя секурити и закрытые двери.
Просто так оказалось, что я входил в тот момент когда из нее кто-то выходил.
И оба раза это были компании, занимавшиеся криптографией. После моего входа в
компании начинался грандиозный шухер.
Мораль — какие криптозамки не навешаешь — социальную составляющую никак не отменишь.Wizard_of_light
04.09.2018 21:33Ну блин. Такое даже в некоторых простых московских подъездах не прокатит — тамбур с двумя дверями и окошком в караулку. Не для хайлоада, конечно, решение, но такие простые трюки как «пятеро по одному пропуску» и «один вышел трое зашло» уже не прокатывают.
khim
04.09.2018 23:44Если у вас «тамбур с двумя дверями и окошком в караулку», то вам нафиг не нужны «умные» двери. Их применяют, когда у вас десяток входов-выходов в здание и ещё внутри на каждом этаже по десятку. Потому что это удобно. Гугл — не «зона», с вышками и колючей проволокой, а кампус, где десятки домиков разбросаны по Mountain View (хотя бы на Street View посмотрите). Держать сотни оранников в караулках — слишком накладно.
Wizard_of_light
05.09.2018 10:07Ну так комментарий-то был не про Гугл, а про какие-то конторы, занимающиеся криптографией, у которых одна эта смарт-дверь по ходу прикрывает все секреты.
OnelaW
05.09.2018 12:59Эка невидаль. Я с гостевой карточкой по всему зданию прошелся, многие офисы открывались.
Был я на деловой встрече у безопасников. Видеть их взгляд бесценно.
saipr
04.09.2018 21:23
Прочитав статью, я вспомнил как в далеких 90-х мы интегрировали системы контроля доступа (СКД) с системами защиты от несанкционирванного доступа (НСД) к компьютерам. Системы мы тогда назвали "Броня-ОТМ" — Система контроля несанкционированного доступа к компьютеру, совмещенная с системой контроля доступа в помещения "Броня-ОТМ". Система хорошо работала: вышел через турникет, не выключив компьютер, он автоматически выключался (и в БД все заносилось), пробрался на рабочее место минуя СКД — компьютер не загрузишь:
TimsTims
05.09.2018 14:52Система хорошо работала: вышел через турникет, не выключив компьютер, он автоматически выключался
Но ведь остаётся еще кучка кейсов, когда за компьютер может сесть злоумышленник. Ваш кейс предполагает, что злоумышленник знает пароль от компьютера (т.к. компьютер не загрузишь). Это значит, что как только сотрудник отошёл за кофе или на кухню злоумышленние уже взломал его комп.
И опять-же утверждение Система хорошо работала напрямую зависит от количества предотвращенных и нет атак :)saipr
05.09.2018 21:35как только сотрудник отошёл за кофе или на кухню злоумышленние уже взломал его комп.
Если сотрудник отошел за кофе или на кухню через турникет, то его компьютер автоматически выключится или заблокируется (как настроить систему), если он этого сам не сделал
Ваш кейс предполагает, что злоумышленник знает пароль от компьютера (т.к. компьютер не загрузишь).
Это откудово такой вывод? Зачем ему пароль, он и без него справится
Lazytech
05.09.2018 07:26+1В июле этого месяца некий хакер смог найти уязвимость в системе управления автоматическими дверями офиса 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.
(подчеркивание мое)Lazytech
05.09.2018 08:11P.S. Поправка: похоже, речь идет об июле этого года.
Lazytech
05.09.2018 09:43P.P.S. Я задал вопрос насчет Last July на известном международном сайте переводчиков:
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.
Иначе получается, что Дэвид прождал целый год, прежде чем поделиться своими изысканиями с другими хакерами. :)
Возможно, кто-нибудь предложит другое объяснение?Lazytech
05.09.2018 11:01+1P.P.P.S. Меня убедили в том, что речь, скорее всего, идет об июле прошлого года. Вот один из веских доводов: поскольку Дэвид работает в Google, он должен был дать своему работодателю достаточное время для устранения проблемы, прежде чем рассказать о ней на хакерской конференции.
balamutang
05.09.2018 13:26ну так себе хак конечно. все равно что говорить о взломе компьютера при наличии физического доступа.
СКУД должен быть вынесен в отдельную подсеть/вилан, физического доступа к езернету СКУДа быть не должно.
а так помоему продолжает нагнетаться тенденция шифрования end2end, потому что если не имеем доверия к своей локалке, то других вариантов безопасной коммуникации у устройств нет.
Это в свою очередь на порядки поднимет требования и соттв стоимость конечных устройств, потому как устройство теперь должно не только уметь езернет и tcp/ip, но и поднять по этому tcp/ip свой шифрованный протокол, при этом иметь стабильность работы на уровне cisco, тк это потребуется как минимум для соблюдения той же пожарной безопасности (например «зависший» замок не выпустит людей в нужный момент), не говоря уж о дискомфорте при «зависшей» двери в обычных ситуациях.khim
05.09.2018 21:50а так помоему продолжает нагнетаться тенденция шифрования end2end, потому что если не имеем доверия к своей локалке, то других вариантов безопасной коммуникации у устройств нет.
Дык собственно это всё со Сноудена началось. Когда выяснилось что никто сеть Гугла не взламывал, а просто роутер подменили у провайдеров, сдающих в аренду оптику — а поскольку Гугл доверял «своей локалке» и ничего «внутри» не шифровал… то и всё.
например «зависший» замок не выпустит людей в нужный момент
Нет, тут всё просто: если ваше здание так устроено, что из него при «зависшем» замке не выйти, то никакой пожарник вам на это «добро» не даст. Больгинство дверей открываются наружу просто кнопкой, а там где нужна повышенная безопасность есть красная аварийная кнопка под стеклом (это плюс к тому, что замки обесточивается, то они открываются — так-то они от UPS'ов питаются, чтобы всё-таки безопасность какая-то была, но если кабель перегорит, то… выйти можно будет).
Lazytech
05.09.2018 14:12Один из участников темы, ссылку на которую я добавил выше, указал на следующую техническую информацию:
NVD — CVE-2017-17704
Возможно, кому-нибудь пригодится.
tvr
HTTP->HTTPS.
IoT->IoT
S?Aquahawk
Буква S в IoT обозначает Security
KodyWiremane
Если на IoST надежды мало, нужен SIoT x)
Разработал бы кто-нибудь коммуникационный фреймворк для умных вещей: адаптеры (проводные/беспроводные), какие-нибудь микроплаты с чипом, со стандартным проводным интерфейсом, которые можно объединить в безопасную сетку, настроить доступ, там, облако — а через стандартный интерфейс к ним подсоединяется само умное устройство. Т. е. безопасная коммуникация стандартизирована, а дальше уже функционал реализуется конкретными железками
Berkof
Это называется TLS и железку ради этого никто ставить не будет, тем более для физической защиты нужно эту железку-интерфейс в устройство как можно глубже запихать и эпоксидкой залить.
KodyWiremane
Будет, если это даст преимущества. TLS — это протокол, который иногда меняется, соответственно, меняется реализация, надо писать новые прошивки для умных устройств, кто-то должен их перепрошить, ну и тут кто во что горазд. С «SIoT Framework» производитель адаптеров максимально концентрируется на сетевой безопасности, инфраструктуре управления сетью и обновления прошивок, ну и над самими прошивками. Адаптер перепрошивается по сети (с ограничениями доступа, криптоподписью обновлений и т. п.), можно заливать эпоксидкой. В случае отсутствия железных уязвимостей, умная сеть максимально оперативно приводится в безопасное состояние (если обнаружена уязвимость в прошивке). Т. о. коммуникации централизованно, с известной степенью гарантии поддерживаются секьюрными.