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

Безпека через неясність (англ. Security through obscurity) — принцип, який полягає в тому, щоб приховати внутрішній устрій системи або реалізацію для забезпечення безпеки. Експерти з безпеки відхилили цей принцип ще у 1851 році та рекомендують ніколи не покладатися на неясніть як основний принцип захисту

Історія питання

Існуюча офіційна література з питання про безпеку через неясність, досить мізерна. Книги по інженерії безпеки посилаються на Принцип Керкгоффса від 1883 року.

В області права Пітер Свайр написав про компроміс між тим, що «безпека через неясність — це ілюзія», і, як кажуть військові, що «чутки топлять кораблі», а також про те, як конкуренція впливає на стимули до розкриття інформації.

Принцип безпеки через неясність був загальноприйнятим в криптографічних роботах в часи, коли проінформовані криптографи працювали на національні спецслужби, такі як Агентство національної безпеки. Тепер криптографи часто працюють в університетах, де дослідники публікують відкрито їх досягнення, публічно тестують чужі розробки, або в приватному секторі. Адже деякі дослідження контролюються патентами й авторськими правами. Наприклад, PGP випущений у вигляді вихідного коду і зазвичай вважається (при правильному використанні) криптосистемою військового рівня[1].

Переваги і недоліки використання принципу

Наведемо аргументи на користь використання принципу. Незважаючи на те, що створення захисту системи, яка спирається виключно на принцип безпеки через неясність, є невдалим рішенням використання даного принципу з метою збереження в таємниці деяких деталей системи. Наприклад, при виявленні уразливості системи, безпека через неясність може бути тимчасовим бар'єром для зловмисників, поки не буде усунена дана уразливість. У цьому випадку метою використання принципу є зниження в короткостроковій перспективі ризику експлуатації уразливості в основних компонентах системи.

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

Ще одна стратегія використання принципу передбачає існування подвійного шару вразливостей, обидва з яких тримаються в секреті. При цьому творці системи дозволяють одній з вразливостей «витекти». Ідея полягає в тому, щоб дати зловмисникові помилкове відчуття впевненості, що захист було подолано й він переміг. Наприклад, це може використовуватися як частина приманки («ловля на живця»).

Аргументи проти принципу безпеки через неясність сягають принципу Керкгоффса, висунутому в 1883 році Огюстом Керкгоффсом. Цей принцип стверджує, що дизайн криптографічної системи не повинен вимагати секретності й не повинен завдавати незручностей, якщо він потрапить в руки ворога. Розробники повинні вважати, що весь дизайн системи безпеки відомий нападникам, за винятком криптографічних ключів (безпека криптографічного системи знаходиться повністю в криптографическом ключі). У 1940 році Клод Шеннон сформулював цей принцип як «ворог знає систему»[1].

Чим більше точок можливої ​​компрометації міститься в системі, тим більша ймовірність того, що стратегія нападу на одну з цих точок існує або буде розроблена. Системи, які містять секретність структури або операцій, які також є точками можливої ​​компрометації, є менш безпечними, ніж аналогічні системи без цих точок. Це в тому випадку, що зусилля, необхідне для отримання уразливості в результаті розкриття структури проекту або методу роботи, а також зусилля, щоб використовувати цю вразливість, менше за зусилля, необхідне для отримання секретного ключа. Рівень безпеки системи зводиться при цьому до зусиль, необхідним для використання цієї вразливості.

Наприклад, якщо хтось зберігає запасний ключ під килимком, у разі, якщо двері замкнені зовні, то він покладається на безпеку через неясність. Теоретична вразливість в системі безпеки в тому, що хтось може увірватися в будинок, відкривши двері за допомогою цього запасного ключа. Крім того, оскільки грабіжники часто знають передбачувані місця схованок, власник будинку буде піддаватися великому ризику крадіжки зі зломом, приховуючи ключ, так як зусилля, потрібне для того, щоб знайти ключ, ймовірно, буде менше зусиль, необхідних для проникнення (наприклад шляхом злому) іншим способом, наприклад, через скло. Господар додав вразливість — той факт, що вхідний ключ зберігається під килимком — в систему, і таку, яку дуже легко вгадати і використати.

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

