Перейти к содержимому

Вся активность

Этот поток обновляется автоматически     

  1. Вчера
  2. Да. Если секретность до сих пор оправдана, память не жалеем. А это как раз та самая дыра, про которую я упоминал ранее. Несколько лет назад я рассматривал только замену EEPROM в роботе, но не рассматривал возможности апргейда робота. Но теперь я готов пойти ещё дальше. Цель оправдывает средства. Устанавливаем в робота диск максимально возможного объёма и полностью забиваем его процедурно сгенерированными данными. Во время авторизации запрашиваем чтение из псевдослучайных областей диска и, преобразовав в короткий вид, передаём на сервер.
  3. Но как понять, когда предел, если сам компьютер, собственно, был подменен? при сборке дрона/робота ставить максимальное количество плашек? Если с дроном еще более-менее прозрачно, то что делать с роботом, если туда могли всунуть дополнительный диск для хранения данных уже непосредственно в ПЗУ?
  4. Проксирование tmpfs в память приведёт к другой проблеме, которую воспроизведёт тот же самый трюк, что и с tmpfs. Даём испытуемому задачу заполнить псевдослучайными данными массив близкого к предельному размера, провести с этими данными псевдослучайные манипуляции и сообщить серверу сравнительно короткий ответ. В общем, всё то же самое, что и с tmpfs. Если испытуемый не смог дать ответ, значит отключился в беспамятстве, всё с ним понятно.
  5. хорошо, но какой в этом смысл, если мы можем проксировать tmpfs и хранить файл который запросил сервер в озу, а настоящую еепрому хранить в tmpfs? и не допускать доступа к реальной tmpfs.
  6. Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу.
  7. хорошо, я не вижу подвоха здесь пока что, но как поступать, если злоумышленник будет хранить данные в tmpfs? она не чистится, если был soft reboot. или в конце концов интернет-карта или беспроводная карта.
  8. Например: $ (dd if=/dev/urandom bs=4096 count=1 | gzip | dd > /dev/zero ) 2>&1 | grep bytes 4096 bytes (4,1 kB, 4,0 KiB) copied, 5,6993e-05 s, 71,9 MB/s 4119 bytes (4,1 kB, 4,0 KiB) copied, 4,2526e-05 s, 96,9 MB/s
  9. насколько трудносжимаемым? если злоумышленник достаточно заинтересован, он может переписать оригинальную нагрузку в более оптимальный вид, чтобы осталось место под его код.
  10. Так... я обнаружил новую дыру в защите, но до неё мы еще не дошли. Поэтому продолжаем. Может, ещё что-то интересное обнаружится. Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому EEPROM для хранения оригинального кода не годится.
  11. Мне показалось, что защищающаяся сторона должна хранить где-то код. Но даже так взломщик может тоже хранить оригинальный код у себя на сервере. Проблема вот в чем: злоумышленник может просто взять оригинальный код еепромы, сделать что-то вроде: data = maliciousChunk .. eeprom.get() и потом если проверяющая сторона запрашивает код, мы просто делаем что-то вроде этого: modem.send(serverAddress, eeprom.get():sub(maliciousChunk, #eeprom.get()) P.S Или даже проще, банально разделив полезную нагрузку и потом вычленив gsub'ом modem.send(.., eeprom.get:gsub("|(.+)"))
  12. Тут я не понял. Ты сейчас за какую сторону выступаешь? Я предложил запрашивать у робота текущий код EEPROM, чтобы сравнить его с эталонным. Да, он хранится на нашем сервере. Ты парировал тем, что взломщик может отправить наш оригинальный код. Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера. Или взломщик также хранит наш оригинальный код уже на своём сервере? Я правильно понял?
  13. На зашифрованном сервере, который предварительно мы загрузили безопасно с трюком выше.
  14. Но как провернуть этот трюк с роботами или дронами? Они больше всех уязвимы, т.к. часто работают на общедоступной территории. Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты?
  15. Но кто будет запрашивать? Если запрашивать будет сервер, вроде схемы загрузки по сети (потенциально небезопасная EEPROM -> содержимое -> сервер) тогда это не имеет смысла, т.к взломщик может просто отправить оригинальный код. Первое, что мне пришло в голову - это в целом не давать компьютерам биос, и вставлять еепрому только на этап загрузки системы. Как сказал fingercomp в IRC - просто поставить eeprom в readonly режим, и физически при старте системы просто сверять адреса компонентов. Остальные варианты представить сложно, потому что в основном защита будет строится на обфускации и спагетти-коде.
  16. @BrightYC После вмешательства злоумышленника компьютер не может достоверно диагностировать сам себя. Для этого нужен какой-то эталон. Но эталон, хранящийся внутри компьютера также может быть сломан, поэтому самодиагностика бессмысленна. Да и сама процедура диагностики может быть сломана. Можно лишь что-то выявить с помощью другого, гарантированно защищённого компьютера, опрашивая по сети проверяемый компьютер. Но т.к. взломанный компьютер может подделывать ответы, задача сводится к выявлению лжи и составлению таких вопросов, на которые взломанный компьютер будет вынужден ответить честно.
  17. Fingercomp в IRC уже написал мне об неправильно поставленном вопросе. В общем: убедится в неизменности EEPROM должен сам игрок при включении компьютера, на счет подмены: имеется в виду либо вставка нового компонента, либо подмена окружения, либо изменение самого кода eeprom напрямую (впрочем, eeprom можно установить в readonly, но едва ли это поможет, если подменили физический компонент)
  18. Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM? И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети?
  19. @LeshaInc, о чём так загрустил, что отметился под каждым постом этой темы?
  20. Я когда-то давно пытался исследовать этот вопрос, но абсолютно непробиваемой и при этом удобной защиты у меня не получилось. Есть неудобный, но надёжный параноидальный вариант: не хранить ничего ценного в постоянной памяти робота, а любого перезагруженного робота считать скомпрометированным. Скомпрометированных роботов следует выводить на нейтральную территорию и проверять содержимое EEPROM аппаратным способом. А при обнаружении опасных изменений следует поменять открытые порты во всей системе, а сетевые карты как робота, так и общавшегося с ним планшета разобрать на запчасти. Определить же факт модификации EEPROM не всегда возможно. Возможно, я не прав, но мне кажется, полностью публичное существование такой системы невозможно. Да, на начальном этапе можно и нужно вести публичное обсуждение. Но в конечном итоге каждая система должна будет заиметь свои уникальные секретные особенности, неожиданные для взломщика. Мотивированный взломщик может обойти каждый конкретный известный ему вариант, но вряд ли сможет написать универсальный анализатор кода. Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи. Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик?
  21. Если злоумышленник перехватил все вызовы к периферии, уже ничто не будет секретным. Поэтому секретность уходит на второй план. А на первый выходит определение факта взлома.
  22. а что если сам component.eeprom был подменен физически? нечему проверять checksum. Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника.
  23. Этого недостаточно. Все обращения к периферии могут быть перехвачены злоумышленником.
  24. Думаю можно постоянно чекать чексум EEPROM. Если изменилась - значит EEPROM был подменен. getChecksum():string https://ocdoc.cil.li/component:eeprom
  25. Последняя неделя
  26. Сидя уже 5 час над этой задачей, адекватных решений не пришло в голову. Вопрос таков: каким образом можно обезопасить окружение на уровне компонента EEPROM, например, если нам нужно удостоверится, что текущий component.eeprom не был подменен как и его код? Не думаю, что это может помочь, если злоумышленник достаточно заинтересован во взломе. Какие практики первыми приходят в голову? Обфускация кода/держать EEPROM под подушкой? В irc-канале #oc не нашел ничего интересного по этому поводу, поэтому, предлагаю обсудить здесь.
  27. В одиночной игре я с таким никогда не сталкивался, а вот на сервере - не один раз. В ближайщее время покажу.
  1. Загрузить больше активности
×
×
  • Создать...