Главная » 2015»Октябрь»3 » Безопасность через неясность (англ. Security through obscurity
23:11
Безопасность через неясность (англ. Security through obscurity
Безопасность через неясность (англ. Security through obscurity) — принцип, используемый для обеспечения безопасности в различных сферах деятельности человека. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.
Система, полагающаяся на «безопасность через неясность», может иметь существующие или предполагаемые уязвимости, но её владельцы или разработчики считают, что если недостатки неизвестны, то злоумышленник не сможет их обнаружить. Система может также использовать безопасность через неясность в качестве одного из уровней защиты системы, поскольку дает время разработчикам системы устранить найденную уязвимость, тогда как публичное раскрытие продуктов и версий делает их основной целью для использования обнаруженных уязвимостей в этих продуктах и версиях. Первым шагом злоумышленника обычно является сбор информации: эта задача усложняется при использовании безопасности через неясность.
Приведем аргументы в пользу использования принципа. Несмотря на то, что создание защиты системы, которая опирается исключительно на принцип безопасность через неясность является плохим решением, использование данного принципа с целью сохранения в тайне некоторых деталей системы может являться разумной тактикой в рамках системы многоуровневой защиты. Например, при обнаружении уязвимости системы её создателями, безопасность через неясность может являться временным барьером для злоумышленников, пока не будет устранена данная уязвимость. В этом случае целью использования принципа является снижение в краткосрочной перспективе риска эксплуатации уязвимости в основных компонентах системы.
Рассмотрим компьютерную сеть, которая содержит известную уязвимость. Не имея информации о конкретном устройстве системы, злоумышленник должен решить вопрос использовать данную уязвимость или нет. Если система настроена на обнаружение этой уязвимости, она обнаружит что находится под атакой и может ответить, либо путем блокировки системы, пока администраторы не получат возможность отреагировать, либо путем мониторинга и отслеживания атаки нападающего, либо путем отсоединения злоумышленника. Суть использования принципа в данной ситуации заключается в том, что злоумышленник не может быстро получить необходимую информацию о системе чтобы принять твёрдое решение о соотношении риска быть заблокированным при попытке использования уязвимости и возможного вознаграждения в случае удачной атаки. Также, как следствие отсутствия необходимой информации об устройстве системы, он не может однозначно выбрать ту часть системы, которую надо атаковать в первую очередь.
Ещё одна стратегия использования принципа предусматривает существование двойного слоя уязвимостей, оба из которых держатся в секрете. При этом создатели системы позволяют одной из уязвимостей «утечь». Идея состоит в том, чтобы дать злоумышленнику ложное чувство уверенности, что защита была преодолена и он победил. Например, это может использоваться как часть приманки (рус. аналог термина — «ловля на живца»).
Аргументы против принципа безопасность через неясность восходят к принципу Керкгоффса, выдвинутому в 1883 году Огюстом Керкгоффсом. Этот принцип утверждает, что дизайн криптографической системы не должен требовать секретности и не должен причинять неудобств, если он попадет в руки врага. Разработчики должны считать, что весь дизайн системы безопасности известен нападавшим за исключением криптографических ключей (безопасность криптографической системы находится полностью в криптографическом ключе). В 1940 году Клод Шеннон сформулировал этот принцип, как «враг знает систему».
Чем больше число точек возможной компрометации содержится в системе, тем больше вероятность того, что стратегия нападения на одну из этих точек существует, или будет разработана. Системы, которые содержат секретность структуры или операций, которые также являются точками возможной компрометации, являются менее безопасными, чем аналогичные системы без этих точек, если усилие, необходимое для получения уязвимости в результате раскрытия структуры проекта или метода работы, а также усилие, чтобы использовать эту уязвимость меньше усилий, необходимых для получения секретного ключа. Уровень безопасности системы сводится при этом к усилиям, необходимым для использования этой уязвимости.
Например, если кто-то хранит запасной ключ под ковриком, в случае, если двери заперты снаружи, то он полагается на безопасность через неясность. Теоретическая уязвимость в системе безопасности в том, что кто-то может ворваться в дом, открыв дверь с помощью этого запасного ключа. Кроме того, поскольку грабители часто знают предполагаемые места тайников, владелец дома будет подвергаться большому риску кражи со взломом, скрывая ключ, так как усилие, требуемое для того, чтобы найти ключ, вероятно, будет меньше усилий, необходимых для проникновения (например путем взлома) другим способом, например, через стекло. Хозяин добавил уязвимость — тот факт, что входной ключ хранится под ковриком — в систему, и такую, которую очень легко угадать и эксплуатировать.
В прошлом несколько алгоритмов программного обеспечения или систем со скрытием внутренних деталей видели, как эти внутренние детали становятся достоянием общественности. Случайное раскрытие произошло несколько раз, например, в известном случае GSM конфиденциальная документация касательно шифра была передана в Университет Брэдфорда без наложения обычных требований конфиденциальности. Кроме того, уязвимости были обнаружены и использованы в программном обеспечении даже тогда, когда внутренние детали оставались секретными. Взятые вместе, эти и другие примеры показывают, что сложно или неэффективно держать детали систем и алгоритмов в секрете.
Безопасность через неясность не признаётся подходящим инженерным подходом к обеспечению безопасности системы, так как она противоречит принципу «KISS». Национальный институт стандартов и технологий специально рекомендует использовать безопасность через неясность не более чем в одном документе. Согласно NIST «система безопасности не должна зависеть от секретности реализации или её компонентов».
Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должна использоваться в качестве основной меры безопасности. Это, в лучшем случае, вторичная мера, и раскрытие информации о неясности не должно приводить к компрометации.
Ценность использования принципа при создании открытого или закрытого ПО весьма различна и неоднозначна. Рассмотрим процесс создания открытого ПО. Наиболее часто разработчики более заинтересованы в создании нового кода, чем в анализе уже существующего на наличие уязвимостей. Так как создание открытого ПО является делом добровольцев, в общем случае безопасности уделяется меньше внимания, чем если бы одной из обязанностей автора был бы анализ безопасности программы. С другой стороны, существует Закон Линуса, гласящий, что «при достаточном количестве глаз баги выплывают на поверхность», предполагает повышенную безопасность алгоритмов и протоколов, описание которых опубликовано. Больше людей может просмотреть детали таких алгоритмов, выявить недостатки и раньше их исправить. Сторонники этой точки зрения считают, что частота и тяжесть последствий компрометации будет меньше, чем для закрытого или секретного программного обеспечения. Из всего этого можно заключить, что в случае создания открытого ПО, безопасность напрямую зависит от популярности программы, то есть чем выше популярность, тем больше добровольцев анализируют код программы и тем выше вероятность нахождения уязвимостей в нём. В подтверждение этого приведем пример, что исходный код Linux имеет 0.17 ошибок на тысячу строк исходного кода[3], в то время как закрытое коммерческое ПО в среднем насчитывает 20-30 ошибок на 1000 строк исходного кода.
Что касается закрытого ПО, то при его создании анализу безопасности кода уделяется большое внимание, что повышает надежность системы. С другой стороны, так как количество разработчиков зачастую меньше, чем в случае открытого ПО, уменьшается вероятность обнаружения существующих уязвимостей в программе. К тому же, операторы и разработчики/производители систем, которые полагаются на безопасность через неясность, могут сохранить в тайне тот факт, что в их системе найдена уязвимость, чтобы избежать снижения уверенности в своих услугах или продуктах и, следовательно, избежать снижения его конкурентоспособности, внушив, таким образом, ложную уверенность в безопасности своих продуктов. Были известны случаи, по меньшей мере, 1960-х годов, когда компания задерживала выпуск исправлений и патчей, отдавая приоритет своим корпоративным правилам, а не проблемам или рискам клиентов.
Существует множество примеров безопасности через неясность в продуктах Microsoft. Некоторые из них могут использоваться администраторами систем, некоторые разработчиками ПО. Все они нацелены на уменьшение опасности уязвимости путем сокрытия этой уязвимости. Некоторые из них могут не иметь положительного эффекта, но это не является доказательством того, что безопасность через неясность не работает.
Одним из вариантов использования принципа безопасность через неясность является возможность скрыть буквы дисков в проводнике Windows. Данная процедура часто используется в школьных компьютерных классах, интернет — кафе либо в других местах, где необходимо создать условия, где пользователь мог пользоваться компьютером, но не мог сохранять данные на жесткий диск. Однако стоит заметить, что большинство приложений все равно могут сохранить данные на жесткий диск, что сильно уменьшает ценность данной меры безопасности. Хотя и применившие данную процедуру учреждения утверждают, что она уменьшает объём данных на жестком диске.
Также в Windows часто реализуется метод отключения административных общих сетевых ресурсов (таких как C$, Admin$ и т. д.). Основа идеи в том, что данная процедура должна воспрепятствовать возможности удаленного подключения к компьютеру злоумышленникам. Однако злоумышленник с учётной записью администратора может удаленно подключиться к административным ресурсам. Тем не менее так же, как и в случае с предыдущей процедурой, организации сообщают, что отключение административных ресурсов уменьшает число вредоносных программ в сетях.
Параметр «Разрешить операторам сервера планировать выполнение заданий по расписанию» позволяет создавать расписание заданий пользователям из группы операторов сервера. Но надо учитывать, что операторы серверов могут сделать себя администраторами множеством различных способов, так что запрещать им планировать выполнение заданий по расписанию не имеет большого значения. Однако этот параметр предпочитается многими организациями, так как он позволяет их специалистам быть не администраторами, а операторами, что уменьшает вероятность случайного уничтожения сервера специалистами. Что в действительности дает неплохие выгоды.
Ещё одним примером является переименование учётной записи администратора с относительным идентификатором (RID) 500 на нечто неизвестное, которое часто рекомендуется специалистами по безопасности, а также некоторыми руководствами Microsoft. Смысл этой операции в том, что взломщик не будет знать имя записи настоящего администратора. Минусом в данном способе является то, что учётная запись администратора всегда имеет RID 500 и по RID любой пользователь может узнать имя учётной записи администратора.
Приведем пример использования обфускации. Обфускация — техника, направленная на запутывание исходного или исполняемого кода программы, целью которой является сохранение работоспособности, но такой код будет затруднительно проанализировать.
Обфускация может быть применена как на уровне алгоритма, так и на уровне исходного кода программы и даже на уровне ассемблерного кода. Например, создание запутанного ассемблерного кода может быть достигнуто с помощью использования специальных компиляторов. Такие компиляторы, как правило, заново создают код, используя недокументированные возможности среды исполнения программы. Так же существуют специальные программы, созданные для запутывания кода — обфускаторы.
Некоторые процедуры при обфускации кода программы: изменение таблиц импорта, экспорта и переадресации маскировка оригинальной Entry Point (точка входа в программу) использование полиморфного варианта распаковки
Пример № 1 (На языке C)
Исходный код до обфускации: int COUNT = 100; float TAX_RATE = 0.2; for (int i=0; i<COUNT; i++) { tax[i] = orig_price[i] * TAX_RATE; price[i] = orig_price[i] + tax[i]; }
После обфускации: for (int a=0;a<100;a++){b[a]=c[a]*0.2;d[a]=c[a]+b[a];}
Пример № 2 (На языке Perl)
Исходный код до обфускации: my $filter; if (@pod) { my ($buffd, $buffer) = File::Temp::tempfile (UNLINK => 1); print $buffd ""; print $buffd @pod or die ""; print $buffd close $buffd or die ""; @found = $buffer; $filter = 1; } exit; sub is_tainted { my $arg = shift; my $nada = substr ($arg, 0, 0); # zero-length local $@; # preserve caller's version eval { eval «#» }; return length ($@) != 0; } sub am_taint_checking { my ($k,$v) = each %ENV; return is_tainted ($v); }
Это примеры так называемой высокоуровневой обфускации. Если целью является скрыть вирусный код, то в большинстве случаев используют низкоуровневую обфускацию (с применением команд ассемблера), а также программы для автоматической обфускации, такие как Afx!AVSpoffer, EPProt и PETools.
Вариант базового принципа основан на характеристиках малоизвестных программ, при использовании которых снижается вероятность обнаружения уязвимостей в случайных и автоматических атаках. Этот подход имеет множество названий, и «безопасность посредством меньшинства» является самым распространённым. Также существуют термины «безопасность посредством редкости», «безопасность посредством непопулярности», «безопасность по причине отсутствия интереса». Данный принцип преимущественно встречается в объяснении, почему количество известных уязвимостей, найденное в программе для широкого сегмента рынка, имеет тенденцию быть выше, чем линейная зависимость, предполагаемая долей программы на рынке, но эта доля является фактором в выборе программы для некоторых крупных организаций. Принцип безопасности посредством меньшинства может быть полезен организациям, которые не подвергаются целенаправленным атакам и планируют использование продукта в долгосрочной перспективе. Тем не менее, выявление новых уязвимостей в программе, которая является лидером на рынке, сложнее, чем в менее известных продуктах, так как из-за широкого распространения программы многие уязвимости уже были выявлены, поэтому программа, обладающая большой долей рынка, более подходит для организаций, подвергающихся постоянным атакам. Проблема также осложнена тем фактом, что выявление новых уязвимостей в малоизвестных программах делает всех пользователей этой программы мишенями для атак. Для программ-лидеров на рынке вероятность того, что новые уязвимости в них случайно могут стать мишенью для атак, ещё более высока.
В целом, проблема тесно связана, и в некотором смысле зависит, от принципа, известного как «безопасность за счет разнообразия» — наличия широкого ассортимента малоизвестных программ, очевидно, более разнообразных, чем предложение лидера рынка в любом типе программ, что и снижает риски случайной атаки.
Аргумент в пользу принципа безопасности посредством меньшинства противоречит принципу, наблюдаемому в природе в сценарии «хищник-жертва». В этом сценарии принцип «один в поле не воин» противодействует принципу «безопасность посредством меньшинства». Однако, есть некоторые очень существенные различия между львом, охотящимся на газель и работой автоматизированной системы. Большинство жертв взлома программ отнюдь не является прямой целью для атаки.
Одним из видов принципа безопасности посредством меньшинства является обеспечение безопасности посредством устаревания. В основе этого принципа, например, может лежать использование устаревших сетевых протоколов (например, IPX, а не TCP/IP), что снижает возможность атак из Интернета.
