Наскільки серйозно ця нова вразливість безпеки ASP.NET і як я можу її вирішити?

Я щойно читав в мережі про недавно виявлену вразливість безпеки в ASP.NET. Подробиці ви можете прочитати тут.

Проблема полягає в тому, що ASP.NET реалізує алгоритм шифрування AES для захисту цілісності файлів cookie, які ці програми створюють для зберігання інформації під час сеансів користувача.

Це трохи розпливчасто, але ось більш страхітлива частина:

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

Загалом, я недостатньо знайомий із темою безпеки / криптографії, щоб знати, чи справді це так серйозно.

Отже, чи повинні всі розробники ASP.NET боятися цієї методики, яка може володіти будь-яким веб-сайтом ASP.NET за лічені секунди чи що?

Як ця проблема впливає на середнього розробника ASP.NET? Це взагалі впливає на нас? У реальному житті які наслідки цієї вразливості? І, нарешті: чи є якесь вирішення, яке запобігає цій вразливості?

Дякую за відповіді!

EDIT: Дозвольте підсумувати відповіді, які я отримав

Отже, це в основному тип нападу "оракул". @Sri дав чудове пояснення про те, що означає цей тип нападу. Ось шокуюче відео про проблему!

Про серйозність цієї вразливості: Так, вона справді серйозна. Це дозволяє зловмиснику ознайомитися з машинним ключем програми. Таким чином, він може робити дуже небажані речі.

• Маючи машинний ключ програми, зловмисник може розшифрувати файли cookie.
• Навіть гірше, що він може генерувати файли cookie автентичності з іменем будь-якого користувача. Таким чином, він може з’являтися як будь-хто на сайті. Додаток не в змозі розмежувати вас або хакера, який створив файл cookie для автентифікації для вашого імені.
• Це також дозволяє йому розшифрувати (а також генерувати) сесійні файли cookie , хоча це не так небезпечно, як попереднє.
• Не так серйозно: він може розшифрувати зашифрований ViewState сторінок. (Якщо ви використовуєте ViewState для зберігання конфіденційних даних, все одно цього робити не слід!)
• Досить несподівано : знаючи ключ машини, зловмисник може завантажити будь-який довільний файл із вашого веб-додатку, навіть той, який зазвичай не можна завантажити! (Включаючи Web.Config тощо)

Ось купа добрих практик, які я не вирішував, але допомагає покращити загальну безпеку веб-програми.

• Ви можете зашифрувати конфіденційні дані за допомогою захищеної конфігурації
• Використовуйте файли cookie Тільки HTTP
• Запобігати DoS-атакам

Тепер зупинимось на цьому питанні.

• Скотт Гетрі опублікував запис про це у своєму блозі
• Повідомлення в блозі ScottGu FAQ про вразливість
• Оновлення ScottGu щодо вразливості
• Майкрософт має рекомендації щодо безпеки
• Розуміння вразливості
• Додаткова інформація про вразливість

Рішення

• Увімкніть customErrors та зробіть єдину сторінку помилок, на яку переспрямовано всі помилки . Так, навіть 404-ті . (СкоттГу сказав, що для цієї атаки важливо розмежування 404-х та 500-х.) Крім того, введіть Application_Errorабо введіть Error.aspxякийсь код, який робить випадкову затримку. (Створіть випадкове число і використовуйте Thread.Sleep для того, щоб спати так довго.) Це зробить неможливим для зловмисника вирішити, що саме сталося на вашому сервері.
• Деякі люди рекомендували перейти назад до 3DES. Теоретично, якщо ви не використовуєте AES, ви не стикаєтесь із слабкістю безпеки у впровадженні AES. Як виявляється, це зовсім не рекомендується .

Деякі інші думки

• Здається, не всі вважають, що вирішення проблеми досить добре.

Дякую всім, хто відповів на моє запитання. Я дізнався багато цікавого не лише про це питання, але і про безпеку в Інтернеті загалом. Я позначив відповідь @ Mikael як прийняту, але інші відповіді також дуже корисні.

