Безопасность через неясность

Безопасность через неясность (англ. Security through obscurity) — принцип, используемый для обеспечения безопасности в различных сферах деятельности человека. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.

Введение

Система, полагающаяся на безопасность через неясность, может иметь существующие или предполагаемые уязвимости, но её владельцы или разработчики считают, что если недостатки неизвестны, то злоумышленник не сможет их обнаружить. Система может также использовать безопасность через неясность в качестве одного из уровней защиты системы, поскольку дает время разработчикам системы устранить найденную уязвимость, тогда как публичное раскрытие продуктов и версий делает их основной целью для использования обнаруженных уязвимостей в этих продуктах и версиях. Первым шагом злоумышленника обычно является сбор информации: эта задача усложняется при использовании безопасности через неясность.

Преимущества и недостатки использования принципа

Приведем аргументы в пользу использования принципа. Несмотря на то, что создание защиты системы, которая опирается исключительно на принцип безопасность через неясность является плохим решением, использование данного принципа с целью сохранения в тайне некоторых деталей системы может являться разумной тактикой в рамках системы многоуровневой защиты. Например, при обнаружении уязвимости системы её создателями, безопасность через неясность может являться временным барьером для злоумышленников, пока не будет устранена данная уязвимость. В этом случае целью использования принципа является снижение в краткосрочной перспективе риска эксплуатации уязвимости в основных компонентах системы.

Рассмотрим компьютерную сеть, которая содержит известную уязвимость. Не имея информации о конкретном устройстве системы, злоумышленник должен решить вопрос использовать данную уязвимость или нет. Если система настроена на обнаружение этой уязвимости, она обнаружит что находится под атакой и может ответить, либо путем блокировки системы, пока администраторы не получат возможность отреагировать, либо путем мониторинга и отслеживания атаки нападающего, либо путем отсоединения злоумышленника. Суть использования принципа в данной ситуации заключается в том, что злоумышленник не может быстро получить необходимую информацию о системе чтобы принять твердое решение о соотношении риска быть заблокированным при попытке использования уязвимости и возможного вознаграждения в случае успешной атаки. Также, как следствие отсутствия необходимой информации об устройстве системы, он не может однозначно выбрать ту часть системы, которую надо атаковать в первую очередь.

Ещё одна стратегия использования принципа предусматривает существование двойного слоя уязвимостей, оба из которых держатся в секрете. При этом создатели системы позволяют одной из уязвимостей "утечь". Идея состоит в том, чтобы дать злоумышленнику ложное чувство уверенности, что защита была преодолена и он победил. Например, это может использоваться как часть приманки.

Существует общее мнение, даже среди тех, кто выступает в пользу принципа безопасность через неясность, что данный принцип не должен являться основной мерой защиты системы. Это, в лучшем случае, вторичная мера, и раскрытие информации о неясности не должно приводить к компрометации.

Аргументы против принципа безопасность через неясность восходят к принципу Керкгоффса, выдвинутому в 1883 году Огюстом Керкгоффсом. Этот принцип утверждает, что дизайн криптографической системы не должен требовать секретности и не должен причинять неудобств, если он попадет в руки врага. Разработчики должны считать, что весь дизайн системы безопасности известен нападавшим за исключением криптографических ключей (безопасность криптографической системы находится полностью в криптографическом ключе). В 1940 году Клод Шеннон сформулировал этот принцип, как «враг знает систему».

Чем больше число точек возможной компрометации содержится в системе, тем больше вероятность того, что стратегия нападения на одну из этих точек существует, или будет разработана. Системы, которые содержат секретность структуры или операций, которые также являются точками возможной компрометации, являются менее безопасными, чем аналогичные системы без этих точек, если усилие, необходимое для получения уязвимости в результате раскрытия структуры проекта или метода работы, а также усилие, чтобы использовать эту уязвимость меньше усилий, необходимых для получения секретного ключа. Уровень безопасности системы сводится при этом к усилиям, необходимым для использования этой уязвимости.

Например, если кто-то хранит запасной ключ под ковриком, в случае, если двери заперты снаружи, то он полагается на безопасность через неясность. Теоретическая уязвимость в системе безопасности в том, что кто-то может ворваться в дом, открыв дверь с помощью этого запасного ключа. Кроме того, поскольку грабители часто знают предполагаемые места тайников, владелец дома будет испытывать больший риск кражи со взломом, скрывая ключ, так как усилие, требуемое для того, чтобы найти ключ, вероятно, будет меньше усилий, необходимых для взлома другим способом, например, через стекло. Хозяин добавил уязвимость — тот факт, что входной ключ хранится под ковриком — в систему, и такую, которую очень легко угадать и эксплуатировать.

