Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

Программисты просто не думают о безопасности, или Зачем в кофеварке Wi-Fi

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

Кодить, забыв об опасности

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

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

Непреднамеренный вред

Айзек Азимов сформулировал три закона робототехники, первый из которых гласит: «Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинен вред». Но сам же в романе «Обнаженное солнце» писал и о несовершенстве этих законов: они не защищают от непреднамеренного вреда — если один робот приготовит яд и поставит его в определенное место, а другой просто отнесет стакан с напитком хозяину, не зная о содержимом, вдвоем они вполне могут совершить убийство. Даже несмотря на то, что каждый из них в отдельности имеет фундаментальный запрет на это.

Классический пример такого дуэта в IT — вынос недостаточно защищенного сервиса в публичный интернет. Разработчик, который этот сервис написал, отдавал себе отчет, что тот, возможно, защищен достаточно примитивно, но он также знал, что это внутренний сервис, он находится в относительно безопасной сети, недоступен «снаружи». Проблема в том, что свое знание о возможных проблемах с безопасностью он никому не передал, а в через какое-то время новое задание получил уже другой человек. Например, компания, в которой сервис сделали, начала аутсорсить часть работы, и доступ к системе потребовался работникам извне. И вот уже сервер прощупывают сотни скриптов, ищущих уязвимости, делается brute-force подбор паролей, которые для маленького внутреннего сервиса, скорее всего, простые, наверняка и тестовые аккаунты остались, да и SSH-сервер без секьюрити-патчей за два года.

Кто тут самый виноватый? Здравый смысл подсказывает, что тот, кто выставил сервис в интернет — он не обеспечил его должную защиту. Но ведь он мог и не знать, что там есть аккаунт «admin» с паролем «test» или что по определенному URL разработчик оставил страницу диагностики, которая вообще не защищена паролем. Если бы первый разработчик не экономил на безопасности и делал систему «как для врагов» — может быть, многих проблем можно было бы избежать. Именно поэтому забота о безопасности должна начинаться с первого дня — это то, что называется «security in depth».

О таких вещах задумываются немногие, обычно программисты в своих действиях просто не видят «security implications». Не потому, что они глупые или ленивые, просто им никогда не приходилось иметь с этим дело. Вот аналогия — джуниор написал какой-то фрагмент программы, два дня его вылизывал и тестировал, он уверен, что теперь в нем все идеально. При этом синьору достаточно одного взгляда, чтобы увидеть баг в этом коде. Ему не нужно что-то тестировать и проверять — он просто сразу может сказать: «Вот тут при таких-то условиях оно сломается». Можно сказать, что «нейронная сеть» опытного разработчика гораздо лучше натренирована в этой предметной области и какие-то паттерны он просто «видит». Мгновенно, не задумываясь. При этом тот же самый опытный разработчик сам может в упор не заметить огромную дыру в безопасности, которую он только что создал. Его «нейронная сеть» отлично натренирована, но она натренирована на другие вещи, он просто «не видит» проблему. Если ее показать, он все поймет, часто с полуслова, но сам он уязвимость проморгает.

Существует отдельная дисциплина Threat modeling, которая позволяет прогнозировать угрозы и направления возможной атаки, а также определять ценность данных, которые вы при этом рискуете потерять. Ее можно преподавать не только применительно к IT, но программисты точно должны получать концептуальное представление о ней в базовом комплекте знаний. Также совершенно необходимо, чтобы разработчики знали типичные дырки. Они должны быть в курсе, какими бывают ошибки и как потом за счет них другие люди взламывают системы.

Buffer overflow

Я предполагаю, большинство разработчиков знают, что такое buffer overflow и почему, когда пишешь на языке C, нельзя использовать функции стандартной библиотеки, которые форматируют строчку, не ограничивая ее длину. Просто потому что в сервисе с открытой регистрацией какой-нибудь пользователь попытается создать себе имя такой длины, которая переполнит буфер и заставит процессор выполнять уже не ваши, а его команды. Это тема, казалось бы, заезжена. Об этой проблеме известно десятки лет, но на GitHub и сейчас можно найти какой-нибудь свежий opensource-проект, в котором первой же строчкой будет форматирование текста в не ограниченный по длине буфер, где в качестве параметров используется информация «out of control of the application, т. е. полученная от пользователя.

Мне кажется, индустрия уже потеряла надежду, что разработчики когда-то научатся защищаться от buffer overflow. Поэтому основное движение было в сторону того, чтобы сделать его невозможным — аппаратная защита от выполнения стека или вовсе отсутствие прямого доступа к памяти в высокоуровневых языках. Но хоть язык C неуклонно теряет популярность, он пока силен и по-прежнему почти безальтернативен для встраиваемых устройств и IoT, поскольку на слабенький процессор ничего больше не затолкаешь.