Що мені робити, щоб захистити себе?

[Оновлення 2010-09-29]

Бюлетень безпеки Microsoft

Стаття KB з посиланням на виправлення

У ScottGu є посилання для завантаження

[Оновлення 2010-09-25]

Поки ми чекаємо виправлення, вчора ScottGu представив оновлення про те, як додати додатковий крок для захисту своїх сайтів за допомогою спеціального правила URLScan.

Крім того, додайте до сторінки помилок випадковий час сну, щоб запобігти зловмиснику призначати відповіді на додаткову інформацію про атаку.

У web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Це призведе до переадресації будь-якої помилки на користувацьку сторінку, повернуту з кодом статусу 200. Таким чином зловмисник не може переглянути код помилки або інформацію про помилку для інформації, необхідної для подальших атак.

Це також безпечно налаштувати customErrors mode="RemoteOnly", оскільки це перенаправить «справжніх» клієнтів. Лише перегляд із localhost покаже внутрішні помилки .Net.

Важлива частина - переконатися, що всі помилки налаштовані для повернення однієї сторінки помилок. Це вимагає, щоб ви чітко встановили defaultRedirectатрибут на <customErrors>розділі та переконалися, що не встановлені коди за статусом.

Що ставиться на карту?

Якщо зловмисникові вдасться використати згаданий експлойт, він / вона може завантажити внутрішні файли з вашого веб-додатку. Зазвичай web.config є цільовим і може містити конфіденційну інформацію, таку як інформація для входу в рядок підключення до бази даних, або навіть посилання на автоматизовану базу даних sql-express, до якої ви не хочете, щоб хтось здобув. Але якщо ви дотримуєтеся найкращої практики, ви використовуєте захищену конфігурацію для шифрування всіх конфіденційних даних у вашій web.config.

Посилання на посилання

Прочитайте офіційний коментар Microsoft щодо вразливості на веб- сайті http://www.microsoft.com/technet/security/advisory/2416728.mspx . Зокрема, "обхідну" частину щодо детальної інформації щодо впровадження цього питання.

Також деяку інформацію про блог Скоттгу , включаючи сценарій пошуку вразливих програм ASP.Net на своєму веб-сервері.

Для пояснення на тему "Розуміння нападів Oracle Attack" читайте відповідь @ sri .

Коментарі до статті:

Атака, яку Rizzo та Duong здійснили проти програм ASP.NET, вимагає, щоб у криптовалюті на веб-сайті був оракул, який при надсиланні шифротексту не тільки розшифрує текст, але і передасть відправнику повідомлення про те, чи є прошивка в шифротексті. є дійсним .

Якщо прокладка недійсна, повідомлення про помилку, яке отримує відправник, дасть йому інформацію про те, як працює процес розшифрування сайту.

Для того, щоб атака спрацювала, повинно бути правдою:

• У вашій програмі повинно бути повідомлення про помилку про те, що прокладка недійсна.
• Хтось повинен підробляти ваші зашифровані файли cookie або перегляд

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

• Збережіть ідентифікатор сеансу у зашифрованому файлі cookie
• Збереження реальних даних у стані сеансу (зберігається в db)
• Додайте випадкове очікування, коли інформація користувача неправильна, перш ніж повернути помилку, тому ви не можете її вчасно

Таким чином, викрадене cookie можна використовувати лише для отримання сеансу, який, швидше за все, більше не присутній або недійсний.

Буде цікаво подивитися, що насправді представлено на конференції Екопарті, але зараз я не надто переживаю цю вразливість.

Розуміння нападів Oracle Attack

Припустимо, що ваша програма сприймає зашифрований рядок як параметр - незалежно від того, чи є це файлом cookie, URL-адресою чи іншим, що не має значення. Коли програма намагається її розшифрувати, є 3 можливі результати -