В прошлом несколько алгоритмов программного обеспечения или систем со скрытием внутренних деталей видели, как эти внутренние детали становятся достоянием общественности. Случайное раскрытие произошло несколько раз, например, в известном случае GSM конфиденциальная документация касательно шифра была передана в Университет Брэдфорда без наложения обычных требований конфиденциальности^[1]. Кроме того, уязвимости были обнаружены и использованы в программном обеспечении даже тогда, когда внутренние детали оставались секретными. Взятые вместе, эти и другие примеры показывают, что сложно или неэффективно держать детали систем и алгоритмов в секрете.

Примеры использования

Различие значения использования принципа в открытом и закрытом программном обеспечении

Ценность использования принципа при создании открытого или закрытого ПО весьма различна и неоднозначна. Рассмотрим процесс создания открытого ПО. Наиболее часто разработчики более заинтересованы в создании нового кода, чем в анализе уже существующего на наличие уязвимостей. Так как создание открытого ПО является делом добровольцев, в общем случае безопасности уделяется меньше внимания, чем если бы одной из обязанностей автора был бы анализ безопасности программы. С другой стороны, существует Закон Линуса, гласящий, что «при достаточном количестве глаз баги выплывают на поверхность», предполагает повышенную безопасность алгоритмов и протоколов, описание которых опубликовано. Больше людей может просмотреть детали таких алгоритмов, выявить недостатки и раньше их исправить. Сторонники этой точки зрения считают, что частота и тяжесть последствий компрометации будет меньше, чем для закрытого или секретного программного обеспечения. Из всего этого можно заключить, что в случае создания открытого ПО, безопасность напрямую зависит от популярности программы, т.е. чем выше популярность, тем больше добровольцев анализируют код программы и тем выше вероятность нахождения уязвимостей в нем. В подтверждение этого приведем пример, что исходный код Linux имеет 0.17 ошибок на тысячу строк исходного кода, в то время как закрытое коммерческое ПО в среднем насчитывает 20-30 ошибок на 1000 строк исходного кода.

Что касается закрытого ПО, то при его создании анализу безопасности кода уделяется большое внимание, что повышает надежность системы. С другой стороны, так как количество разработчиков зачастую меньше, чем в случае открытого ПО, уменьшается вероятность обнаружения существующих уязвимостей в программе. К тому же, операторы и разработчики/производители систем, которые полагаются на безопасность через неясность, могут сохранить в тайне тот факт, что в их системе найдена уязвимость, чтобы избежать снижения уверенности в своих услугах или продуктах и, следовательно, избежать снижения его конкурентоспособности, внушив, таким образом, ложную уверенность в безопасности своих продуктов. Были известны случаи, по меньшей мере, 1960-х годов, когда компания задерживала выпуск исправлений и патчей, отдавая приоритет своим корпоративным правилам, а не проблемам или рискам клиентов.

История использования принципа в сервисе Skype^[2]