В Java такое слабое место, как buffer overflow, отсутствует как класс. Но каким бы ни был язык, не составляет труда накодить на нем какую-нибудь классическую дыру. Скажем, вроде сервера, возвращающего файл из upload-каталога по его имени, где окажется, что в имени можно передать ../../.. и выйти за пределы upload-каталога. Подобные проблемы известны много лет, и в 2018 году не должно быть ни одной программы, которая позволяет этим воспользоваться. Но они продолжают появляться.

Именно поэтому мне кажется важно обучать разработчиков безопасности. И самое главное, наверное, это как раз рассказывать им об „опасности“» — как обычно взламываются системы. Только с этим набором знаний они начинают видеть проблемы в своем коде.

Опасные связи

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

Никто не волнуется, потому что этими данными люди не дорожат. Кому есть дело до уровня влажности в спальне, наличия накипи в вашей кофеварке, любимой вами температуре воды или времени включения лампочек в гостиной? Но последнее, как минимум, сообщает заинтересованному лицу, когда вы бываете дома. Если темно становится в шесть часов вечера, а свет включается в семь, можно с большой долей вероятности рассчитывать, что до семи вы не появитесь. Недавно был прекрасный скандал с вибраторами, которыми зачем-то можно было управлять через iOS-приложение. Оказалось, обо всех режимах использования они сообщали производителю (разумеется, для улучшения качества сервиса). Вот уж, кажется, информация с очень низкой ценностью, но пользователям такое наблюдение за их привычками категорически не понравилось.

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

Готовность к стандартам, труду и обороне

Здорово, если умная лампочка, которую ты купил, сразу интегрируется с умным домом. Но с большой вероятностью она реализует какой-то запатентованный производителем собственный «стандарт» и работает только со своим приложением. Теоретически тебе бы могло потребоваться десять приложений, чтобы регулировать лампочки от разных производителей. Apple, Google, Amazon пытаются ввести стандартный API для управления домом, при использовании которого тебе вообще не важно, как именно реализовано конкретное устройство. Какое-нибудь приложение от Amazon может управлять любым из них, понять его тип и успешно выполнять функции интерфейса между пользователем и облаком.

В IoT особенно ярко проявляется стремление как можно скорее вывести на рынок новейшее гениальное устройство. Поэтому вопрос стандартов оказывается вторичен — если приложение может управлять устройством, производитель уже счастлив. Позже на него начинают сбоку прикручивать, например, интеграцию с Amazon Alexa, чтобы им можно было управлять голосом. Но это уже пример after thought (мысли вдогонку).

Имплементировать стандарты с самого начала было бы проще, но всегда ли производители в этом заинтересованы? Возможно, некоторые вендоры как раз и хотят, чтобы их устройства отправляли информацию именно в их же собственное облако, откуда они смогут ее извлечь и проанализировать. Например, если компания поставляет термостаты, очень интересно собрать статистику, когда пользователи их включают и выключают, какую температуру считают оптимальной. Это позволит оценить картину по отдельным регионам и выделить основные типы пользователей, которых наверняка окажется немного. Привычный для каждого из них режим можно предлагать вместе с термостатом в виде preset с понятными названиям: «офисный сотрудник», «фрилансер» и т. д. В итоге клиенты смогут сэкономить время, а возможно, и деньги (если preset идет с особым тарифным планом на электричество), просто опознав себя в одном из типов.

Слабое звено

Производители бытовой техники теперь стараются вывести в интернет любой новый прибор. Я с большим удивлением узнал, что микросхема ESP32 (есть еще и более ранние варианты, в том числе ESP8266) стоит меньше доллара. Она позиционируется как «system on chip with integrated Wi-Fi» — в принципе, это маленький процессор со встроенной памятью и Wi-Fi-модулем. Стоит копейки, да и размером тоже с монету. Какой соблазн для производителя микроволновой печи воткнуть в нее такую штуку! А сколько возможностей для утюга!

Никакую определенную цель они могут при этом и не преследовать, скорее, прощупывать почву. Здесь можно вспомнить историю с Apple watch — я практически уверен, что на момент выпуска первого устройства никто не знал, какая из его возможностей выстрелит. Apple бил из дробовика во всех направлениях сразу: и тебе идентификация, и contactless payments, и фичи для спорта — и то, и это, все, что приходит в голову. К третьему Apple watch у них наверное собралась какая-то статистика использования устройства и понимание его пользователей. Поэтому презентация третьей модели уже смотрится гораздо больше как презентация спортивного аксессуара, чем чего-то другого. Думаю, производители бытовой техники делают то же самое, пытаясь посмотреть на реакцию пользователей.

Зачем стиральной машине выход в интернет? Я вижу только один резон: она сможет сама себя диагностировать и сообщить в сервисную службу о том, что скоро сломается. Это, возможно, полезно. Но производитель расскажет о миллионе других несомненно необходимых вещей, которые можно делать с connected стиралкой — конечно же, ее можно дистанционно запустить с телефона (здравствуй, еще одно приложение).

Почему засилье connected (без нужды) устройств — это проблема?

