Websecurity - Веб безпека

Тема безпеки Invision Power Board та уразливостей в ньому важлива для мене. Тому що в мене форум на цьому движку.

Продовжуючи тему Безпеки IPB, розповім вам про нові уразливості та експлоіти до IPB.

Ось три самих останніх експлоїта для IPB (для 2.1.7 та попередніх версій движка):

• Міжсайтове виконання сценаріїв в Invision Power Board (деталі)
• Invision Power Board <= 2.1.7 (Debug) Remote Password Change Exploit (деталі)
• Invision Power Board 2.1.7 debug mode vulnerability (деталі)

Раніше я вже писав про жовтневий Web Application Security Professionals Survey, який проводив Джеремія Гроссман. А зараз розповім вам про результати листопадового Web Application Security Professionals Survey (в якому я приймав участь).

Питання:

1) Для кого ви виконуєте аудит безпеки веб додатків?
a) Для секюріті виробників
b) Для підприємств
c) В розважальних і/або навчальних цілях
d) Ішне

A: 40% B: 48% C: 8% D: 4%

2) Яка ваша найбільш поширена методологія аудиту безпеки веб додатків?
a) Аналіз вихідних кодів (White Box)
b) Black Box
c) Комбінація A та B

A: 2% B: 54% C: 44%

3) Чи ви використовуєте комерційні сканери безпеки для проведення секюріті аудитів?
a) Ніколи
b) Іноді
c) 50/50
d) В більшості випадків
e) Завжди

A: 52% B: 21% C: 0% D: 6% E: 21%

4) Чи ви використовуєте опен сорс інструменти для проведення секюріті аудитів?
a) Ніколи
b) Іноді
c) 50/50
d) В більшості випадків
e) Завжди

A: 0% B: 13% C: 15% D: 17% E: 56%

5) Яку систему оцінки небезпечності уразливостей веб додатків ви використовуєте?
a) DREAD
b) TRIKE
c) CVSS
d) Власну
e) Інше

A: 8% B: 2% C: 6% D: 67% E: 17%

6) Яка одна найбільш небезпечна і найбільш поширена уразливість веб додатків?
a) Cross-Site Scripting (XSS)
b) Cross-Site Request Forgery (CSRF)
c) PHP Include
d) SQL Injection
e) Інше

A: 48% B: 6% C: 10% D: 31% E: 4%

7) Чи є Cross-Site Request Forgeries (CSRF) частиною вашої методологї аудиту безпеки?
a) Так
b) Ні
c) Іноді
d) Що?

A: 42% B: 10% C: 46% D: 2%

8) З вашого досвіду аудиту безпеки, скільки веб сайтів майють серйозні уразливості в веб додатках?
a) Всі чи майже всі
b) Більшість
c) 50/50
d) Декілька
e) Незнаю

A: 17% B: 38% C: 21% D: 25% E: 0%

9) Скільки часу у вас займає пошук однієї серйозної уразливості на більшості публічних веб сайтів?
a) Пару хвилин
b) Час чи два
c) День і ніч
d) Кілька днів
e) Незнаю, ніколи не пробував

A: 23% B: 35% C: 19% D: 2% E: 21%

10) Через який час, після проведення аудиту безпеки, виправляється більшість знайдених уразливостей?
a) На протязі кількох годин
b) За декілька наступних днів
c) На протязі наступного планового оновлення програм
d) Місяць з часу знайдення
e) Як раз перед наступним щорічним аудитом безпеки

A: 0% B: 40% C: 30% D: 26% E: 4%

11) Які заходи можуть найбільше покращити безпеку веб сайтів?
a) Використання сучасних фрейморків для розробки програм (.NET, J2EE, Ruby on Rails, тощо)
b) Тренінги про безпеку програм та обізнаності розробників в темі безпеки
c) Більша присутність безпеки в Циклі Розробки Програмного Забезпечення (SDLC)
d) Відповідність промисловим стандартам
e) Інше

A: 21% B: 28% C: 21% D: 2% E: 28%

12) Чи ви були причетними до злочинних атак на веб додатки, які не були розкритими?
a) Ні
b) Один раз
c) Декілька разів
d) Багато, що й усе не перерахуєш