Безпека через неясність не визнається відповідним інженерним підходом до забезпечення безпеки системи, так як вона суперечить принципу «KISS». Національний інститут стандартів і технологій спеціально рекомендує використовувати безпеку через неясність не більше ніж в одному документі. Згідно NIST, «система безпеки не повинна залежати від секретності реалізації її компонентів»[2].

Існує загальний консенсус, навіть серед тих, хто виступає на користь безпеки через неясність, що принцип «безпека через неясність» ніколи не повинна використовуватися в якості основного заходу безпеки. Це, в кращому випадку, вторинна міра, й розкриття інформації про неясності не повинно призводити до компрометації.

Приклади використання

Різниця значення використання принципу у відкритому і закритому програмному забезпеченні

Цінність використання принципу при створенні відкритого або закритого ПЗ дуже різна й неоднозначна. Розглянемо процес створення відкритого ПЗ. Найбільш часто розробники більш зацікавлені в створенні нового коду, ніж в аналізі вже існуючого на наявність вразливостей. Так як створення відкритого ПЗ є справою добровольців, а безпеці приділяється менше уваги. З іншого боку, існує закон Лінуса, який говорить, що «при достатній кількості очей баги випливають на поверхню». Тобто, закон передбачає підвищену безпеку алгоритмів і протоколів, опис яких опубліковано. Більше людей може переглянути деталі таких алгоритмів, виявити недоліки і раніше їх виправити. Прихильники цієї точки зору вважають, що частота й тяжкість наслідків компрометації буде менша, ніж для закритого або секретного програмного забезпечення. З усього цього можна зробити висновок, що в разі створення відкритого ПЗ, безпека безпосередньо залежить від популярності програми, тобто чим вище популярність, тим більше добровольців аналізують код програми і тим вища ймовірність знаходження вразливостей в ньому. На підтвердження цього наведемо приклад, що вихідний код Linux має 0.17 помилок на тисячу рядків вихідного коду[3], в той час як закрите комерційне програмне забезпечення в середньому налічує 20-30 помилок на 1000 рядків вихідного коду.

Що стосується закритого ПЗ, то при його створенні аналізу безпеки коду приділяється велика увага, що підвищує надійність системи. З іншого боку, так як кількість розробників часто менше, ніж в разі відкритого ПЗ, зменшує ймовірність виявлення існуючих вразливостей в програмі. До того ж, оператори й розробники/виробники систем, які покладаються на безпеку через неясність, можуть зберегти в таємниці той факт, що в їх системі знайдена уразливість, щоб уникнути зменшення попиту в своїх послуг або продуктів і, отже, уникнути зниження його конкурентоспроможності, вселивши, таким чином, помилкову впевненість у безпеці своїх продуктів. Були відомі випадки, щонайменше, 1960-х років, коли компанія затримувала випуск виправлень і патчів, віддаючи пріоритет своїм корпоративним правилам, а не проблемам або ризиків клієнтів.

Історія використання принципу в сервісі Skype

Інженер-розробник Шон О'Ніл (Sean O'Neil) відомий як творець досить гнучкого криптоалгоритма EnRUPT. Також він відомий у вузьких колах криптоаналітиків як людина, що брала участь у зломі секретного шифру в RFID — чипах Mifare. Ці чипи лежать в основі транспортних карт, електронних перепусток та інших безконтактних смарт-карт, кількість яких по всьому світу на сьогоднішній день обчислюється мільярдами[4].

У липні 2010 року в Інтернеті з'явилася новина, що Шон О'Ніл з групою колег зміг розкрити вихідні коди програм, які захищають відомий сервіс IP-телефонії Skype. А точніше, їм вдалося отримати вихідні коди пропрієтарних протоколів шифрування сервісу Skype. У своєму блозі Шон О'Ніл дає посилання на сайт cryptolib.com, де, за його словами, знаходяться отримані коди[4].