Кофеварка тоже может сходить в интернет, чтобы узнать свежие цены на кофе или курсы валют. И хотя она не может рассказать о тебе слишком многого, кроме, пожалуй, режима владельца, с ней может возникнуть другая проблема: «Цепь настолько крепкая, насколько крепким окажется ее самое слабое звено». Я имею в виду, если ваша кофеварка будет взломана, под ударом окажутся еще 25 ваших unhackable устройств. Тот, кто сумеет взломать любую бытовую технику, подключенную к вашей сети, по большому счету войдет к вам домой и сможет там разгуляться. Такое уже было, правда, не с кофеваркой, а с чайником. Его производитель использовал чип со встроенным Wi-Fi, поддерживавший TELNET с дефолтным паролем. А зайдя в чайник, через пару команд можно было получить Wi-Fi-ключ. В общем и целом, чем больше разных устройств в доме, тем больше того, что называется attack surface — потенциальных мест для атаки.

Например, у какого-то устройства может быть механизм, подразумевающий автоматический трансфер данных конфигурации. Если одно из них выйдет из строя и будет заменено новым, первое просто передаст данные о локальном окружении: ключи, пароли, а новое не нужно будет мучительно конфигурировать. Но, если в это механизме есть дырки, проходящий под окном человек сможет заставить устройство передать эти данные и ему. Проблема в том, что пользователь, как правило, понятия не имеет, на что способно его устройство. У него может быть всего одна кнопка, оно может не уметь ничего умного, и common sense подсказывает нам, что и угрозы оно представлять не должно. А представьте, что оно принимает команды по Bluetooth, и в нем забыли отключить режим диагностики... А всегда ли вы готовы доверять результатам security testing производителей бытовой техники? Да и было ли оно?

Выводы

Вряд ли умные холодильники поработят нас в ближайшее время (за кофеварку не поручусь). Но вот лишиться всех паролей можно по милости самого примитивного датчика, установленного в вашей квартире. Параллельно с проблемой security, существует связанная, но не тождественная ей, проблема privacy. Умные дома наблюдают за своими владельцами, в конце концов сбор информации — одна из основных функций устройств, из которых эти системы состоят. Если данные в итоге оказываются не в тех руках, наблюдение автоматически превращается в шпионаж.

Конечно, пользователь сам решает, нужны ли ему чайник и зубная щетка с выходом в интернет. Но в первую очередь, задумываться о потенциальных угрозах следует тем, кто создает программы. Постоянная оценка возможных угроз на уровне вашего собственного куска работы — не паранойя, а важная часть профессиональной культуры. Во всяком случае, я надеюсь, что она такой станет.

LinkedIn

Лучшие комментарии пропустить

Идеальный программист делает то, что написано в задаче, ни больше, не меньше, не заложили время на security-аудит, не описали требования к сервису — Сами Себе Злобный Буратино!

Неоднократно сталкивался ситуацией, когда внезапно private метод стал public-ом, а валидацию входных параметров никто и не подумал добавить. Хранение паролей в String, а не char[] и прочие детские ошибки. Всем на это пофигу абсолютно.

Хотите безопасно — нанимайте еще отдел специалистов и пишите внятные задачи в JIRA, тогда и поговорим, но не раньше.

83 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

К этому надо бы добавить что нет даже программ.. Есть объекты и можно лишь прочитать-записать свойства объекта и запустить метод.. Инициировать событие снаружи никак не получится.. Тем более создать что-то левое и запустить на выполнение.

Да. Процесс знакомства заключается в согласовании структуры передаваемых данных.

Безопасность это интересная тема, но не для меня. Но, это дело личное. Задумываться приходится. Уверен что за блокчейн тут многие в курсе и рассказывать за него здесь не буду. Я расскажу как я планирую решить вопрос безопасности в своей системе. Я считаю что вообще возможность взлома основана на фиксированном протоколе и все что отправляется и получается считается пакетом двоичных данных. А моей системе нет вообще непонятных данных. Все имеет описание.. Т.е. невозможно в принципе передать что-то не понятное. Общаться данными могут только системы у которых есть согласованное описание того чего передается. С подтверждением версии этого описания. Т.е. при передаче осуществляется анализ типа синтаксиса и семантики передаваемого-принимаемого сообщения. Нет абстрактных данных. Вообще нет. Это нечто типа блокчейна. Только там хэш. А у меня могут общаться только устройства имеющие описания предмета общения. Другими словам для обмена данных необходимо «познакомиться». Иначе никак.. Хочу услышать критику специалистов. Ну, вы поняли. Нет фиксированного протокола есть только правила «знакомства» и по результату становится возможным (или не возможным) общение.

то что у тебя строгий контракт общения компонентов не делает твою систему безопасной

Даже если протокол общения высокого уровня между компонентами информационной системы с математически доказанной безопасностью, уязвимости могут быть на более низком уровне: операционная система, сетевое оборудование, физическое периметр, аппаратное обеспечение, и так далее, все зависит от общей сложности информационной системы.