1. Результат 1 : Зашифрована рядок розшифрована належним чином, і програма змогла зрозуміти це. Значить, якщо зашифрований рядок був 10-значним номером рахунку, після розшифровки додаток знайшов щось на кшталт "1234567890", а не "abcd1213ef"

2. Результат 2 : Прокладка була правильною, але після розшифровки отримана нитка стала химерною, що додаток не міг зрозуміти. Наприклад, рядок розшифрована на "abcd1213ef", але додаток очікував лише цифр. У більшості програм з’явиться повідомлення типу "Недійсний номер облікового запису".

3. Результат 3 : Прокладка була неправильною, і додаток кинуло якесь повідомлення про помилку. У більшості додатків відображатиметься загальне повідомлення типу "Виникла помилка".

Для того, щоб атака Padding Oracle була успішною, зловмисник повинен мати можливість зробити кілька тисяч запитів і повинен мати можливість класифікувати відповідь в одне з вищезгаданих 3 відра без помилок.

Якщо ці дві умови будуть дотримані, зловмисник може врешті-решт розшифрувати повідомлення, а потім повторно зашифрувати його тим, що захоче. Це лише питання часу.

Що можна зробити, щоб запобігти?

1. Найпростіша річ - нічого чутливого ніколи не слід надсилати клієнту, зашифровувати або не шифрувати. Зберігайте його на сервері.

2. Переконайтесь, що результат 2 та результат 3 у наведеному вище списку виглядають точно так само, як і для зловмисника. Не повинно бути ніякого способу відрізнити одне від іншого. Однак це не все так просто - зловмисник може дискримінувати, використовуючи якусь атаку в таймінгу.

3. В якості останньої лінії захисту створіть брандмауер веб-додатків. Для атаки Oracle padding необхідно зробити кілька запитів, які виглядають майже подібними (змінюючи один біт за один раз), тому WAF повинен мати можливість ловити та блокувати такі запити.

PS Хороше пояснення щодо Padding Oracle Attacks можна знайти в цій публікації в блозі . Відмова: Це НЕ мій блог.

З того, що я читав дотепер ...

Атака дозволяє комусь розшифрувати нюхані файли cookie, які можуть містити цінні дані, такі як банківські залишки

Їм потрібен зашифрований файл cookie користувача, який вже був увійшов у систему, у будь-якому обліковому записі. Їм також потрібно знайти дані у файлах cookie - сподіваюся, що розробники не зберігають критичні дані у файлах cookie :). І є спосіб, який я маю нижче, щоб не дозволяти asp.net зберігати дані у файлі cookie.

Як хтось може отримати файли cookie користувача, який перебуває в Інтернеті, якщо він не отримує свої дані в браузері? Або нюхати IP-пакет?

Один із способів запобігти цьому - не дозволяти файлам cookie транспортувати без шифрування ssl.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Також ще одним заходом є запобігання зберігання ролей у файлах cookie.

<roleManager enabled="true" cacheRolesInCookie="false">

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

Довідка:
Чи може якийсь хакер викрасти файл cookie у користувача та увійти з цим ім'ям на веб-сайті?

Як перевірити, звідки надходять напади, і не давати назад інформації. Я написав тут простий спосіб запобігти недійсності прокладки і одночасно вести журнал, щоб відслідковувати зловмисників: CryptographicException: Прокладка недійсна і її неможливо видалити.

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

Оновлення 1.

Я завантажив інструмент, який передбачає, що знайдіть КЛЮЧ і розшифруйте дані, і, як я кажу, його пастка у наведеному вище коді, який перевіряє перегляд стану . З моїх тестів у цього інструменту є ще багато чого виправити, наприклад не можна сканувати стан стисненого перегляду таким, яким він є, і його збій на моїх тестах.

Якщо хтось намагається скористатися цим інструментом або цим методом, наведений вище код може відстежити їх, і ви можете заблокувати їх зі своєї сторінки простим кодом, таким як "Попередити відмову в сервісі (DOS)" або подібним цим кодом для запобігання відхилення обслуговування .

