Архів для категорії 'Новини сайту'

Уразливості в Yandex-Direct

23:30 15.02.2007

18.11.2006

Деякий час тому (у вересні) я знайшов XSS уразливість на itnews.com.ua. Після додаткового досліження вияснилось, что окрім власної XSS уразливісті на даному сайті, є також ще одна уразливість (Cross-Site Scripting) - в коді Яндекс-Директ.

Про даний тип уразливостей я вже згадув в записі Хакінг сайту через уразливості в коді зовнішніх систем (подібні уразливості мають місце і в кодах інших систем, в тому числі й систем контекстної реклами, про що я ще напишу додатково). Детальна інформація про дану уразливість з’явиться пізніше (одразу за інформацією про основну XSS уразливість на itnews.com.ua).

Яндексу потрібно слідкувати за використанням кода власної системи контекстної реклами (і не допускати подібних ситуацій).

15.02.2007

Cross-Site Scripting уразливість в Яндекс-Директ коді (XSS в DOM).

На веб сторінці з кодом даної системи контекстної реклами, наприклад на сторінці з пошуком по сайту (як це було на itnews.com.ua), в будь-якому з передаваємих скрипту параметрів (або навіть в усіх параметрах) може бути уразливість, наприклад в параметрі page. Якщо він не обробляється відповідним чином.

XSS в DOM:

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

XSS уразливості в WordPress 2.0

21:49 14.02.2007

В листопаді минулого року (03.11.2006) я знайшов Cross-Site Scripting уразливості в движку WordPress 2.0. Дані уразливості зокрема я знайшов на сайті www.mozilla-team.org.ua (про що я писав нещодавно), адмінам якого я повідомив, і вони працюють над виправленням (планують оновити движок на більш нову версію).

Уразливими є версії WordPress 2.0 та потенційно 2.0.1 і 2.0.2. WP 2.0.3 вже не вразливий. Як і всі наступні версії WordPress: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1 (нещодавно як раз вийшов WordPress 2.1).

XSS:

Уразливості в файлі wp-register.php.

POST запит на сторінці http://site/wp-register.php:

"><script>alert(document.cookie)</script>В полях: Ім’я користувача та E-Mail.

Це лише деякі з уразливостей в движку WordPress, що були в попередніх версіях движка, які я не використовував (сам почав використовувати WP з версії 2.0.3), але котрі знаходив на різних сайтах в Мережі. І це окрім тих уразливостей, які я знайшов у наступних версіях движка, про які я писав: Численні уразливості в WordPress, Нові уразливості в WordPress, Чергові уразливості в WordPress.

Думай безпечно

19:38 09.02.2007

Пропоную вам подивитися один цікавий (і забавний) відеоролик про безпеку в Інтернет - Думай безпечно (Think Security). В цьому ролику йдеться про різні загрози, які можуть вас торкнутися з Інтернету, і про те що з цим треба боротися.

Think Security

Дане відео розроблене компанією Microsoft, яка дуже піклується про вашу безпеку ;-) . Цим креативом Майкрософт вам намагається натякнути, що в Інтернеті небезпечно, але вони подбають про вас і ваших дітей (якщо раніше вас не похакають зловмисники).

Використання AFLAX для веб атак

20:28 05.02.2007

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

В своєму записі AFLAX and something more Pdp розповідає про такий варіант атак, як атака через AFLAX. Перша версія якого вийшла в минулому році.

AFLAX представляє собою фреймворк для інтеграції JavaScript та Flash. І окрім додаткових плюсів для веб розробників, він також несе в собі нові ризики пов’яазані з бепекою. Потенційно зловмисники можуть використати AFLAX (Flash + JavaScript) для нового напрямку веб атак. Використовуючи сильні сторони обох мов (AS та JS) і технологій, та обходячи деякі обмеження кожної з мов - для проведення нових і більш ефективних атак.

Веб 2.0 окрім позитивних надбань, несе в собі й деякі негативні, зокрема нові технології (та їх сімбіози) несуть в собі додаткові ризики безпеки. З якими нам прийдеться зіштовхнутися.

Чергові уразливості в WordPress

22:50 31.01.2007

До вже згаданих мною уразливостей в WordPress (Численні уразливості в WordPress та Нові уразливості в WordPress) та його плагінах, про що я вже неодноразово писав, розповім про нові уразливості в цьому движку.

Раніше я писав про уразливості в WordPress, які й знайшов в серпні, вересні та жовтні. Зараз я розповім про уразливості які я знайшов в движку в листопаді.

У листопаді, 15.11.2006, я знайшов численні уразливості: 36 Cross-Site Scripting уразливостей (в адмінці WordPress). Розробникам WP я вже повідомив про них. З часом повідомлю деталі про дані уразливості.

До зазначених XSS вразливий WP до версії 2.0.5 включно. В останніх версіях (2.0.6 та 2.0.7, що вийшла нещодавно) дані уразливості вже виправлені.

DoS в Internet Explorer 6 і Firefox

20:46 28.01.2007

Тест для вашого браузера. Даний експлоіт виконує DoS атаку на Internet Explorer 6 та Firefox.

Дана уразливість пов’язана з пошкодженням пам’яті в Microsoft Internet Explorer. І уразливими є Internet Explorer версії 6.0.2800.1106 (і можливо попередні).

В результаті роботи експлоіта браузер підвисає (тобто DoS атака). Як я протестував, на моєму Internet Explorer 6 під Windows XP SP2 цей експлоіт не працює (хоча IE і напрягяється, але не зависає). Тому він працює в IE на Windows без SP2, де IE зависає. Mozilla не зависає (спрацювує захист), а от Firefox (старі версії) зависає. Тобто цей експлоіт виявився DoS атакою одразу для двох брузерів ;-) .

Протестувати Internet Explorer 6 і Firefox.

Останній тест для браузерів (зокрема Internet Explorer 6) був DoS атака на Internet Explorer 6, з яким ви також можете ознайомитися.

Небезпечний інтернет серфінг

19:36 26.01.2007

Розповім вам про один цікавий відеоролик про небезпечний інтернет серфінг. Ось ходите ви по сайтах і раз - ваш браузер вибило (DoS атака), або навіть гірше. Або преставте, набираєте ви адресу відомого сайта, наприклад пошукової системи, і випадково зробили помилку в слові (що нерідко трапляється). І в результаті ви потрапляєте зовсім на інший сайт, а там таке… :lol:

Як розповів Pdp в своєму записі, може трапитися така ситуація, коли людина набирала адресу Гугла і помилилася на одну літеру, після чого потрапила на небезпечний сайт. І далі її комп’ютеру не повезло :-) .

What happens to Your Computer if you Мisspell Google.com

Так що подивіться це цікаве відео. І спробуйте не робити помилок в адресах сайтів і зокрема в адресі Google.

Безпека IPB №2

22:33 24.01.2007

Тема безпеки 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 (листопад)

21:41 21.01.2007

Раніше я вже писав про жовтневий 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% опитаних секюріті спеціалістів взагалі не використовують (або дуже рідко) комерційні сканери безпеки (зокрема я не використовую подібні сканери, і в цьому наші позиції співпали).

Визначення IIS

20:50 19.01.2007

В своєму записі 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) може знадобитися при аудиті безпеки окремих сайтів, або навіть окремих веб серверів в локальній мережі чи в Інтернет.