Очень мудрое замечание. Можно было бы и короче написать-«Уязвимости могут быть!»

Какой вопрос — такой ответ. Успехов.

Надо смотреть на Вашу реализацию. Но и идеальная реализация ломается неочевидными методами как написал Pavel Kryvko ниже. Вот как пример, side channel attacks используются для взлома совершенно защищённых непробиваемых алгоритмов, см. Meltdown/Spectre.

Возьмите простой случай: сравнение plain text паролей. Скорее всего это производится чем-то типа memcmp/strcmp. Поскольку сравнение посимвольное, функция возвращается как только найдено несоответствие очередного байта (ок, сравнение чаще идёт по 32/64-битным интам, опустим эту деталь реализации. Чуть замедляет взлом). Если мы находимся на той же машине и можем следить за другим процессом с точностью до микросекунд, мы можем перебирать префикс пароля и замерять время, которое заняло выполнение функции сравнения пароля, тем самым угадывая по 1 символу пока не найдем его.

Есть легкий нюанс. У меня нет алгоритмов и нет программ. В принципе. Так же нет абстрактной памяти куда можно было б чего-то подсунуть и передать управление. Все находящееся в памяти имеет жесткую структуру (типа «все есть объект». Только реально все имеет единую структуру и размещение. Даже данные. Взаимодействие возможно только тремя способами. Читать и писать свойства, запускать методы (возможно с параметрами) и инициировать события. Из выполняющегося только методы и их нельзя заменить. Адресации двоичной тоже нет. Протокол проверяется на легальность. Т.е. нельзя адресоваться к тому чего нет ну и прочие вещи. Дыры, конечно, могут быть если не предусмотрено программистом при создании класса. Типа запустить метод с критичным параметром или изменить свойство не приводящее к нештатному функционированию объекта.. События не изменяемы. Их всего 16 и это охватывает все, что может произойти с данными.. Семантика заключается в переименовании. Т.е. нет события Key_Press. Есть событие Is_Null или Change_Value того значения свойства которое отвечает за состояние клавиатуры. Реально на них оформляется подписка. Так что события вообще никак не изменишь.

Такое уже было, правда, не с кофеваркой, а с чайником. Его производитель использовал чип со встроенным Wi-Fi, поддерживавший TELNET с дефолтным паролем. А зайдя в чайник, через пару команд можно было получить Wi-Fi-ключ. В общем и целом, чем больше разных устройств в доме, тем больше того, что называется attack surface — потенциальных мест для атаки.

Такое возможно только в том случае, если чайник имеет ПУБЛИЧНЫЙ , а не приватный адрес IP(все равно какой — 4 или 6 )или если с какого-то бодуна порт телнета чайника вытягивается в ДМЗ домашнего роутера. Или если кто-то тихонько подкрался к вашему дому и пытается подключиться к чайнику. Нет. проблема конечно есть, но она совершенно не так серьезна, как вы пишете.

с какого-то бодуна порт телнета чайника вытягивается в ДМЗ домашнего роутера.

Дед, окстись! %) Какое ДМЗ у домохозяйки?

Нет. проблема конечно есть, но она совершенно не так серьезна, как вы пишете.

Ну как тебе сказать. Я очень люблю «умные» дома, одним умникам я вполне наглядно продемонстрировал, как задрать температуру отопления в доме оборудованном их системой до 40С летом, попутно сжигая сотни кубометров газа.

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

Дед, окстись! %) Какое ДМЗ у домохозяйки?

Ну вот и я о чем.
Разговор шел о чайнике, который изначально подключается к домашней вайфай сети 8-) .
И к которому внешний вход возможен только если какой жулик сядет сканировать сетку дома и вычислять какой именно пакет идет от чайника. Или — тот вариант о котором я говорил про ДМЗ, если скажем сын домохозяйки захочет себе чайку удаленно накипятить (ага,дурость, но возможность есть). Или — твой вариант умного дома, де-факто маленькой SDN , где есть общий контроллер, с навешеными на него политиками испльзования домашних девайсов, попав на который ты получишь управление над всем — и над чайником в том числе. Но в этом случае открытый телнет-порт чайника до п..ы, так как управление идет через контроллер и некий пропиетарный порт на чайнике.

Чисто теоретично (у друга спитав). Якщо ви на близькій відстані, то:
1) валите точку доступу флудом (beacon/auth — mdk3 вміє), вона уходить в ребут
2) піднімаєте свою AP з тим же ім’ям але без шифрування. Кавоварка чіпляється до вас, поки справжня AP перезавантажується
3) видаєте кавоварці IP, заходите телнетом і читаєте пароль

Проблемы таки есть, и серьёзные.