Оновлення 2

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

дуже цікаве відео з цього питання.

Отже, все вищесказане - це більше міра для більшого захисту, але не 100% необхідна для цього конкретного питання. Наприклад, використання файлу cookie ssl - це вирішення проблеми snif, а не кешування ролей у файлах cookie. Добре не надсилати та отримувати великі файли cookie, а також уникати тих, у яких усі готові зламати код, просто розмістити роль адміністратора на печиво його.

Держава перегляду відстежує свою ще одну міру пошуку атаки.

Ось відповідь МС. Все це зводиться до "використання користувацької сторінки помилок", і ви не даватиме жодних підказок.

EDIT
Ось трохи детальніша інформація від scottgu.

Додавання відповідей ScottGu, взятих із обговорення на веб- сайті http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Чи впливає користувацький IHttpModule замість customErrors?

З: У мене немає елемента, задекларованого в моєму web.config, у мене замість цього IHttpModule у розділі. Цей модуль записує помилку та переспрямовує на сторінку пошуку (для 404-х) або на сторінку помилки (на 500-і). Я вразливий?

A: Я рекомендую тимчасово оновити модуль, щоб завжди переадресовувати на сторінку пошуку. Одним із способів цієї атаки є розмежування 404 помилок та 500 помилок. Завжди повертати один і той же HTTP-код і надсилати їх на те саме місце - це один із способів блокувати його.

Зауважте, що коли виправити це виправлення, вам цього не потрібно буде (і ви можете повернутись до старої поведінки). Але наразі я рекомендую не розрізняти 404s та 500s для клієнтів.

Чи можу я продовжувати використовувати різні помилки для 404 та 500 помилок?

Питання: Я вважаю, що ми можемо мати окрему сторінку 404 на додаток до перенаправлення за замовчуванням на помилку, не порушуючи описаних вище принципів?

Відповідь: Ні - поки ми не випустимо патч для реального виправлення, ми рекомендуємо вищевказане рішення, яке однозначно підтверджує всі помилки. Одним із способів цієї атаки є розмежування 404 помилок та 500 помилок. Завжди повертати один і той же HTTP-код і надсилати їх на те саме місце - це один із способів блокувати його.

Зауважте, що коли виправити це виправлення, вам цього не потрібно буде (і ви можете повернутись до старої поведінки). Але наразі вам не слід розмежовувати 404s та 500s для клієнтів.

Як це дозволяє відкрити web.config?

Питання: Як це дозволяє відкрити web.config? Здається, це дозволяє лише розшифрувати ViewState, чи існує ще одна пов'язана з цим вразливість, яка також дозволяє розкривати інформацію? Чи є довідка, яка детально описує атаку для кращого пояснення того, що відбувається?

Відповідь: Атака, яка була показана у публіці, покладається на функцію ASP.NET, яка дозволяє завантажувати файли (як правило, JavaScript та css) і захищена ключем, який надсилається як частина запиту. На жаль, якщо ви зможете підробити ключ, ви можете скористатися цією функцією для завантаження файлу web.config програми (але не файлів поза додатком). Ми, очевидно, випустимо патч для цього - до цього часу вищезгадане вирішення закриває вектор атаки.

EDIT: додаткові поширені запитання доступні у другому дописі на веб-сторінці http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

ІМО, для цього немає всебічної профілактики, її потрібно вирішувати в кожному конкретному випадку:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Кілька важливих посилань:

• Консультативна допомога з питань безпеки 2416728 (це офіційна інформація)
• Додаткова інформація від команди з питань безпеки та оборони MS
  • "Розуміння вразливості ASP.NET" (2010-09-17)
  • "Додаткова інформація про вразливість ASP.NET" (2010-09-20)
• Скотт Гу: "Важливо: Уразливість безпеки ASP.NET" (2010-09-18)

