Security through obscurity
Безопасность через неясность (англ. Security through obscurity) — принцип, используемый для обеспечения безопасности в различных сферах деятельности человека. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.
Система, полагающаяся на «безопасность через неясность», может иметь существующие или предполагаемые уязвимости, но её владельцы или разработчики считают, что если недостатки неизвестны, то злоумышленник не сможет их обнаружить. Система может также использовать безопасность через неясность в качестве одного из уровней защиты системы, поскольку даёт время разработчикам системы устранить найденную уязвимость, тогда как публичное раскрытие продуктов и версий делает их основной целью для использования обнаруженных уязвимостей в этих продуктах и версиях. Первым шагом злоумышленника обычно является сбор информации: эта задача усложняется при использовании безопасности через неясность.
История вопроса[править | править код]
Существующая официальная литература по вопросу о безопасности через неясность довольно скудна. Книги по инженерии безопасности ссылаются на Принцип Керкгоффса от 1883 года, если вообще на что-то ссылаются.
В области права Питер Свайр написал о компромиссе между тем, что «безопасность через неясность — это иллюзия», и мнении военных, что «слухи топят корабли», а также о том, как конкуренция влияет на стимулы к раскрытию информации.
Принцип безопасности через неясность был общепринятым в криптографических работах в дни, когда, по существу, все хорошо информированные криптографы работали на национальные спецслужбы, такие как Агентство национальной безопасности. Теперь криптографы часто работают в университетах, где исследователи публикуют многие или даже все их результаты, и публично тестируют чужие разработки, или в частном секторе, где результаты чаще контролируются патентами и авторскими правами, нежели секретностью, поэтому принцип потерял часть его былой популярности. Например, PGP выпущен в виде исходного кода и обычно считается (при правильном использовании) криптосистемой военного уровня.
Преимущества и недостатки использования принципа[править | править код]
Приведём аргументы в пользу использования принципа. Несмотря на то, что создание защиты системы, которая опирается исключительно на принцип безопасность через неясность, является плохим решением, использование данного принципа с целью сохранения в тайне некоторых деталей системы может являться разумной тактикой в рамках системы многоуровневой защиты. Например, при обнаружении уязвимости системы её создателями безопасность через неясность может являться временным барьером для злоумышленников, пока не будет устранена данная уязвимость. В этом случае целью использования принципа является снижение в краткосрочной перспективе риска эксплуатации уязвимости в основных компонентах системы.
Рассмотрим компьютерную сеть, которая содержит известную уязвимость. Не имея информации о конкретном устройстве системы, злоумышленник должен решить вопрос, использовать данную уязвимость или нет. Если система настроена на обнаружение этой уязвимости, она обнаружит, что находится под атакой и может ответить, либо путём блокировки системы, пока администраторы не получат возможность отреагировать, либо путём мониторинга и отслеживания атаки нападающего, либо путём отсоединения злоумышленника. Суть использования принципа в данной ситуации заключается в том, что злоумышленник не может быстро получить необходимую информацию о системе, чтобы принять твёрдое решение о соотношении риска быть заблокированным при попытке использования уязвимости и возможного вознаграждения в случае удачной атаки. Также, как следствие отсутствия необходимой информации об устройстве системы, он не может однозначно выбрать ту часть системы, которую надо атаковать в первую очередь.
Ещё одна стратегия использования принципа предусматривает существование двойного слоя уязвимостей, оба из которых держатся в секрете. При этом создатели системы позволяют одной из уязвимостей «утечь». Идея состоит в том, чтобы дать злоумышленнику ложное чувство уверенности, что защита была преодолена и он победил. Например, это может использоваться как часть приманки (рус. аналог термина — «ловля на живца»).
Аргументы против принципа безопасность через неясность восходят к принципу Керкгоффса, выдвинутому в 1883 году Огюстом Керкгоффсом. Этот принцип утверждает, что дизайн криптографической системы не должен требовать секретности и не должен причинять неудобств, если он попадёт в руки врага. Разработчики должны считать, что весь дизайн системы безопасности известен нападавшим, за исключением криптографических ключей (безопасность криптографической системы находится полностью в криптографическом ключе). В 1940 году Клод Шеннон сформулировал этот принцип как «враг знает систему».
Чем больше число точек возможной компрометации содержится в системе, тем больше вероятность того, что стратегия нападения на одну из этих точек существует или будет разработана. Системы, которые содержат секретность структуры или операций, которые также являются точками возможной компрометации, являются менее безопасными, чем аналогичные системы без этих точек, если усилие, необходимое для получения уязвимости в результате раскрытия структуры проекта или метода работы, а также усилие, чтобы использовать эту уязвимость, меньше усилий, необходимых для получения секретного ключа. Уровень безопасности системы сводится при этом к усилиям, необходимым для использования этой уязвимости.
Например, если кто-то хранит запасной ключ под ковриком, в случае, если двери заперты снаружи, то он полагается на безопасность через неясность. Теоретическая уязвимость в системе безопасности в том, что кто-то может ворваться в дом, открыв дверь с помощью этого запасного ключа. Кроме того, поскольку грабители часто знают предполагаемые места тайников, владелец дома будет подвергаться большому риску кражи со взломом, скрывая ключ, так как усилие, требуемое для того, чтобы найти ключ, вероятно, будет меньше усилий, необходимых для проникновения (например путём взлома) другим способом, например, через стекло. Хозяин добавил уязвимость — тот факт, что входной ключ хранится под ковриком — в систему, и такую, которую очень легко угадать и эксплуатировать.
В прошлом несколько алгоритмов программного обеспечения или систем со скрытием внутренних деталей видели, как эти внутренние детали становятся достоянием общественности. Случайное раскрытие произошло несколько раз, например, в известном случае GSM конфиденциальная документация касательно шифра была передана в Университет Брэдфорда без наложения обычных требований конфиденциальности[1]. Кроме того, уязвимости были обнаружены и использованы в программном обеспечении даже тогда, когда внутренние детали оставались секретными. Взятые вместе, эти и другие примеры показывают, что сложно или неэффективно держать детали систем и алгоритмов в секрете.
Безопасность через неясность не признаётся подходящим инженерным подходом к обеспечению безопасности системы, так как она противоречит принципу «KISS». Национальный институт стандартов и технологий специально рекомендует использовать безопасность через неясность не более чем в одном документе. Согласно NIST, «система безопасности не должна зависеть от секретности реализации или её компонентов»[2].
Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должен использоваться в качестве основной меры безопасности. Это, в лучшем случае, вторичная мера, и раскрытие информации о неясности не должно приводить к компрометации.
Примеры использования[править | править код]
Различие значения использования принципа в открытом и закрытом программном обеспечении[править | править код]
Ценность использования принципа при создании открытого или закрытого ПО весьма различна и неоднозначна. Рассмотрим процесс создания открытого ПО. Наиболее часто разработчики более заинтересованы в создании нового кода, чем в анализе уже существующего на наличие уязвимостей. Так как создание открытого ПО является делом добровольцев, в общем случае безопасности уделяется меньше внимания, чем если бы одной из обязанностей автора был бы анализ безопасности программы. С другой стороны, существует закон Линуса, гласящий, что «при достаточном количестве глаз баги выплывают на поверхность», предполагает повышенную безопасность алгоритмов и протоколов, описание которых опубликовано. Больше людей может просмотреть детали таких алгоритмов, выявить недостатки и раньше их исправить. Сторонники этой точки зрения считают, что частота и тяжесть последствий компрометации будет меньше, чем для закрытого или секретного программного обеспечения. Из всего этого можно заключить, что в случае создания открытого ПО, безопасность напрямую зависит от популярности программы, то есть чем выше популярность, тем больше добровольцев анализируют код программы и тем выше вероятность нахождения уязвимостей в нём. В подтверждение этого приведём пример, что исходный код Linux имеет 0.17 ошибок на тысячу строк исходного кода[3], в то время как закрытое коммерческое ПО в среднем насчитывает 20-30 ошибок на 1000 строк исходного кода.
Что касается закрытого ПО, то при его создании анализу безопасности кода уделяется большое внимание, что повышает надёжность системы. С другой стороны, так как количество разработчиков зачастую меньше, чем в случае открытого ПО, уменьшается вероятность обнаружения существующих уязвимостей в программе. К тому же, операторы и разработчики/производители систем, которые полагаются на безопасность через неясность, могут сохранить в тайне тот факт, что в их системе найдена уязвимость, чтобы избежать снижения уверенности в своих услугах или продуктах и, следовательно, избежать снижения его конкурентоспособности, внушив, таким образом, ложную уверенность в безопасности своих продуктов. Были известны случаи, по меньшей мере, 1960-х годов, когда компания задерживала выпуск исправлений и патчей, отдавая приоритет своим корпоративным правилам, а не проблемам или рискам клиентов.
История использования принципа в сервисе Skype[4][править | править код]
Инженер-разработчик Шон О`Нил (Sean O`Neil) известен как создатель довольно гибкого криптоалгоритма EnRUPT. Также он известен в узких кругах криптоаналитиков как человек, участвовавший во взломе секретного шифра в RFID-чипах Mifare. Эти чипы лежат в основе транспортных карт, электронных пропусков и других бесконтактных смарт-карт, количество которых по всему миру на сегодняшний день исчисляется миллиардами.
В июле 2010 года в Интернете появилась новость, что Шон О`Нил с группой коллег смог раскрыть исходные коды программ, которые защищают известный сервис IP-телефонии Skype. А точнее, им удалось получить исходные коды проприетарных протоколов шифрования сервиса Skype. В своём блоге Шон О`Нил даёт ссылку на сайт cryptolib.com, где, по его словам, находятся полученные коды.
По их собственному свидетельству, Шон О`Нил и его коллеги по реверс-инжинирингу в действительности занимались проблемами безопасности сервиса Skype на протяжении долгого периода времени. Так как они были специалистами в анализе двоичных кодов, им удалось довольно быстро восстановить программу по двоичным кодам, несмотря на то, что программисты Skype очень интенсивно применяли обфускацию. Именно по причине того, что разработчики Skype интенсивно применяли обфускацию, немногим до этого удавалось восстановить программу по двоичным кодам, а те, кто это смог сделать, не публиковали исходные коды, так как они выглядели устрашающе.
В конечном итоге Шону О`Нилу удалось создать эквивалентный код, во всех основных режимах работающий как Skype, но который написан без использования кода Skype. Хотя создание кода происходило приватно, через несколько недель ему удалось просочиться в Интернет, и он сразу стал инструментом спамеров, которые делали рассылки по каналам сервиса срочных сообщений Skype. Чувствуя ответственность за происходящее, Шон О`Нил решил выложить главный секрет коммуникационного протокола Skype — запутанный обфускацией алгоритм расширения для вектора инициализации шифра RC4. Более конкретно, на сайте cryptolib.com выложена программа на языке C, с помощью которой возможно дешифрование служебного трафика между клиентами Skype и суперузлами системы. Несмотря на то, что для шифрования служебных данных используется поточный метод шифрования RC4, отсутствуют секретные ключи, которые необходимо взламывать. Единственное же, что реально имеется, это постоянное преобразование, которое превращает читаемую информацию в нечитаемую. Смысл этого алгоритма заключался в том, чтобы никакие другие лица не смогли разрабатывать совместимые с Skype приложения, ведь не зная алгоритмов передачи служебных данных, невозможно создать такие приложения. Это была защита для монопольного владения Skype своей системой.
Несмотря на взлом и публикацию, данные действия никак не наносят вред и не раскрывают конфиденциальность сообщений и файлов, которые пересылаются в сервисе Skype между пользователями. Взлом был направлен только на служебный канал, по которому передаются поисковые запросы пользователей, их профили, списки контактов и так далее. Это один из ярких примеров того, что даже большие компании используют в своих продуктах принцип «безопасность через неясность» и что это действие может нанести как огромный материальный урон, так и снижение доверия к продуктам.
Примеры использования принципа в ОС Windows[5][править | править код]
Существует множество примеров безопасности через неясность в продуктах Microsoft. Некоторые из них могут использоваться администраторами систем, некоторые — разработчиками ПО. Все они нацелены на уменьшение опасности уязвимости путём сокрытия этой уязвимости. Некоторые из них могут не иметь положительного эффекта, но это не является доказательством того, что безопасность через неясность не работает.
Одним из вариантов использования принципа «безопасность через неясность» является возможность скрыть буквы дисков в Проводнике Windows. Данная процедура часто используется в школьных компьютерных классах, интернет-кафе либо в других местах, где необходимо создать условия, где пользователь мог пользоваться компьютером, но не мог сохранять данные на жёсткий диск. Однако стоит заметить, что большинство приложений всё равно могут сохранить данные на жёсткий диск, что сильно уменьшает ценность данной меры безопасности.
Также в Windows часто реализуется метод отключения общих административных сетевых ресурсов (таких как C$, Admin$ и т. д.). Основа идеи в том, что данная процедура должна воспрепятствовать возможности удалённого подключения к компьютеру злоумышленникам. Однако злоумышленник с учётной записью администратора может удалённо подключиться к административным ресурсам. Тем не менее так же, как и в случае с предыдущей процедурой, организации сообщают, что отключение административных ресурсов уменьшает число вредоносных программ в сетях.
Параметр «Разрешить операторам сервера планировать выполнение заданий по расписанию» позволяет создавать расписание заданий пользователям из группы операторов сервера. Но надо учитывать, что операторы серверов могут сделать себя администраторами множеством различных способов, так что запрещать им планировать выполнение заданий по расписанию не имеет большого значения. Однако этот параметр предпочитается многими организациями, так как он позволяет их специалистам быть не администраторами, а операторами, что уменьшает вероятность случайного уничтожения сервера специалистами.
Ещё одним примером является переименование учётной записи администратора с относительным идентификатором (RID) 500 на нечто неизвестное, которое часто рекомендуется специалистами по безопасности, а также некоторыми руководствами Microsoft. Смысл этой операции в том, что взломщик не будет знать имя записи настоящего администратора. Минусом в данном способе является то, что учётная запись администратора всегда имеет RID 500 и по RID любой пользователь может узнать имя учётной записи администратора.
Иллюстрация принципа на примере обфускации[6][править | править код]
Приведём пример использования обфускации. Обфускация — техника, направленная на запутывание исходного или исполняемого кода программы, целью которой является сохранение работоспособности, но такой код будет затруднительно проанализировать.
Обфускация может быть применена как на уровне алгоритма, так и на уровне исходного кода программы и даже на уровне ассемблерного кода. Например, создание запутанного ассемблерного кода может быть достигнуто с помощью использования специальных компиляторов. Такие компиляторы, как правило, заново создают код, используя недокументированные возможности среды исполнения программы. Также существуют специальные программы, созданные для запутывания кода — обфускаторы.
Некоторые процедуры при обфускации кода программы:
- изменение таблиц импорта, экспорта и переадресации
- маскировка оригинальной 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);
}
После обфускации:
sub z109276e1f2 { ( my $z4fe8df46b1 = shift ( @_ ) ) ; ( my $zf6f94df7a7 = substr (
$z4fe8df46b1 , (0x1eb9+ 765-0x21b6) , (0×0849+ 1465-0x0e02) ) ) ; local $@ ;
eval { eval ( ( "" ) ) ; } ; return ( ( length ( $@ ) != (0x26d2+ 59-0x270d) ) );
} my ( $z9e5935eea4 ) ; if ( @z6a703c020a ) { ( my ($z5a5fa8125d , $zcc158ad3e0 ) =
File::Temp::tempfile ( "" , (0x196a+ 130-0x19eb) ) ) ; print (
$z5a5fa8125d "" ) ; ( print ( $z5a5fa8125d @z6a703c020a ) or die ( ( ( ( "" . $zcc158ad3e0 ) .
«\x3a\x20» ) . $! ) ) ) ;
print ( $z5a5fa8125d "" ) ; ( close ( $z5a5fa8125d ) or die ( ( ( ( "" ) ) ) ; ( @z8374cc586e =
$zcc158ad3e0 ) ; ( $z9e5935eea4 = (0×1209+ 1039-0×1617) ) ; } exit ; sub z021c43d5f3 { ( my
( $z0f1649f7b5 , $z9e1f91fa38 ) = each ( %ENV ) ) ; return ( z109276e1f2 ( $z9e1f91fa38 ) ) ; }
Это примеры так называемой высокоуровневой обфускации. Если целью является скрыть вирусный код, то в большинстве случаев используют низкоуровневую обфускацию (с применением команд ассемблера), а также программы для автоматической обфускации, такие как Afx!AVSpoffer, EPProt и PETools.
Принцип безопасности посредством меньшинства[править | править код]
Вариант базового принципа основан на характеристиках малоизвестных программ, при использовании которых снижается вероятность обнаружения уязвимостей в случайных и автоматических атаках. Этот подход имеет множество названий, и «безопасность посредством меньшинства» является самым распространённым. Также существуют термины «безопасность посредством редкости», «безопасность посредством непопулярности», «безопасность по причине отсутствия интереса». Данный принцип преимущественно встречается в объяснении, почему количество известных уязвимостей, найденное в программе для широкого сегмента рынка, имеет тенденцию быть выше, чем линейная зависимость, предполагаемая долей программы на рынке, но эта доля является фактором в выборе программы для некоторых крупных организаций. Принцип безопасности посредством меньшинства может быть полезен организациям, которые не подвергаются целенаправленным атакам и планируют использование продукта в долгосрочной перспективе. Тем не менее, выявление новых уязвимостей в программе, которая является лидером на рынке, сложнее, чем в менее известных продуктах, так как из-за широкого распространения программы многие уязвимости уже были выявлены, поэтому программа, обладающая большой долей рынка, более подходит для организаций, подвергающихся постоянным атакам. Проблема также осложнена тем фактом, что выявление новых уязвимостей в малоизвестных программах делает всех пользователей этой программы мишенями для атак. Для программ-лидеров на рынке вероятность того, что новые уязвимости в них случайно могут стать мишенью для атак, ещё более высока.
В целом проблема тесно связана с принципом, известным как «безопасность за счёт разнообразия» — наличия широкого ассортимента малоизвестных программ, очевидно более разнообразных, чем предложение лидера рынка в любом типе программ, что и снижает риски случайной атаки.
Аргумент в пользу принципа безопасности посредством меньшинства противоречит принципу, наблюдаемому в природе в сценарии «хищник-жертва». В этом сценарии принцип «один в поле не воин» противодействует принципу «безопасность посредством меньшинства». Однако, есть некоторые очень существенные различия между, например, львом, охотящимся на газель, и работой автоматизированной системы. Большинство жертв взлома программ отнюдь не является прямой целью для атаки.
Одним из видов принципа безопасности посредством меньшинства является обеспечение безопасности посредством устаревания. В основе этого принципа, например, может лежать использование устаревших сетевых протоколов (например, IPX, а не TCP/IP), что снижает возможность атак из Интернета.
Неудачные примеры использования принципа[править | править код]
- В Москве на Ходынском поле рабочие во время ремонта дороги повредили кабель специальной связи, который не был указан в документации в связи с большой секретностью расположения кабеля. Это хорошая иллюстрация того, что при использовании принципа «безопасность через неясность» безопасность может быть нарушена не только злоумышленником, но даже и случайным человеком[7].
- Многие людиШаблон:Сколько прячут свою личную информацию на серверах в надежде, что если не будет раскрыто то, что информация расположена на сервере, то злоумышленник не сможет её найти (используя скрытую папку, создавая сервер на нестандартном порте, не указывая DNS имя). Однако в настоящее время[когда?] сетевые сканеры легко находят такую информацию и она оказывается в руках злоумышленника[7].
- Существует несколько проблем с использованием URL. Так как данные в URL посылаются при использовании протокола HTTP в открытом виде, то они могут быть легко перехвачены (URL сохранятся в логах браузера, в истории браузера, в логах провайдеров и прокси-серверов и т. д.)[7].
- A5/1, изначально засекреченный шифр для мобильной телефонной системы сотовой связи GSM, стал известен частично за счёт реверс-инжиниринга[1].
- Уязвимости в различных версиях Microsoft Windows, веб-браузера по умолчанию Internet Explorer, его почтового приложения Microsoft Outlook и Outlook Express вызвали во всём мире проблемы, когда компьютерные вирусы, троянские кони или сетевые черви пользовались этими уязвимостями.
- Программное обеспечение маршрутизаторов Cisco случайно стало доступным для свободного подключения в корпоративной сети.
См. также[править | править код]
Ссылки[править | править код]
- ↑ 1,0 1,1 "Безопасность GSM: Реальная или виртуальная?". БАРСУКОВ Вячеслав Сергеевич, кандидат технических наук. Архивировано 5 марта 2016. Дата обращения: 28 апреля 2020.
{{cite web}}: Неизвестный параметр|deadlink=игнорируется (справка)К:Википедия:Ошибки CS1 (неподдерживаемый параметр) - ↑ "Guide to General Server Security" (PDF). National Institute of Standards and Technology. 2008-07. Архивировано (PDF) 9 августа 2017. Дата обращения: 25 ноября 2012.
{{cite web}}: Неизвестный параметр|deadlink=игнорируется (справка)К:Википедия:Ошибки CS1 (неподдерживаемый параметр) - ↑ "Coverity: На 1000 строк исходного кода открытых программ насчитывается 1 дефект". SecurityLab. 2012-02-27. Архивировано 20 июля 2015. Дата обращения: 10 января 2015.
{{cite web}}: Неизвестный параметр|deadlink=игнорируется (справка)К:Википедия:Ошибки CS1 (неподдерживаемый параметр) - ↑ "Кивино гнездо: О "взломе" Skype". КОМПЬЮТЕРРА-ONLINE. 2010-07. Архивировано 12 марта 2012. Дата обращения: 12 декабря 2012.
{{cite web}}: Неизвестный параметр|deadlink=игнорируется (справка)К:Википедия:Ошибки CS1 (неподдерживаемый параметр) - ↑ "Великий спор: безопасность через маскировку". TechNet Magazine. 2008-06. Архивировано 23 января 2013.
- ↑ "Обфускация". Персональный Компьютер. 2008-06. Архивировано 23 января 2013.
- ↑ 7,0 7,1 7,2 "Security through obscurity". Корпоративный блог Граманта.ру. 2010-08. Архивировано 23 января 2013.