Во-первых: IP6 принципиально рассчитан на отказ от NAT и введение варианта типа «получаем /64 на один сегмент, дальше все в нём сами заводятся». При этом у любого чайника постоянный мировой белый адрес. (Можно даже его назвать публичным, с поправкой на файрволл.) Защита делается не NATʼом с приватным адресом, а файрволлом с явными списками того, что постоянно разрешено на вход, плюс динамическими трансляциями (из которых самое сложное это FTP, SIP, etc. hole punching — временное разрешение входящего соединения, описанного в информации уже установленного соединения).

Да, любые реализации IP6 на концептуальном уровне должны иметь такой файрволл в явном виде там, где для IP4 это реализуется в пределах NAT. Но забыть это в каком-то очередном индийском роутере с малайской прошивкой — элементарно.

Кстати, даже в IP4 NAT это необязательно — в простых устройствах часто делают какой-то вариант full cone NAT с логикой переброса входящих соединений на конкретные внутренние хост:порт, но без принципиального запрета — потому что анализировать все протоколы сигнализации — сложно и дорого. Например, исходящее с устройства X на ремотный IP Y — ближайшую минуту любые входящие с IP из блока /24, в который входит Y, безусловно форвардятся на такой же порт на X. Слышал я про устройства с такой логикой, когда VoIP делал...

(Некоторую защиту от этого в IP6 создаёт то, что младшие 64 бита адреса при автоназначении формируются из MAC адреса, который ещё узнать надо — имеем 46 бит с гарантией рандома «в среднем по больнице» на 16-24 из них. Но тут можно сниффить сеть у домонетчика, брать списки клиентов со столь же «защищённых» серверов, управляющих ими... варианты есть)

Во-вторых, устройство, которое делает только исходящие соединения, тоже может быть подвержено бразиллионам разных атак — точно так же, как винда в суперзащищённой сети запускает пришедший по почте nudegirls.mp4.exe, потому что пользователь сказал его запустить. Аналоги для чайника могут быть всех видов, включая прошивки с левого сайта (DNS подделан, проверка подписи сломана), эксплойт через JSON якобы команды стартовать утром сделать кипяток к моменту пробудки хозяев, и так далее...

Времена, когда просто NAT был достаточен для защиты, закончились около 2000 года. Тогда мы стояли на краю пропасти, теперь сделали огромный шаг вперёд (tm).

Про кино «Искусственный интеллект. Доступ неограничен», 2016.

Чи виробник стандартної домашньої кавоварки планує захист її від того, що злодій влізе в хату і фізично її вкраде? А чи є захист від того, що злодій красти її не буде, а просто зробить собі каву і винесе сейф? Чому б не встановити замок або, як мінімум, зчитувач відбитку пальця?
Ні, це не робиться і не буде робитися. Чому? Тому що це виходить за скоуп функціональності для якої цей пристрій був зроблений. Є кавові автомати, які ставляться в публічних місцях і вони захищені від того, аби злодій його виніс чи поламав.
Абсолютно та ж сама фігня з софтом. Є софт який працює на публічних девайсах, які мають необхідний ступінь захисту, є спеціалізований супер-захищений софт з багатофакторною аутентифікацією який спроектований для своїх задач і справляється з ними.
Завжди є можливість, що твій софт зламають, в твою мережу вклиняться або твою кавоварку фізично вкрадуть. Якщо для ваших задач важлива секюрність — робіть її, але пихати її скрізь, «Бо можу» не варто. Як мінімум, це буде призводити до здорожчання розробки, здорожчання підтримки і, як наслідок, здорожчання кінцевого продукту. Кожен девайс, кожна програма на цьому девайсі, має виконувати лише те, для чого створена і мати свою сферу відповідальності, не більше не менше.
Звісно, повністю нехтувати секюрністю не варто, треба зберігати «золоту середину» але дуже упорюватись на цій темі я б не став.

Чому б не встановити замок або, як мінімум, зчитувач відбитку пальця?

Сканер відбитку пальця це не сек’юрність, а її імітація :)

Ну если добавить сканер сетчатки, распознавание голоса, анализ ДНК к отпечатку, то уже неплохо выйдет.

Тому що це виходить за скоуп функціональності для якої цей пристрій був зроблений.

Скоуп дуже простий — якщо чайник від Умань Ентерпрайзіз взламується «на раз», а від Полтава-побутприлад — ні, то це на якусь долю спрацює проти його репутації і продаж. А далі все залежить, наскільки це може бути зкомпенсовано продакт-плейсментом в новому кліпу Сердючки...

Статья хорошая, но не своевременная: пока за безопасность не платят делать её никто не будет

А если за отсутвие ее будут штрафовать? Миллинов эдак 20 евро или 4% оборота? А?

В кофеварке? Тогда она будет стоить дороже.

Нет. Просто не станет компании кот-я делает эту кофеварку и все.

И кофеварки не станет

Ну да. Но судьба кофеварки то фигня. Вы лучше подумайте о судьбе разработчиков той кофеварки. Погуглите например terminated contract with Equifax. Ну и т.д.

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

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

А вы уверены, что автоматический выключатель в чайнике хоть как-то подключен к вайфаю?

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