За їх власним свідченням, Шон О'Ніл і його колеги по реверс-інженірингу насправді займалися проблемами безпеки сервісу Skype протягом довгого періоду часу. Так як вони були фахівцями в аналізі двійкових кодів, їм вдалося досить швидко відновити програму по двійковим кодами, незважаючи на те, що програмісти Skype дуже інтенсивно застосовували обфускацію. Саме через те, що розробники Skype інтенсивно застосовували обфускацію, дещо до цього вдавалося відновити програму за двійковими кодами, а ті, хто це зміг зробити, не публікували вихідні коди, так як вони виглядали страхітливо[4].

В кінцевому підсумку Шону О'Нілу вдалося створити еквівалентний код, який у всіх основних режимах працює як Skype, але який написаний без використання коду Skype. Хоча створення коду відбувалося приватно, через кілька тижнів йому вдалося просочитися в Інтернет, і він відразу став інструментом спамерів, які робили розсилки по каналах сервісу термінових повідомлень Skype. Відчуваючи відповідальність за те, що відбувається, Шон О'Ніл вирішив викласти головний секрет комунікаційного протоколу Skype — заплутаний обфускація — алгоритм розширення для вектора ініціалізації шифру RC4. Більш конкретно, на сайті cryptolib.com викладена програма на мовою C, за допомогою якої можливе дешифрування службового трафіку між клієнтами Skype і супервузлом системи. Незважаючи на те, що для шифрування службових даних використовується потоковий метод шифрування RC4, відсутні секретні ключі, які необхідно зламувати. Єдине ж, що реально є, це постійне перетворення, яке перетворює читану інформацію в таку, що не читається. Сенс цього алгоритму полягав в тому, щоб ніякі інші особи не змогли розробляти сумісні з Skype додатки, адже не знаючи алгоритмів передачі службових даних, неможливо створити такі додатки. Це був захист для монопольного володіння Skype своєю системою.


Наведемо приклад використання обфускаціі. Обфускація — техніка, спрямована на заплутування вихідного або виконуваного коду програми, метою якої є збереження працездатності, але такий код буде важко проаналізувати.

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

Деякі процедури при обфускаціі коду програми:

  • Зміна таблиць імпорту, експорту та переадресації
  • Маскування оригінальної 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), що знижує можливість атак з Інтернету.

Невдалі приклади використання принципу
  • У Москві на Ходинському полі робочі під час ремонту дороги пошкодили кабель спеціального зв'язку, який не був зазначений в документації в зв'язку з великою секретністю розташування кабелю. Це хороша ілюстрація того, що при використанні принципу «безпека через неясність» безпека може бути порушена не тільки зловмисником, але навіть і випадковою людиною.
  • Багато людей ховають свою особисту інформацію на серверах в надії, що якщо не буде розкрито те, що інформація розташована на сервері, то зловмисник не зможе її знайти (використовуючи приховану папку, створюючи сервер на нестандартному порту, ще не вказуючи DNS ім'я). Однак в даний час мережеві сканери легко знаходять таку інформацію і вона виявляється в руках зловмисника.
  • Існує кілька проблем з використанням URL. Так як дані в URL посилаються при використанні протоколу HTTP у відкритому вигляді, то вони можуть бути легко перехоплені (URL збережуться в логах браузер а, в історії браузера, в логах провайдерів і проксі-сервер і т. д.).
  • A5/1, спочатку засекречений шифр для мобільної телефонної системи стільникового зв'язку GSM, став відомий частково за рахунок Відтворення програмного коду реверс-інжинірингу .
  • Уразливості в різних версіях Microsoft Windows, веб-браузера за замовчуванням Internet Explorer, його поштовий клієнт Microsoft Outlook і Outlook Express викликали в усьому світі проблеми, троянські коні або мережеві черв'яки користувалися цими вразливостями.
  • Програмне забезпечення маршрутизаторів Cisco випадково стало доступним для вільного підключення в корпоративній мережі.

Див. також


Примітки
  1. Безопасность GSM: реальная или виртуальная?
  2. Guide to General Server Security
  3. Coverity: На 1000 строк исходного кода открытых программ насчитывается 1 дефект
  4. Кивино гнездо: О «взломе» Skype

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.