Инженер – разработчик Шон О`Нил (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^[3]

Существует множество примеров безопасности через неясность в продуктах Microsoft. Некоторые из них могут использоваться администраторами систем, некоторые разработчиками ПО. Все они нацелены на уменьшение опасности уязвимости путем сокрытия этой уязвимости.Некоторые из них могут не иметь положительного эффекта, но это не является доказательством того, что безопасность через неясность не работает.

Одним из вариантов использования принципа безопасность через неясность является возможность скрыть буквы дисков в проводнике Windows. Данная процедура часто используется в школьных компьютерных классах, интернет – кафе либо в других местах, где необходимо создать условия, где пользователь мог пользоваться компьютером, но не мог сохранять данные на жесткий диск. Однако стоит заметить, что большинство приложений все равно могут сохранить данные на жесткий диск, что сильно уменьшает ценность данной меры безопасности. Хотя и применившие данную процедуру учреждения утверждают, что она уменьшает объем данных на жестком диске.

Так же в Windows часто реализуется метод отключения административных общих сетевых ресурсов (таких как C$, Admin$ и т.д.). Основа идеи в том, что данная процедура должна воспрепятствовать возможности удаленного подключения к компьютеру злоумышленникам. Однако злоумышленник с учетной записью администратора может удаленно подключиться к административным ресурсам. Тем не менее, также как и в случае с предыдущей процедурой, организации сообщают, что отключение административных ресурсов уменьшает число вредоносных программ в сетях.

Параметр «Разрешить операторам сервера планировать выполнение заданий по расписанию» позволяет создавать расписание заданий пользователям из группы операторов сервера. Но надо учитывать, что операторы серверов могут сделать себя администраторами множеством различных способов, так что запрещать им планировать выполнение заданий по расписанию не имеет большого значения. Однако этот параметр предпочитается многими организациями, так как он позволяет их специалистам быть не администраторами, а операторами, что уменьшает вероятность случайного уничтожения сервера специалистами. Что в действительности дает неплохие выгоды.

Еще одним примером является переименование учетной записи администратора с относительным идентификатором (RID) 500 на нечто неизвестное, которое часто рекомендуется специалистами по безопасности, а также некоторыми руководствами Microsoft. Смысл этой операции в том, что взломщик не будет знать имя записи настоящего администратора. Минусом в данном способе является то, что учетная запись администратора всегда имеет RID 500 и по RID любой пользователь может узнать имя учетной записи администратора.

Иллюстрация принципа на примере обфускации^[4]

Приведем пример использования обфускации. Обфускация - техника, направленная на запутывание исходного или исполняемого кода программы, целью которой является сохранение работоспособности, но такой код будет затруднительно проанализировать.

Обфускация может быть применена как на уровне алгоритма, так и на уровне исходного кода программы и даже на уровне ассемблерного кода. Например, создание запутанного ассемблерного кода может быть достигнуто с помощью использования специальных компиляторов. Такие компиляторы, как правило, заново создают код, используя недокументированные возможности среды исполнения программы. Так же существуют специальные программы, созданные для запутывания кода - обфускаторы.

Некоторые процедуры при обфускации кода программы:

• изменение таблиц импорта, экспорта и переадресации
• маскировка оригинальной 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), что снижает возможность атак из Интернета.

Неудачные примеры использования принципа

• В Москве на Ходынском поле рабочие во время ремонта дороги повредили кабель специальной связи, который не был указан в документации в связи с большой секретностью расположения кабеля. Это хорошая иллюстрация того, что используя принцип безопасность через неясность, не только злоумышленник может нарушить этот принцип, но даже и случайный человек.^[5]
• Многие люди прячут свою личную информацию на серверах в надежде, что если не будет раскрыто то, что информация расположена на сервере, то злоумышленник не сможет её найти ( используя скрытую папку, создавая сервер на нестандартном порте, не указывая DNS имя). Но в настоящее время сетевые сканеры легко находят такую информацию и она оказывается в руках злоумышленника.^[5]
• Существует несколько проблем с использованием URL. Так как данные в URL посылаются в открытом виде, то они могут быть легко перехвачены (URL сохранятся в логах браузера, в истории браузера, в логах прокси-серверов и т.д.). Поэтому не стоит пересылать секретные данные, такие как имена пользователей и пароли, используя технологию URL.^[5]
• A5/1 шифр для мобильной телефонной системы сотовой связи GSM стал известен частично за счет реверс-инжиниринга^[1]
• Уязвимости в различных версиях Microsoft Windows, веб-браузера по умолчанию Internet Explorer, его почтового приложения Microsoft Outlook, Outlook Express вызвали во всем мире проблемы, когда компьютерные вирусы, троянские кони или сетевые черви пользовались этими уязвимостями. Действительно, различные государственные учреждения имеют время от времени проблемы с безопасностью использования этого программного обеспечения.
• Программное обеспечение маршрутизаторов Cisco случайно стало доступным для свободного подключения в корпоративной сети.

См. также

• Стеганография
• Морфинг программного кода
• Принцип Керкгоффса
• Обфускация

Ссылки

1. ↑ ^{1 2} Безопасность GSM: Реальная или виртуальная?. БАРСУКОВ Вячеслав Сергеевич, кандидат технических наук.
2. ↑ Кивино гнездо: О "взломе" Skype. КОМПЬЮТЕРРА-ONLINE (июль 2010).
3. ↑ Великий спор: безопасность через маскировку. TechNet Magazine (июнь 2008).
4. ↑ Обфускация. Персональный Компьютер (июнь 2008).
5. ↑ ^{1 2 3} Security through obscurity. Корпоративный блог Граманта.ру (август 2010).