Это вредительство которое по нутру мелкому жулью. А вот заблокировать подачу электричества в квартиру на счетчике это тема уже сегодня..

Все бы хорошо, но:

Именно поэтому забота о безопасности должна начинаться с первого дня — это то, что называется «security in depth».

Security-in-Depth\Defence-in-Depth эти термины в некоторой литературе и в правду обозначают разные процессы но о том что «безопасность с первого дня» является одним из них нигде не сказано. Эти термины обозначают построение эшелонированной обороны наслаивая разные механизмы безопасности друг на друга, например ASLR, DEP, CFG работая вместе гораздо более эффективно усложняют эксплуатацию чем по отдельности.

Я предполагаю, большинство разработчиков знают, что такое buffer overflow и почему, когда пишешь на языке C, нельзя использовать функции стандартной библиотеки, которые форматируют строчку, не ограничивая ее длину. Просто потому что в сервисе с открытой регистрацией какой-нибудь пользователь попытается создать себе имя такой длины, которая переполнит буфер и заставит процессор выполнять уже не ваши, а его команды.

Первое, переполнения буфера может происходить и без использования небезопасных функций из стандартной библиотеки.
Второе, уязвимости форматирования строки это отдельный класс уязвимостей.
Третье, это проблема не только С.
Четвертое, я бы с удовольствием посмотрел как автор статьи в режиме Blackbox без наличия исходных кодов и бинарников будет писать эксплойт проходящий через ASLR, DEP и другие митигейшн.

Это тема, казалось бы, заезжена. Об этой проблеме известно десятки лет, но на GitHub и сейчас можно найти какой-нибудь свежий opensource-проект, в котором первой же строчкой будет форматирование текста в не ограниченный по длине буфер

Вообще-то проблема как раз в том что буфер ограничен (неожиданно). И если брать классический «Stack-Based Buffer Overflow», то перезапись адреса возврата хранящегося на стеке как раз и происходит по причине того что можно записать данных больше чем выделенный буфер.

В Java такое слабое место, как buffer overflow, отсутствует как класс.

А что делать с Java интерпретатором и компилятором в которых такие уязвимости могут быть ? Достаточно поднять историю эксплуатации браузеров через встроенную Java машину что бы понять что это не отвечает действительности, и программы которые написаны на Java также могут быть подвержены Buffer Overflow потому как уязвимость может находиться в самой Java машине.

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

Вообще-то это, как бы так сказать, даже математически невозможно.

Именно поэтому мне кажется важно обучать разработчиков безопасности. И самое главное, наверное, это как раз рассказывать им об «опасности»" — как обычно взламываются системы. Только с этим набором знаний они начинают видеть проблемы в своем коде.

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

P.S.
Дальше читать не осилил.

шпионаж с помощью умных девайсов? зачем так сложно... самая большая проблема прайвеси это интернет и соц.сети, а точнее информация которую люди о себе выкладывают — сами, совершенно добровольно. кто где зачекинился, кто куда полетел, кто в какое кафе с кем сходил. есть в спецслужбах такое направление — шпионаж из открытых источников. 90% информации о людях и их привычках можно собрать из открытых источников, ничего не взламывая.

Идеальный программист делает то, что написано в задаче, ни больше, не меньше, не заложили время на security-аудит, не описали требования к сервису — Сами Себе Злобный Буратино!

Неоднократно сталкивался ситуацией, когда внезапно private метод стал public-ом, а валидацию входных параметров никто и не подумал добавить. Хранение паролей в String, а не char[] и прочие детские ошибки. Всем на это пофигу абсолютно.

Хотите безопасно — нанимайте еще отдел специалистов и пишите внятные задачи в JIRA, тогда и поговорим, но не раньше.

А в чём существенная разница между хранением паролей в String и char[] или даже byte[] ? Если есть доступ к оперативной памяти, то это как бы вопрос техники как его оттуда выковырять, ну и если посмотрите сорцы String (java) то значение храниться в
private final char value[];
Как бы разницы не вижу акромя что у String можно дёрнуть intern() и тем самым стрельнуть себе в ногу
Пароль желательно не хранить вообще, а хранить его хеш и тот с солью, которую надо добавлять в начало пароля.

Масив чарів можна затерти одразу після того як пароль став непотрібен

А можно и забыть затереть. И в стринге можно, только чуток с рефлекшеном поиграть, так в чём существенное отличие? При условии что у злоумышлиника есть доступ к рабочей jvm (память, debug режим, внедрил свой код), только в том что пароль будет там храниться более короткое время ? Но если я вклинился в код или в дебаг режиме то как бы до затирания можно и не дойти.
Если я звлоред имею доступ к серверу с приложением с правами запуска перезапуска приложения, то вы можете хранить хоть в стринге, хоть в масиве байтов, хоть в масиве char, если будет хоть одно мгновение когда пароль будет в открытом виде, я его выужу, затираете вы его или нет. Тут или предполагаем что зловред доступа к серваку не получит, или не храними не передаём пароли в открытом виде.

