Forwarded from Just code IT
SATA передает ваши ключи по радио
Когда кто-то говорит о информационной безопасности, мы часто вспоминаем угрозы, характерные для программного обеспечения: бинарные уязвимости вроде переполнения буфера на стеке, SQL-иньекции, XSS-атаки. Кто-то, вероятно, знаком с теоретическими основами ИБ и может припомнить различные модели дискреционного и мандатного контроля доступа, модели контроля целостности, широко применяемые в современных операционных системах.
Также существуют и угрозы аппаратного уровня, или на стыке между аппаратурой и программным обеспечением. К ним можно отнести уязвимости разного рода в механизмах безопасности, предоставляемых центральным процессором или другими устройствами.
Но есть особый мир угроз, которые в англоязычной литературе называются TEMPEST. Этот род угроз связан с путями утечки конфиденциальных данных через каналы связи, организованные непредусмотренным в системе образом.
Наиболее известный пример атаки такого рода — system bus radio. Это программа, которую можно запустить на макбуке и она начнет вещать песню «У Мэри был барашек» на частоте 1580 kHz (AM). Программа не использует какой-либо предусмотренный производителем канал связи, вместо этого она просто исполняет определенные паттерны инструкций со специально подобранной частотой. Процессор и другие юниты, сидящие на системной шине, работают как антенна, излучая электромагнитные волны. Перехватить такой сигнал можно при помощи SDR-приемника.
Другой пример демонстрирует перехват приватных ключей RSA через наблюдение за электромагнитным излучением ноутбука, выполняющего расшифровку сообщения. Это возможно сделать при помощи достаточно компактного устройства, расположенного в радиусе полуметра от компьютера.
Свежая публикация исследователей демонстрирует, как SATA кабели могут быть использованы для организации утечки через ЭМ-излучение. Правда, в этом варианте злоумышленнику все же приходится произвести проникновение в систему заранее, чтобы запустить злонамеренный код, инициирующий передачу данных.
Долгое время атаки такого рода волновали только спецслужбы и военных, но кажется приходит время, когда и мы с вами можем стать жертвами хорошо подготовленных хакеров.
#digest
Когда кто-то говорит о информационной безопасности, мы часто вспоминаем угрозы, характерные для программного обеспечения: бинарные уязвимости вроде переполнения буфера на стеке, SQL-иньекции, XSS-атаки. Кто-то, вероятно, знаком с теоретическими основами ИБ и может припомнить различные модели дискреционного и мандатного контроля доступа, модели контроля целостности, широко применяемые в современных операционных системах.
Также существуют и угрозы аппаратного уровня, или на стыке между аппаратурой и программным обеспечением. К ним можно отнести уязвимости разного рода в механизмах безопасности, предоставляемых центральным процессором или другими устройствами.
Но есть особый мир угроз, которые в англоязычной литературе называются TEMPEST. Этот род угроз связан с путями утечки конфиденциальных данных через каналы связи, организованные непредусмотренным в системе образом.
Наиболее известный пример атаки такого рода — system bus radio. Это программа, которую можно запустить на макбуке и она начнет вещать песню «У Мэри был барашек» на частоте 1580 kHz (AM). Программа не использует какой-либо предусмотренный производителем канал связи, вместо этого она просто исполняет определенные паттерны инструкций со специально подобранной частотой. Процессор и другие юниты, сидящие на системной шине, работают как антенна, излучая электромагнитные волны. Перехватить такой сигнал можно при помощи SDR-приемника.
Другой пример демонстрирует перехват приватных ключей RSA через наблюдение за электромагнитным излучением ноутбука, выполняющего расшифровку сообщения. Это возможно сделать при помощи достаточно компактного устройства, расположенного в радиусе полуметра от компьютера.
Свежая публикация исследователей демонстрирует, как SATA кабели могут быть использованы для организации утечки через ЭМ-излучение. Правда, в этом варианте злоумышленнику все же приходится произвести проникновение в систему заранее, чтобы запустить злонамеренный код, инициирующий передачу данных.
Долгое время атаки такого рода волновали только спецслужбы и военных, но кажется приходит время, когда и мы с вами можем стать жертвами хорошо подготовленных хакеров.
#digest
Forwarded from Just code IT
Как обезопасить что угодно
Многие привыкли думать, что сферы физической и информационной безопасности — два ортогональных, непохожих мира. Что может быть общего у охранника на входе в офисное здание и модели ролевого контроля доступа? Разве можно сравнивать пункт досмотра пассажиров крупного аэропорта и модуль ядра современного антивирусного пакета?
Репозиторий how-to-secure-anything на гитхабе содержит хорошо организованный дайджест материалов на тему безопасности. Здесь можно отыскать информацию про базовые понятия информационной безопасности, моделирование угроз, концепцию secure by design, методы поиска уязвимостей, популярные методы защиты информации и даже документы, описывающие стандартны проектирования тюрем! По каждой теме есть краткие заметки от автора, упрощающие погружение в эту интересную и непростую область.
Если задуматься, то многие достижения в ИБ проистекают из докомпьютерной эпохи, правил документооборота в организациях, обрабатывающих грифованную информацию, военных ведомств, и т.п. Поэтому архитектура современной безопасной информационной системы вполне может напоминать устройство хорошо спроектированной атомной электростанции или крупной организации с четкой иерархией ролей и прав.
#digest
Многие привыкли думать, что сферы физической и информационной безопасности — два ортогональных, непохожих мира. Что может быть общего у охранника на входе в офисное здание и модели ролевого контроля доступа? Разве можно сравнивать пункт досмотра пассажиров крупного аэропорта и модуль ядра современного антивирусного пакета?
Репозиторий how-to-secure-anything на гитхабе содержит хорошо организованный дайджест материалов на тему безопасности. Здесь можно отыскать информацию про базовые понятия информационной безопасности, моделирование угроз, концепцию secure by design, методы поиска уязвимостей, популярные методы защиты информации и даже документы, описывающие стандартны проектирования тюрем! По каждой теме есть краткие заметки от автора, упрощающие погружение в эту интересную и непростую область.
Если задуматься, то многие достижения в ИБ проистекают из докомпьютерной эпохи, правил документооборота в организациях, обрабатывающих грифованную информацию, военных ведомств, и т.п. Поэтому архитектура современной безопасной информационной системы вполне может напоминать устройство хорошо спроектированной атомной электростанции или крупной организации с четкой иерархией ролей и прав.
#digest
GitHub
GitHub - veeral-patel/how-to-secure-anything: How to systematically secure anything: a repository about security engineering
How to systematically secure anything: a repository about security engineering - veeral-patel/how-to-secure-anything
Forwarded from Just code IT
Казалось бы, в наше время ручное шифрование годится разве что для музеев, поскольку такие шифры, как правило, очень просты и легко поддаются взлому. Однако существует алгоритм LC4 (ElsieFour) – lowtech потоковый шифр, который достаточно трудно взломать.
Он позволяет шифровать и расшифровывать сообщения без какого-либо вычислительного устройства, используя только ручку и бумагу. Более того, LC4 можно использовать не только для шифрования сообщения, но и для аутентификации отправителя.
Упростить шифрование и дешифрование можно при помощи специального набора фишек, которые легко изготовить из обычной фанеры. Подробности смотрите в статье по ссылке выше.
#digest
Он позволяет шифровать и расшифровывать сообщения без какого-либо вычислительного устройства, используя только ручку и бумагу. Более того, LC4 можно использовать не только для шифрования сообщения, но и для аутентификации отправителя.
Упростить шифрование и дешифрование можно при помощи специального набора фишек, которые легко изготовить из обычной фанеры. Подробности смотрите в статье по ссылке выше.
#digest
Forwarded from Just code IT
Рохус Келлер (Rochus Keller) — программист, создающий свои собственные среды разработки для олдскульных языков программирования. У него много проектов на GitHub, большинство из которых имеют три общие черты:
1. Они используют байт-код LuaJIT в качестве целевого языка
2. Они включают в себя не только компиляторы, но и полнофункциональные IDE с отладчиками
3. Они написаны на C++ с использованием Qt.
Рохус создал такие среды разработки для Smalltalk-80, Simula, Som, Algol-60 и Oberon+. Последний представляет собой язык программирования, подобный Oberon, совместимый с Oberon, Oberon II, Oberon 07, и расширенный некоторыми новыми возможностями, такими как UTF-8, generics и FFI.
Также, в компиляторе Oberon+ Рохус реализовал бэкенд для Mono и рекомендует использовать его по умолчанию вместо LuaJIT.
#digest
1. Они используют байт-код LuaJIT в качестве целевого языка
2. Они включают в себя не только компиляторы, но и полнофункциональные IDE с отладчиками
3. Они написаны на C++ с использованием Qt.
Рохус создал такие среды разработки для Smalltalk-80, Simula, Som, Algol-60 и Oberon+. Последний представляет собой язык программирования, подобный Oberon, совместимый с Oberon, Oberon II, Oberon 07, и расширенный некоторыми новыми возможностями, такими как UTF-8, generics и FFI.
Также, в компиляторе Oberon+ Рохус реализовал бэкенд для Mono и рекомендует использовать его по умолчанию вместо LuaJIT.
#digest
GitHub
rochus-keller - Overview
see http://rochus-keller.ch. rochus-keller has 76 repositories available. Follow their code on GitHub.
Forwarded from Just code IT
Как компьютерная графика подняла сетевой протокол
Один из наших авторов однажды участвовал в проекте, в котором надо было передавать по Wi-Fi видеопоток в DVD-качестве (5-7 мегабит) с устройства, которое не являлось точкой доступа, сразу на несколько принимающих PC.
А надо сказать, в стандартном Wi-Fi все ходит через точку доступа. То есть любой пакет от станции к станции занимает эфир два раза. Вдобавок Wi-Fi был старомодный, 54 мегабита, что с учетом всех зазоров между пакетами давало где-то 22 реальных мегабита по TCP между станцией и точкой доступа, или половину этого между двумя станциями (автор, конечно, использовал UDP, но цифры по TCP уместны для оценки).
В общем, пришлось изобретать метод, как передавать данные между станциями напрямую, минуя точку доступа ни ничего при этом не ломая. Как следствие, пришлось изобретать механизм подбора оптимальной скорости модуляции.
Допустим, можно среди пакетов, которые передаются на выбранной скорости, подмешать некоторое количество пробных пакетов на других скоростях, посчитать по ним статистику и выбрать скорость, которая кажется наиболее многообещающей, с учетом теоретической скорости доставки и статистики потерь.
Но как среди N пакетов послать M пробных, более-менее равномерно размазав их среди общего потока?
Для этой цели автор применил графический алгоритм Брезенхема, рисующий линии на дискретном экране: мысленно рисуем диагональ прямоугольничка NxM и там, где линия меняет высоту, вставляем пробный пакет.
Так, графический алгоритм, придуманный для рисования на экране прямых, нашел свое применение в сетевом протоколе :)
#digest
Один из наших авторов однажды участвовал в проекте, в котором надо было передавать по Wi-Fi видеопоток в DVD-качестве (5-7 мегабит) с устройства, которое не являлось точкой доступа, сразу на несколько принимающих PC.
А надо сказать, в стандартном Wi-Fi все ходит через точку доступа. То есть любой пакет от станции к станции занимает эфир два раза. Вдобавок Wi-Fi был старомодный, 54 мегабита, что с учетом всех зазоров между пакетами давало где-то 22 реальных мегабита по TCP между станцией и точкой доступа, или половину этого между двумя станциями (автор, конечно, использовал UDP, но цифры по TCP уместны для оценки).
В общем, пришлось изобретать метод, как передавать данные между станциями напрямую, минуя точку доступа ни ничего при этом не ломая. Как следствие, пришлось изобретать механизм подбора оптимальной скорости модуляции.
Допустим, можно среди пакетов, которые передаются на выбранной скорости, подмешать некоторое количество пробных пакетов на других скоростях, посчитать по ним статистику и выбрать скорость, которая кажется наиболее многообещающей, с учетом теоретической скорости доставки и статистики потерь.
Но как среди N пакетов послать M пробных, более-менее равномерно размазав их среди общего потока?
Для этой цели автор применил графический алгоритм Брезенхема, рисующий линии на дискретном экране: мысленно рисуем диагональ прямоугольничка NxM и там, где линия меняет высоту, вставляем пробный пакет.
Так, графический алгоритм, придуманный для рисования на экране прямых, нашел свое применение в сетевом протоколе :)
#digest
Forwarded from Just code IT
Не искушайтесь аудит-логами
На многих системах во имя безопасности появляется сущность аудит-лога. Аудит-лог предназначен для хранения информации о событиях безопасности (например: «пользователь залогинился», «пользователь 3 раза подряд не смог залогиниться», «пользователь удалил бэкап» и так далее).
Аудит-лог, как правило, сделан добротно и аттестован всеми аттестатами. И тут возникает искушение писать в него не только события безопасности, но и общесистемные события, которые кажутся важными (к примеру, когда пофейлилась аллокация в ядре). Оставим за скобками что важных-как-кажется-событий будет становится больше и решительно осудим такой подход с самого начала.
1. Как правило, у аудит-лога и обычного лога разные настройки конфиденциальности. Обычные логи может читать администратор системы или даже простой пользователь во имя debug-ability и возможности самостоятельно решать часть проблем. Аудит-лог читает только аудитор, так как он содержит сенситивную информацию.
2. Аудит-лог и обычный лог чаще всего имеют разные политики целостности. В обычный лог пишут и обычные приложения, и самые разные части системы. А произвольная запись в аудит-лог должна быть ограничена — только TCB-of-TCB может перезаписать данные. Если вообще может.
3. Аудит-лог и обычный лог имеют разные retention policies. Обычные логи ротируются и обрезаются. Аудит-лог хранится долго, и его ротация – это важное событие, которое благословляется высокими кредами, а иногда сопровождается записью на другой носитель.
Вывод: используйте концепты по прямому назначению и не используйте их всуе. А если хотите переиспользовать концепт вне домена, четко представляйте ограничения в моменте и их будущее развитие.
#digest
На многих системах во имя безопасности появляется сущность аудит-лога. Аудит-лог предназначен для хранения информации о событиях безопасности (например: «пользователь залогинился», «пользователь 3 раза подряд не смог залогиниться», «пользователь удалил бэкап» и так далее).
Аудит-лог, как правило, сделан добротно и аттестован всеми аттестатами. И тут возникает искушение писать в него не только события безопасности, но и общесистемные события, которые кажутся важными (к примеру, когда пофейлилась аллокация в ядре). Оставим за скобками что важных-как-кажется-событий будет становится больше и решительно осудим такой подход с самого начала.
1. Как правило, у аудит-лога и обычного лога разные настройки конфиденциальности. Обычные логи может читать администратор системы или даже простой пользователь во имя debug-ability и возможности самостоятельно решать часть проблем. Аудит-лог читает только аудитор, так как он содержит сенситивную информацию.
2. Аудит-лог и обычный лог чаще всего имеют разные политики целостности. В обычный лог пишут и обычные приложения, и самые разные части системы. А произвольная запись в аудит-лог должна быть ограничена — только TCB-of-TCB может перезаписать данные. Если вообще может.
3. Аудит-лог и обычный лог имеют разные retention policies. Обычные логи ротируются и обрезаются. Аудит-лог хранится долго, и его ротация – это важное событие, которое благословляется высокими кредами, а иногда сопровождается записью на другой носитель.
Вывод: используйте концепты по прямому назначению и не используйте их всуе. А если хотите переиспользовать концепт вне домена, четко представляйте ограничения в моменте и их будущее развитие.
#digest