A: 35% B: 7% C: 41% D: 17%

Результати опитування навіюють на роздуми.

Зокрема результати відповідей на питання №3, про використання комерційних сканерів безпеки. 73% опитаних секюріті спеціалістів взагалі не використовують (або дуже рідко) комерційні сканери безпеки (зокрема я не використовую подібні сканери, і в цьому наші позиції співпали).

В своєму записі Yet Another Way to Fingerpring IIS, RSnake розповідає про розроблений метод визначення IIS (його ідентифікації) - веб сервера Internet Information Services від Майкрософт (ясна річ сервер тільки під Windows платформу).

Суть методу зводиться до відправлення хитрого запиту: після адреси домена не ставиться слеш і додається знак питання та будь-який текст (наприклад: ?blah). Цей простий трюк приводить до того, що: Апач сервер нормально на це реагує (видає “200 OK”), а IIS ругається (видає “400 Bad Request”) - тим самим видаючи себе. В записі RSnake наводить приклади запитів до веб серверів (через telnet), які демонструють реакцію веб серверів Apache та IIS.

До речі, в коментарях Ilia Alshanetsky повідомив, що даний трюк можна використати для визначення lighttpd, який також своєрідно реагує на подібний запит (видає “301 Moved Permanently”). В даному випадку лише треба в запиті до імені домена додати “//?”, щоб визначити сервер lighttpd по його реакції.

Подібне визначення веб серверів (fingerpring) може знадобитися при аудиті безпеки окремих сайтів, або навіть окремих веб серверів в локальній мережі чи в Інтернет.

Відомі секюріті компанії та експерти в галузі безпеки (та веб безпеки) вже виступили зі своїми прогнозами на наступний рік. Про деякі з них я писав раніше, про деякі цікаві прогнози я ще напишу.

Але зараз підведу власні підсумки 2006 року і надам свої прогнози на рік новий. Ніколи раніше не робив подібних прогнозів, це я роблю вперше , тому віднесіться з розумінням до моїх прогнозів.

Результати розвитку галузі веб безпеки в 2006 році.

1. Поширення XSS уразливостей, які в 2006 році стали найпоширенішими уразливостями, залишивши далеко позаду уразливості “переповнення буферу”.
2. Почастішали атаки на соціальні мережі (зокрема з використанням XSS уразливостей)
3. З’явились перші масові веб віруси (які набули більшої поширенності ніж веб віруси 2004 року), які використовували уразливості на популярних веб ресурсах і вразили велику кількість їх користувачів.
4. В цьому році зафіксована висока активність хакерів.
5. Акцент пошуку уразливостей і написання експлоітів змістився з області традиційних програм в область веб додатків.

Прогноз розвитку галузі веб безпеки в 2007 році.

1. Уразливості XSS будуть поширюватися й надалі, причому будуть з’являтися і поширюватися нові типи подібних уразливостей (такі як XSS в DOM, UXSS в PDF, тощо).
2. Фішинг набуде більшого поширення та самі фішери почнуть використовувати вдосколені та нові техніки своїх атак.
3. Збільшиться кількість і різноманітність веб вірусів та хробаків.
4. Зросте кількість Ajax уразливостей та пов’язаних з ними атак.
5. Очікується подальше зростання хакерської активності.

Декілька днів тому, 07.01.2007, я знайшов Cross-Site Scripting уразливість на Офiцiйному представництві Президента України http://www.president.gov.ua - сайті Президента України. Про що найближчим часом сповіщу адміністрацію сайту.

Раніше я вже писав про Уразливість на сайті Кабінета Міністрів України та про мій аудит безпеки сайту Верховної Ради України. І тоді результати були невтішні. Ситуація з сайтом президента не набагато краща - уразливості також мають місце (зокрема, я повідомлю адміністраторів про знайдену XSS).

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

P.S.

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

19.11.2006

Продовжимо тему безпеки секюріті сайтів, яку я підняв в першому записі Безпека сайтів про безпеку.

Ось нова добірка уразливих сайтів про інформаційну безпеку:

• safe.cnews.ru
• www.securit.ru
• www.iss.net

Компаніям, які займаються проблемами безпеки, варто слідкувати і за безпекою власних сайтів. Тому що дані компанії є взірцем для інших. В подальшому я продовжу інформувати про випадки уразливостей на сайтах секюріті компаній.

Всім security проектам слід приділяти достатньо уваги власній безпеці.

10.01.2007

Ще одна добірка уразливих сайтів на тему інформаційної безпеки:

• www.fbi.gov
• www.geos-inform.com
• sb.adverman.com
• www.nist.org

Секюріті проектам слід приділяти більше уваги безпеці власних сайтів.

Поздоровляю вас з Різдвом Христовим!

У зв’язку зі святами - Новим Роком та Різдвом - пропоную подивитися мою святкову листівку на флеші.

Всіх благ!

Продовжу тему уразливостей на сайтах спецслужб (в даному випадку спецслужб США). Як раз перед Різдвом пропоную вашій увазі уразливість на сайті ЦРУ .

До раніше згаданих дір на сайтах ФБР (FBI) і АНБ (NSA), додам Cross-Site Scripting уразливість на сайті ЦРУ (CIA) - сайті Центрального Развідувального Управління США (Central Intelligence Agency) www.cia.gov, і зокрема на сайті його інформаційного відділу www.foia.cia.gov.

XSS:

• alert(document.cookie)
• alert(’XSS’)
• цікавий

Уразливість знаходиться в pdf-файлі, і вона являє собою універсальну XSS в PDF уразливість (про даний тип XSS я буду окремо розповідати).

Повідомляти адмінам ЦРУ я не стану - враховуючи що адміни сайтів спецслужб США не реагують на мої повідомлення і не виправляють уразливості най своїх сайтах. Нехай самі слідкують за власним сайтом і проводять секюріті аудити (а також слідкують за інформацією на моєму сайті). Бо дана уразливість доволі небезпечна, і чимало користувачів сайта можуть від неї постраждати (це відноситься як до сайту ЦРУ, так і до усіх інших сайтів, вразливих до цієї уразливості - ще додатково розповім про даний тип XSS атак).

Як писав деякий час тому Джеремія Гроссман в записі Top 5 signs you’ve selected a bad web application package (коментуючи повідомлення Роберта Аугера), існує список TOP5 ознак, що ви вибрали поганий веб додаток (в список експерти з безпеки додали найбільш поширені ознаки, які актуальні в наш час).

Ось п’ятірка ознак:

5. Суть процеса виправлення помилок в программі (тобто встановлення патчів) на думку виробника продукту полягає в тому, щоб відрегувати рядок X, замінівши його новим кодом.
4. Загальна кількість скачуваннь програми менша ніж її вік.
3. Власний веб додаток не використовується на сайті віробника.
2. В файлі readme вказано, що вам необхідно встановити права (chmod) 777 на деякий файл чи на директорію, щоб вони працювали.
1. Якщо в назві програми присутє слово ‘nuke’, то ви явно не в собі.

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

На секлабі пройшло цікаве опитування: “Який движок для веб сайта найбільш безпечний?”. В якому я також прийняв участь. На мою думку, найбільш безпечний, є той движок, при розробці якого приділялася достатьня (бажено посилена) увага питанням безпеки. А враховуючи те, що на інших розробників не варто розраховувати, можна лише на себе розраховувати - тому найбільш безпечним є саме власний движок.

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

Результати опитування наступні:

• Власноруч написаний движок - 44,84%
• CMS під вільними ліцензіями (Drupal, XOOPS, PHP-Nuke та інші) - 18,89%
• Не знаю - 17,63%
• CMS під пропрієтарними ліцензіями з відкритим віхідним кодом (наприклад, Бітрікс) - 10,08%
• CMS під пропрієтарними ліцензіями с закритим віхідним кодом (більшість платних CMS) - 7,81%

Більшість опитаних (майже половина) мають подібну думку. Що власний движок є найбільш безпечною основою сайта.

• Какой движок для Web сайта наиболее безопасен? (деталі)