И в стринге можно, только чуток с рефлекшеном поиграть, так в чём существенное отличие?

в джаве все настолько плохо?

Хорошо или плохо это понятия относительные, и зависят от наблюдателя.
Но можно, хотя не стандартным способом, а при помощи reflection, при большом желании можно и весь класс подменить.
Field value = String.class.getDeclaredField("value");
value.setAccessible(true);

Field hash = String.class.getDeclaredField("hash");
hash.setAccessible(true);

String s = new String("test");

char[] charArr = (char[]) value.get(s);
charArr[1] = ’o’;
hash.set(s, 0);//для соблюдения контракта, чтоб hashCode пересчитался
System.out.println(s); //tost
А вот как в C# одновременно итерировать по Dictionary и удалять с него элементы, я не нашёл, возможно как то можно нестандартно, но стандартно вроде нельзя.
P.S. Насчёт C# не судите строго, это не мой native language :-) а где то 3-4 по списку из тех что я знаю. Но знаю что java позволяет всё что мне нужно было :-) На этот язык/платформу я матерюсь меньше всего, чего не скажешь о JS и C#

только в том что пароль будет там храниться более короткое время

Саме так. Smallest possible local scope, це стандартна практика, вона існує не тільки в джаві і використовується щоб ускладнити життя «зловрєдам».

використовується щоб ускладнити життя «зловрєдам».

Это переводится как «защита от лоха».
Вопрос: человек который получил доступ к памяти исполняемого процесса очень похож на лоха?
Вот есть у вас пароль в массиве символов. Как он туда попал?
Чтобы такая техника работала, нужно иметь очень обширный контроль надо жизниным циклом сценария (возможно для десктоп приложений или эмбедедов).
Более предсказуемо — захешировать пароль как можно раньше (просто для того чтобы кто-то по ошибке на распечатал его в логи или джсон-ответ) и постараться обеспечить защиту от проникновения в систему на которой запущено приложение.

---
UPD
С JPasswordField в общем понятно, суть в том что инстанс этого класса скорее всего живет куда дольше (пока ворма видна), чем нужны данные в ней. Но это не стандартная практика, а часный случай.
Может я что-то упускаю, тогда поясните, пожалуйста.

согласен

1. при наборе символов, каждый хешировать с префиксом.
2. префикс(тоже хеш) зависит от хеша предыдущего символа, который обрабатывается формулой(можно накрутить что хочеш :) ), для первого символа создать префикс по умолчанию.
3. складываем в массив (можно смешать индексы, опять же формулой)

ну, можно много навыдумывать )

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

Не совсем так
Нужно внедрять методы сурового американского правосудия — сломал зуб о косточку в Вишнёвом пироге — получил миллион баксов компенсации
Иначе прижимистая рука директора не выделит бюджет на безопасность

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

Эх, я бы мог получить миллион...

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

Для начала пусть хотя бы стандарты разные пофиксят. Дыры уже в стандартах забиты жестко.
Вон 4G чего стоит с ее дырами, про WiFi и речи не веду. И это без програмерских и хардварных багов.

Возможно те дыры запланировали АНБ или другие структуры

О да, бери глубже — сионские мудрецы.

Чтоб программист думал про безопасность — ему надо озвучить требования и оплачивать работу

в некоторых компаниях/странах считается, что программист должен думать о безопасности продукта по умолчанию (потому что он ответственен за качество)

И сервера настраивать и картриджи менять. Знаю я эти ваши компании.

вы не путаете программистов из реальной жизни с «тыжпрограммистами» из анекдотов?

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

Чтоб программист думал про безопасность — ему надо озвучить требования и оплачивать работу

1) Какие именно требования нужно озвучить? Или у вас прогаммисты самы придумывают какой функционал должен быть в приложении?
2) Тут на ДОУ есть раздел ЗП, там числа отличаются от нуля.

1) Совмещать работу программиста с специалистом ИБ
2) Доплюсуйте к зряплате программиста ещё и зарплату ИБ

Совмещать работу программиста с специалистом ИБ

Понятно.
Проверять свою работу программист тоже не должен. Организовывать мониторинг системы (логирование, метрики и тд) тоже не должен. Бизнес аналитик — это тоже другая специальность.
А программисты только пишут код.
И тут мы приходим к пункту № 2:

Доплюсуйте к зряплате программиста ещё и зарплату ИБ

Проблема в том что это работник «доплюсовывает». А наниматель считает затраты и он будет отминусовывать ЗП ИБ-специалиста (при том таки специалиста, а не просто чувака который хоть немного думает головой).

---

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

Рабочий продукт и безопасный — разные вещи

Рабочий продукт и безопасный — разные вещи
размышления уровня джуниор

:)

Ага. И чтоб картриджи менял.

А это логика «обиженого эникейщика»

Каждый судит по своей мерке. Если вас в детстве кто-то обидел — так то ваши проблемы.

Каждый судит по своей мерке

