leo_sosnine (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
leo_sosnine) wrote2021-11-22 08:46 pm
leo_sosnine) wrote2021-11-22 08:46 pm
Entry tags:
Аналогия data-in-use и data-in-motion
Существуют различные состояния информации в которых она может быть атакована различными способами. Например, два состояния на которые я хотел бы обратить внимание это data-in-use и data-in-motion.
К нынешнему дню data-in-motion хорошо защищена, большинство протоколов перепроложили поверх TLS или они поддерживают нативную аутентификацию и шифрование. И всё это делается ради уменьшения простого риска -- якобы сервис провайдер будет нюхать наши пакеты и копировать себе, чем создаст утечку, а то и подменит важную информацию на лету и изменит смысл пересылаемого сообщения. Классика "Man in the middle".
Ничего подобного в практическом инфобезе не происходит: MITM атаки крайне редки. Случаи практической эксплуатации, допустим, BEAST атаки на TLS равны нулю. Причина номер один этого в том, что хозяева роутеров, лежащих между источником и назначением, в этом особого интереса не видят. И по сей день можно годами, допустим, аутентифицироваться по чистому HTTP через, допустим, формы или базовую, при которых пароль передаётся открытым текстом, и буквально всем будет на это похуй и наш пароль никому не будет нужен. Я проводил такой эксперимент (ну, например, на сервере можно отслеживать факты аутентификации) годами с нулевым результатом.
Таким образом, МИТМ атаки это удел маргинальных сценариев типа "открытая или PSK вай-фай сеть" или комбинации со спуфом сервера.
Тем не менее, кажного тупого инфобезничка в америчке обымет трясунец, если вдруг ему предложить одобрить дизайн приложения, которое обменивается сообщениями в открытом тексте, даже если это всё происходит внутри одного датацентра. "Усё должно быть зашифровано во время передачи", ггг.
При этом абсолютно аналогичные и я бы даже сказал большие по размеру риски для data-in-use в облаках полностью игнорируются и вся проблема спускается на тормозах. Как я уже много раз писал в этом бложеке, если информация обрабатывается в облаках, облачный провайдер не может избавиться от доступа к ней, причём доступа неконтролируемого. Попробуйте на митингах с агитаторами переезда в облака задать простой вопрос -- имеют ли ваши собственные сотрудники и сотрудники Амазона, где вы хостите своё говноподелие, доступ к нашим данным и послушать их бессмысленные заверения в полной зашифрованности и даже доступности технологий Bring Your Own Key. Это всё -- полнейшая туфта, доступ они имеют, доступ неконтролируемый и избавиться от него они не могут. И проверяется это простым вопросом: "...but, for you, in order to process our information, it has to be decrypted first, right? RIGHT, MOTHERFUCKER? ANSWER ME!"
Каким образом это существенно отличается от рисков для состояния data-in-motion в отношении которых все знают, что незашифрованные соединения абсолютно недопустимы в наше время и любой трафик должен быть зашифрован и через TLS? Ну, например, любой икоммерс прямо запрещён, если трафик не зашифрован, через соотв. положения PCI DSS, которые энфорсятся на любого процессора данных кредитных карт. И при этом он же в облаках (причём нередко с многослойным пирогом различных провайдеров от инфраструктуры через платформу до софта) разрешён.
Все эти хуесосы являются сертифицированными специалистами, читают соответствующие книжки и торчат на соответствующих конференциях. Проблема в том, что все эти источники "знаний" оплачиваются теми самыми облачными провайдерами которым не хотелось бы, чтобы эта информация была широко известна.
Это абсолютно неизбежно ведёт к скандалу уровня Сноуден 2.0 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.
К нынешнему дню data-in-motion хорошо защищена, большинство протоколов перепроложили поверх TLS или они поддерживают нативную аутентификацию и шифрование. И всё это делается ради уменьшения простого риска -- якобы сервис провайдер будет нюхать наши пакеты и копировать себе, чем создаст утечку, а то и подменит важную информацию на лету и изменит смысл пересылаемого сообщения. Классика "Man in the middle".
Ничего подобного в практическом инфобезе не происходит: MITM атаки крайне редки. Случаи практической эксплуатации, допустим, BEAST атаки на TLS равны нулю. Причина номер один этого в том, что хозяева роутеров, лежащих между источником и назначением, в этом особого интереса не видят. И по сей день можно годами, допустим, аутентифицироваться по чистому HTTP через, допустим, формы или базовую, при которых пароль передаётся открытым текстом, и буквально всем будет на это похуй и наш пароль никому не будет нужен. Я проводил такой эксперимент (ну, например, на сервере можно отслеживать факты аутентификации) годами с нулевым результатом.
Таким образом, МИТМ атаки это удел маргинальных сценариев типа "открытая или PSK вай-фай сеть" или комбинации со спуфом сервера.
Тем не менее, кажного тупого инфобезничка в америчке обымет трясунец, если вдруг ему предложить одобрить дизайн приложения, которое обменивается сообщениями в открытом тексте, даже если это всё происходит внутри одного датацентра. "Усё должно быть зашифровано во время передачи", ггг.
При этом абсолютно аналогичные и я бы даже сказал большие по размеру риски для data-in-use в облаках полностью игнорируются и вся проблема спускается на тормозах. Как я уже много раз писал в этом бложеке, если информация обрабатывается в облаках, облачный провайдер не может избавиться от доступа к ней, причём доступа неконтролируемого. Попробуйте на митингах с агитаторами переезда в облака задать простой вопрос -- имеют ли ваши собственные сотрудники и сотрудники Амазона, где вы хостите своё говноподелие, доступ к нашим данным и послушать их бессмысленные заверения в полной зашифрованности и даже доступности технологий Bring Your Own Key. Это всё -- полнейшая туфта, доступ они имеют, доступ неконтролируемый и избавиться от него они не могут. И проверяется это простым вопросом: "...but, for you, in order to process our information, it has to be decrypted first, right? RIGHT, MOTHERFUCKER? ANSWER ME!"
Каким образом это существенно отличается от рисков для состояния data-in-motion в отношении которых все знают, что незашифрованные соединения абсолютно недопустимы в наше время и любой трафик должен быть зашифрован и через TLS? Ну, например, любой икоммерс прямо запрещён, если трафик не зашифрован, через соотв. положения PCI DSS, которые энфорсятся на любого процессора данных кредитных карт. И при этом он же в облаках (причём нередко с многослойным пирогом различных провайдеров от инфраструктуры через платформу до софта) разрешён.
Все эти хуесосы являются сертифицированными специалистами, читают соответствующие книжки и торчат на соответствующих конференциях. Проблема в том, что все эти источники "знаний" оплачиваются теми самыми облачными провайдерами которым не хотелось бы, чтобы эта информация была широко известна.
Это абсолютно неизбежно ведёт к скандалу уровня Сноуден 2.0 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.
no subject
no subject
Но, я другом. Что все таки облачный провайдер может "в теории" избавиться от доступа к пользовательской информации.
Вот такая аналогия. Немного перевернем ситуацию. Производители компьютерных игр отдают свои данные в виде игр конечным пользователям, которые заинтереснованы играть в них бесплатно, тиражировать бесплатно, модифицировать бесплатно и так далее. Причем у пользователей полный доступ к железу игровых приставок. Конечно, не на таком легком уровне как у облачных провайдеров с гипервизором и не с такими финансовыми и техническими возможностями как у ЦРУ. Но все-таки можно снять дамп с чипов памяти. Вот он путь к пиратству? На одной приставке сняли дамп, на другой запустили. Нет, так не сработает, память зашифрована, плюс все процессоры на плате в разном состоянии.
Как это организовано с технической точки зрения? AMD произвела процессор, продала Microsoft, Microsoft в контролируемом окружении прожгла на процессоре перемычки ( электронные ), туда записался секретный ключ. В процессе работы игровой приставки этот ключ, не светится ни на диске, ни в памяти. Конечно остается вариант разобрать процессор ( весьма трудоемкий ), чтобы получить значения перемычек, сделать так сказать dump процессора, но он будет стоить миллионы долларов, поэтому, обычно идут путем софтового эксплойта ( иногда совмещают с аппаратным гличем ), эксплуатируют все выше и выше.
Можно аналогичным путем идти и для облачной инфраструктуры. Покупаются процессоры ( возможно в составе платы ), далее они инициализируются на предприятии, потом передаются облачному провайдеру, который их использует в собственном окружении, со своей памятью, дисками, материнскими платами.
Конечно, остается вариант сговора Intel/AMD, c Microsoft/Amazon, но если производителей процессоров пара штук, то облачных провайдеров гораздо больше. И возможно, что китайское или российское облако, не будут идти на поводу ЦРУ, и в то же время не смогут получить пользовательские данные в своих целях.
no subject
Хотя "в теории" это возможно, но уж точно не через шифрование памяти и хранение ключей в кэше, а через homomorphic encryption.
no subject
Я хочу сказать, что проблема давно была осознана производителями всякого железа.
Типа вложишься в разработку, а конкуренты снимут прошивку с готового устройства и будут продавать дешевле. Как раз уход в онлайн частично снял эту проблему, но наработки лет 30 назад были уже. Другое дело, что и процессоры ( для embedded ) тогда снимались послойно кислотой и микроскопом. А сейчас просто ситуация сделала круг, и уход в облачный онлайн уже угроза.
no subject
Не понятно, однако, как это могло бы работать надёжно в принципе, т.к. это, судя по всему, не более чем прокси, в котором слой из которого информацию нужно пиздить (на диске зашифровано и на данный момент атакуется память) сдвигается на 1-2 уровня вглубь.
Но, допустим, ключ шифрования и сама операция шифрования происходят в процессоре и/или кэше, всё это железо тем не менее находится в руках заинтересованного игрока, а значит это вопрос ресурсов расколупать как это работает, вытащить ключи, воссоздать код программно и расшифровать дампы памяти вытащенными ключами. Хотя, не спорю, это существенно сложнее чем как щас просто тупо делать дамп из гипервизора, и, возможно, остановит некоторый процент абьюза.
no subject
Но многое зависит от количества денег вложенных в защиту и количества устройств. Apple же вкладывается в технологии защиты от ремонта, то есть разбирания устройства. В сервачок, можно хоть детектор рентгеновских лучей вставить, если просвечивают, окирпичиваемся, а облачная платформа будет должна денег.
Конечно, это будет уже не совсем облачная платформа, которая подразумевает шаринг аппаратных ресурсов и за счет этого их экономию. Но электричество, охлаждение, гигабиты будут по прежнему разделяться, да и дисковое пространство с памятью можно шарить, не исключаю, что и сервачок с защитой от рентгена будет стандартизован, чтобы каждому конечному пользователю не изобретать велосипед.