[Щоб відповісти на аспект серйозності цього (те, що було опубліковано та обхідні шляхи, охоплені іншими відповідями).]

Ключ, на який атакують, використовується для захисту файлів cookie стану перегляду та сеансу. Зазвичай цей ключ генерується внутрішньо ASP.NET з кожним новим екземпляром веб-програми. Це обмежить масштаби пошкодження протягом життя робочого процесу, звичайно, для напруженого застосування це може бути декілька днів (тобто не дуже обмеження). За цей час зловмисник може змінити (або ввести) значення у ViewState та змінити їх сеанс.

Ще серйозніше, якщо ви хочете, щоб сеанси мали змогу охопити життя робочих робітників або дозволити веб-фермам (тобто всі екземпляри ферми можуть обробляти будь-яку сесію користувача), ключ повинен бути чітко закодований, це робиться в web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Це, звичайно, новостворені ключі, я використовую наступний PowerShell для доступу до криптографічного генератора випадкових чисел Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Використовуючи масив довжиною 20 для перевірки та 16 для ключів розшифровки.)

Окрім зміни публічних сторінок помилок, щоб не просочуватися конкретні помилки, здається, вдалий час змінити вищевказані клавіші (або циклічні процеси, якщо вони працюють деякий час).

[Редагувати 2010-09-21: Додані посилання на початок]

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

Просто хочу зрозуміти деякі факти:

1. атака не дозволяє отримати ключ машини безпосередньо. Однак, це майже так, як це було, оскільки дозволяє розшифрувати повідомлення та змінити повторно / шифрувати нові.
2. спосіб отримати фактичні ключі, використовуючи їх здатність змінювати повторне шифрування, як у 1, та отримувати web.config. На жаль, є причини, чому деякі кладуть ці ключі в web.config на рівні сайту (різні дискусії), а у зразковому відео вони виграють від того, що це за замовчуванням DotnetNuke.
3. щоб отримати web.config все там, вказує на те, що вони використовують webresources.axd та / або scriptresources.axd. Я думав, що вони працюють лише з вбудованими ресурсами, але, здається, це просто не так.
4. якщо додаток asp.net MVC, нам насправді не потрібні webresources.axd та / або scriptresources.axd, тому їх можна вимкнути. Ми також не використовуємо viewstate. З цього приводу, мені незрозуміло, чи будь-яка інша функція asp.net надає іншу інформацію з можливим вирішенням, тобто я не знаю, чи підшивка дає помилкові результати в помилках під час прокладки дійсних результатів в ігнорованому квитку автентифікації (не знаю якщо це так чи ні) ... той самий аналіз повинен застосовуватися і до файлу cookie сеансу.
5. постачальник членства asp.net "кешує" ролі у файлах cookie, вимкніть це.

Приблизно 1, afaik зашифрованих повідомлень не може бути на 100% довільною потребою переносити крихітний шматок сміття десь у повідомленні, оскільки в повідомленні є один блок, який розшифровує значення, яке неможливо контролювати.

Нарешті, я хотів би сказати, що ця проблема є результатом того, що повідомлення в цьому випадку не відповідає власним вказівкам: функція покладається на те, що клієнт надсилає щось, що не підлягає фальсифікації.

Більше на тему:

Я не знаю, чи заміщення дає помилкові результати в помилках, тоді як додавання дійсних результатів в ігнорованому квитку автентифікації (не знаю, чи це так чи ні) ... той же аналіз повинен застосовуватися і до файлу cookie сесії.

Файл cookie-аутентифікатора підписаний, і з інформації в папері вони не повинні мати змогу генерувати підписаний файл cookie, якщо вони не дістаються до фактичних ключів (як це було зроблено у відео перед тим, як підробляти авторське cookie).

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

Виправлення цієї помилки було випущено в Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Ця проблема також впливає на Asp.Net MVC (як і Sharepoint, ...)

Тут я висвітлив виправлення MVC: Чи вразливий ASP.NET MVC до атаки прокладки Oracle?