Угу, вот почему-то мне не пришла в голову идея про смену картриджей программистом, а кому-то пришла.

В ТЗ, которое програмер делал, были требования?
Если нет, то какие вопросы могут быть. Программист сделал то, что ему сказали.
А вот за отсебятину, когда делают не то, что сказали, надо бить по рукам.

И кстати даже в ГОСТе по составлению ТЗ есть разделы по требованиям к безопасности, надежности, наработке на отказ и т.п. с формулами, как оное оценивать.

В ТЗ, которое програмер делал, были требования?

ТЗ — это способ прикрыть свою Ж, в случае проблем.
В современном мире четких ТЗ не бывает, всегда кто-то чего-то забудет, а что-то (например безопасность системы) будет подразумеваться.
Про ГОСТы может быть аргументов если заказчик/бизнес знает про эти самые ГОСТы. И если бизнесу не важен time to market, ибо конкуретны уже будут штамповать версю 2.0 пока вы будете ТЗ писать.

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

Это нормальная логика джуна: моя работа набирать буквачки так чтобы копмилятор не ругался.

А вот за отсебятину, когда делают не то, что сказали, надо бить по рукам.

И вот тут мы перескакиваем от джуна сразу к синьору:
Делать отсебятину — это не вариант. Но вот возможность уводомить бизнес о доп рисках, типовых решениях — это один из моментов которые отличают синьора от мидла.
В контексте безопасности, опытный разработчик должен имень представление об общих принципах безопасности в своей сфере.

Это нормальная логика джуна: моя работа набирать буквачки так чтобы копмилятор не ругался.

Як недоджун — я категорично не згоден.

Як недоджун — я категорично не згоден

Эсли мы это сказали не для самопиара, то у вас есть шанс стать синьором.

ТЗ — это техническое задание, где написаны требования и правила приемки.

Да уведомлять можно хоть Бога, а менеджмент и заказчик твой решит, что важнее.

Спешу согласиться с Вашей посылом, что от специалиста ожидается допустимый уровень безопасности системы. Однако, а) любой код имеет WTF фактор, и может быть разного уровня безопасности; б) код с низким WTF фактором, и высоким уровнем устойчивости бывает на порядок дороже написать, и в конкретно взятом случае, более простое, но не оптимальное решение для бизнеса выгоднее, и потому выбирается оно. Так что боюсь, что посыл, что каждый разраб должен писать изначально все гипер-безопасное, с учетом всех корнер-кейсов — это утопия. Иногда бизнесу нужно реально на завтра (и о недостатках такого кода овнер должен быть оповещен).

Именно для этого и нужен аудитор кода, который его вычитывает.

Я говорю о «заведомо не идеальном коде» который в конкретном случае может быть оправдан скоростью/простотой/доступностью написания, или же требованиям удобности использования ПО, а не о код-ревью (которые я считаю действительно полезной практикой).

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

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

Даже не мечтайте — за двумя зайцами!

Замачтельно! Вот толко в раельном мире все чуть по другому. Практически все стандарты и фреймворки безопасности настаивают на том что за безопасность сервиса или ПО отвечают... ВСЕ, начиная от СЕО и СТО и заканчиваю джуном-тестировщиком и админом эникейщиком. Именно потому то все стандарты говорят что нужно проводить регулярные тренинги. Но дело не тольк в тренингах. Вот ет программисты кот-е хотят что бы их за ручку водили по тем же стандарам безопасности должны следовать рекоммендациям OWASP/SANS и прочиv inductry best practices. И подход — я тут напишу то за то что мне, как я думаю, деньги платят а вы себе делайте что хотите — не спасет. Бо как только контора попадет на бабки из-за того, что кто-то потянул прод данные в тест и оттуда их потерял иили бабахнул рассылку на реальных пользователе менеджмент быстрой найде кто за это ответит. Особенно весело всем станет после 25 мая 2018 когда окончательно войдет в действие GDPR и утечка скажем адресов пользователя будет стоить 20 млн евро минимум...
Поэтому забудьте «моя хата скарю что хлочу то и пишу» и думайет о безопасности вашего продукта как об одной из важных его фич. И будет вам нирвана и зп :).

смелое заявление — кодер станет спецом в инфобез по щелчку пальцами)

ага, пивоварова или еще какого трубадура айти нации.

Ну может я свои открою. Когда-нибудь.

Без ложной скромности ИТ-безопасность это Процесс, не Состояние. Про нее можно узнать из курсов или книг. Но научит чела только опыт! Сейчас услуги по ИТ-безопасности активно продвигают как аутсорц.

Нет конечно, но даже базовая безопасность (типа не отдать чужие данные по айди) требует времени. Бывает такое что ту или иную фичу требуют на вчера, программер быстро ваяет прототип без проверок, а потом менеджер думает что «та оно ж готово, что там ещё делать», и так можно вполне зарелизить бекенд, который будет отдавать любые данные тому кто хорошо попросит.

Подписаться на комментарии