Капать, капать, капать … Это звук твоего облака?
Это может случиться по-разному. См., Например, эту недавнюю исследовательскую работу под названием «Привет, ты, выйди из моего облака: исследование утечки информации в сторонних вычислительных облаках» . Это приятно читать, особенно если вам интересны побочные каналы (недавно я их нашел в другом контексте ).
В первой части статьи авторы показывают, как получить экземпляр вашего EC2 совместно (т.е. работать в том же гипервизоре) с целевым экземпляром (тот, на который вы хотите шпионить). Как только это будет достигнуто, они описывают атаки по побочным каналам для сбора информации из этой ситуации.
Эта статья заставила меня задуматься. Я заметил, что в нем не упоминается попытка перейти к дисковым блокам и памяти. Я не знаю, если они не пытались или они пытались и потерпели поражение.
Что касается дисковых блоков (наиболее очевидный вектор атаки), Amazon не является пустышкой, а их «запатентованный уровень виртуализации дисков автоматически стирает каждый блок памяти, используемый клиентом, и гарантирует, что данные одного клиента никогда не будут доступны другому», как объясняется в AWS. Белая книга по безопасности . На самом деле они настолько уверены в этом, что даже не потрудились запретить попытки восстановления на основе блоков в клиентском соглашении AWS.(кажется, что они в основном обеспокоены атаками, которые не являются специфическими для сред гипервизора, таких как сканирование портов или сетевая DOS). Я принял это как приглашение для проверки их требований, поэтому я запустил несколько экземпляров Linux / ext3 и Windows / NTFS, подключил к ним пару томов EBS и запустил готовые инструменты для восстановления файлов. Конечно же, ничего не было найдено в / dev / sda2 (пустой 150 ГБ раздел локального хранилища, которое поставляется с каждым экземпляром) или на томах EBS. Они не блефуют.
С другой стороны, в / dev / sda1 было много восстанавливаемых файлов. Вот то, что сканирование Foremost вернуло в двух экземплярах (оба они созданы из общедоступных AMI Fedora).
Первый:
Finish: Tue Sep 1 05:04:52 2009
5640 FILES EXTRACTED
jpg:= 14
gif:= 670
htm:= 1183
exe:= 2
png:= 3771
И второй:
Finish: Wed Sep 2 00:32:16 2009
17236 FILES EXTRACTED
jpg:= 236
gif:= 2313
rif:= 11
htm:= 4886
zip:= 182
exe:= 6
png:= 9594
pdf:= 8
------------------------------------------------------------------
Это блоки в самом AMI, а не блоки, оставленные на томах, на которых был установлен AMI. Другими словами, все экземпляры, созданные из одного и того же AMI, будут обеспечивать одинаковые восстанавливаемые файлы. Диск C: экземпляра Windows также имел несколько восстанавливаемых файлов. Не удивительно, что это были установочные файлы Windows.
Я не вижу в этом недостатка AWS. Они отлично справляются с предоставлением чистых чистых томов, и создатель AMI несет ответственность не снимать восстанавливаемые блоки. Я просто не уверен, что все, кто делает AMI доступными, знают об этом. Мои простые сканирования Foremost, приведенные выше, искали только типы файлов по умолчанию, известные из коробки Foremost . Я подозреваю, что если бы я добавил поддержку файлов .pem (используемых AWS для хранения закрытых ключей), вполне возможно, что несколько таких файлов можно будет восстановить в некоторых общедоступных AMI…
Опять же, спасибо Amazon, но мне также интересно, открывает ли эта функция возможный подход к DOS в AWS: мне не нужно много денег, чтобы создать том EBS объемом 1 ТБ и уничтожить его через несколько секунд. Но для Amazon, это много блоков, чтобы стереть. Интересно, сколько таких мгновенных действий по созданию / удалению на больших томах EBS потребовалось бы, чтобы перевести большой кусок памяти AWS в состояние «недоступен — ожидает очистки»… Предполагается, что они активно стирают все физические блоки. Если вместо этого стирание является виртуальным (их уровень виртуализации возвращает ноль в качестве значения для любого свободного блока, независимо от физического значения блока), тогда эта атака не будет работать. Или, может быть, они отслеживают блоки, которые были написаны, и только стирают их.
Тогда есть оперативная память. Бумага безопасности AWS сообщает нам, что физическое ОЗУ хранится отдельно между экземплярами (предположительно, они не используют раздувание или более амбициозную трансцендентную память Xen ). Но они ничего не говорят о том, что происходит, когда новый экземпляр получает ОЗУ завершенного экземпляра.
Amazon, вероятно, гарантирует, что ОЗУ сбрасывается, как и блоки диска. Но как насчет вашей частной облачной инфраструктуры? Хотя вероятность такой утечки в облаке является наиболее пугающей в сценарии с публичным облаком (любой может воспользоваться ею, чтобы преследовать вас), на практике я подозреваю, что эти векторы атаки в настоящее время гораздо более пригодны для использования в различных «частных облаках». там. И что для многих из этих частных облаков вам не нужно прибегать к экзотическим побочным каналам, описанным в статье «Отстань от моего облака». Амазонка была вокруг блока (не каламбур) несколько раз, но не все частные облачные фреймворки там есть.
Одним из возможных выводов является то, что вы хотите убедиться, что ваш поставщик облачных решений делает больше, чем просто написание сценариев для управления вызовами API гипервизора. Они должны разбираться в инфраструктуре хранения, вычислительной и сетевой инфраструктуры. Под твоим чистым виртуальным миром лежит грязный физический мир. Им нужно знать, как думать о безопасности на системном уровне.
Другое — то, что это в основном проблема для служебных вычислений на основе гипервизора и возможный козырь для более высокого уровня виртуализации, например, PaaS. Атаки, описанные в документе (а также восстановление файлов на основе блоков) не будут работать в Google App Engine. Что означает совместное проживание в мире, где последующие запросы к одному и тому же приложению могут попасть на любую машину (хотя на практике это вряд ли будет так случайно)? Вы не «развернуты» на том же хосте, что и ваша предполагаемая жертва. В лучшем случае вы выполняете несколько запросов, в то время как несколько запросов вашей цели выполняются на одной физической машине. Это намного сложнее использовать. Что еще более важно, поверхность атаки намного более сдержана. Нет прямого доступа к памяти, нет данных планировщика низкого уровня,нет файловой системы… Интерфейс ОС к оборудованию, который эмулирует гипервизор, должен был позволить ОС управлять оборудованием. Интерфейс GAE / SDK, с другой стороны, предназначался для того, чтобы предоставить приложению достаточно возможностей для выполнения его задачи таким образом, чтобы он был максимально удален от оборудования. Конечно, в случае с GAE все еще существует основополагающая физическая реальность, и наверняка будут и некоторые утечки. Но маленькая поверхность атаки делает их намного сложнее в использовании.Но маленькая поверхность атаки делает их намного сложнее в использовании.Но маленькая поверхность атаки делает их намного сложнее в использовании.