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

Три дні тому, 15.07.2008, вийшла нова версія WordPress 2.6.

Дана версія WordPress 2.6 - це значне оновлення движка (яка продовжила багато тенденцій розпочатих в 2.5). В цій версії WP додана велика кількість нововведень та покращень.

Головні нововведення:

• Post Revisions: Wiki-like tracking of edits.
• Press This!: Post from wherever you are on the web.
• Shift Gears: Turbo-speed your blogging.
• Theme Previews: See it before your audience does.

Нові функції для користувачів та покращення:

1. Word count.
2. Image captions.
3. Bulk management of plugins.
4. A completely revamped image control.
5. Drag-and-drop reordering of Galleries.
6. Plugin update notification bubble.
7. Customizable default avatars.
8. You can now upload media when in full-screen mode.
9. Remote publishing via XML-RPC and APP is now secure (off) by default.
10. Full SSL support in the core, and the ability to force SSL for security.
11. You can now have many thousands of pages or categories with no interface issues.
12. Ability to move your wp-config file and wp-content directories to a custom location, for “clean” SVN checkouts.
13. Select a range of checkboxes with “shift-click”.
14. You can toggle between the Flash uploader and the classic one.
15. A number of proactive security enhancements, including cookies and database interactions.
16. Stronger better faster versions of TinyMCE, jQuery, and jQuery UI.

Також в версії 2.6 виправлено біля 194 багів.

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

Питання:

1) What type of organization do you work for?
a) Security vendor / consultant (53%)
b) E-Commerce (9%)
c) Healthcare (0%)
d) Financial (9%)
e) Government (14%)
f) Educational institution (5%)
g) Other (please specify) (9%)

2) From your experience, how many web developers “get” web application security?
a) All or almost all (0%)
b) Most (0%)
c) About half (19%)
d) Some (59%)
e) None or very few (22%)

3) What is your technical understanding of DNS-Pinning and Anti-DNS-Pinning?
a) Strong (26%)
b) Some familiarity (60%)
c) I’ve heard of these (12%)
d) Eh? (2%)

4) Do you click on links sent in email?
a) Never (27%)
b) Sometime (68%)
c) Always, I fear no link (5%)

5) Your recommendation about using web application firewalls?
a) Two thumbs up (13%)
b) One thumb up (59%)
c) Thumbs down (15%)
d) Profane gesture (10%)
e) No Answer (3%)

6) From your experience, what is the typical risk level of Response Splitting exploitability?
a) High (23%)
b) Medium (34%)
c) Low (43%)

7) How has the security of the average website changed in the last 12 months?
(Take into consideration new attack techniques and defense measures)
a) Way more secure (0%)
b) Slightly more secure (33%)
c) Same (38%)
d) Worse (29%)
e) No idea (0%)

8) Do you plan to attend BlackHat Vegas of Defcon this year?
a) Yes (23%)
b) No (51%)
c) Maybe (26%)

9) Are hacking contests, like Hack a Mac at CanSecWest, a good idea security-wise for the industry?
a) Yes (58%)
b) No (11%)
c) Somewhere in between (please describe: 1-2 sentences)

10) What is your stage of web application security grief?
a) Denial (5%)
b) Anger (8%)
c) Bargaining (27%)
d) Depression (14%)
e) Acceptance (46%)

11) What is the most secure website industry vertical you encounter during vulnerability assessments?
a) Financial (47%)
b) E-Commerce (6%)
c) Healthcare (6%)
d) Government (0%)
e) Adult Entertainment (11%)
f) Gaming/Gambling (3%)
g) Don’t know (14%)
h) Other (please specify) (14%)

12) From your experience, what development technology is present in the most secure websites?
a) PHP (3%)
b) Java (28%)
c) ASP Classic (0%)
d) .Net (31%)
e) Cold Fusion (0%)
f) Perl (0%)
g) Don’t know (19%)
h) Other (please specify) (19%)

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

20.06.2008

Продовжу тему безпеки секюріті сайтів, яку я піднімав в попередніх записах Безпека сайтів про безпеку, 2, 3, 4, 5, 6, 7, 8 та 9.

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

• secnull.org
• www.protectwebform.com
• www.saferinternet.org

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

10.07.2008

Ще одна добірка уразливих секюріті сайтів:

• www.astalavista.com
• www.cctvua.com
• bezpeka-shop.com

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

В березні минулого року була виявлена уразливість міжсайтового скриптінгу в WordPress. Уразливість дозволяє віддаленому користувачу виконати XSS напад.

Вразливим є параметр year в функції wp_title, що виводить заголовок сторінки.

XSS:

http://site/?year=%3C/title%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Вразливі версії WordPress: для 2.0.x до 2.0.10, для 2.1.x до 2.1.3. В нових версіях WP уразливість вже виправлена.

• WordPress XSS under function wp_title() (деталі)

Як написав Steven Murdoch в своєму пості Google as a password cracker, Гугл можна використовувати для взлому паролів. В даному випадку він використав Google для взлому MD5 хеша.

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

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

Бази Даних MD5 хешів з можливістю пошуку по БД відомі вже давно. А це інший варіант цього ж підходу. Тільки в даному випадку базою виступає Інтернет, а пошук відбувається в Гуглі та інших пошуковцях.

Як повідомив RSnake в своєму записі Iframe HTTP Ping, існує можливість пінгування сайтів за допомогою iframe. Дана можливість існує лише в браузері Firefox.

Пінгування можливе за допомогою onload метода тега iframe. Даний трюк спрацьовує лише в Firefox, бо IE завжди активує onload метод, незалежно від того завантажилась сторінка в іфреймі чи ні (тобто чи активний сервер чи ні). Як я перевірив, в моєму Firefox даний метод працює, а от в Mozilla ні. Й враховуючи, що в мене в Мозілі налаштоване спеціальне виведення повідомлень про помилки, я бачу, що ця поведінка браузера, яка дозволяє пінгувати через іфрейм, залежить від налаштувань повідомлення браузера про помилку завантаження сторінки.

Можете протестувати дану можливість (в IE та Firefox): Iframe HTTP Ping PoC.

В травні була виявлена Code Execution уразливість в WordPress. Що дозволяє завантажити на сайт php-файл (shell). Вразливі всі версії WordPress по 2.5.1 включно.

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

• Wordpress Malicious File Execution Vulnerability (деталі)

В описі уразливості наводяться наступні можливості виконання коду:

1. Через аплоадер файлів, що є на сторінках створення запису та створення сторінки, можна завантажити php скрипт.

2. Через редактор плагінів. Якщо за допомогою аплоадера php скрипт не вдається завантажити (через обмеження), то можна відреагувати будь-який плагін і додати до нього потрібний PHP код.

До вищезгаданих можливостей виконання коду я додам ще дві (про які забули дані дослідники):

3. Через редактор файлів, яким можна відредагувати php-файли движка (як файли плагінів, так й інші).

4. Через теми. Які також можна відредагувати у редакторі тем (їх php-файли).

Для проведення даної атаки потрібно мати права адміна, тому ризик від безпосередньо даного функціоналу низький (бо спочатку потрібно отримати адмінські права). Але дана уразливість нагадує, що потрібно слідкувати за безпекою власного сайта на Вордпресі. Бо якщо нападник отримає доступ до адмінки (наприклад, через XSS уразливість), то він зможе використати Code Execution функціонал движка.

Що може бути використано для отримання доступу до інших адмінок на сайті (якщо на сайті є інші системи, окрім WP), або до інших сайтів розміщених на одному сервері. Останній варіант був добре продемонстрований на прикладі взлому Бігміра в 2007 році, про який я розповідав в своїй доповіді Безпека Блогосфери.

Два дні тому я виявив DoS уразливість в Internet Explorer 6. DoS я виявив, як раз коли перевіряв DoS уразливість в Microsoft Internet Explorer 7 (тому вона має місце в IE6 та IE7). І на основі даного PoC я розробив свій експлоіт, який ви можете використати в якості теста для вашого браузера.

В результаті роботи експлоіта браузер вилітає. Даний експлоіт працює на Internet Explorer 6 під Windows XP SP2 і повинен працювати під Internet Explorer 7 (виходячи з інформації автора PoC, з якого я зробив свій експлоіт).

Протестувати:

Internet Explorer 6 & 7 DoS.html

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

В лютому, 26.02.2008, я знявся для телепередачі телеканалу Інтер. І спеціально для мого виступу на Інтері я розробив презентацію про фішинг-атаки через Інтернет.

Презентація доступна на українській та російській мові:

Фішинг-атаки через Інтернет на користувачів банків

Фишинг-атаки через Интернет на пользователей банков

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

В своєму пості The Danger of Pre-canned RFI Exploits, RSnake підняв цікаву тему. Готові RFI експлоіти можуть бути небезпечними (тим чи іншим чином). І якщо бути не дуже уважним, і особливо якщо той, хто запускає експлоіт не сильно розбирається в RFI уразливостях та експлоітах для них, то можна зіштовхнутися з деякими проблемами.

Аналізуючи коди різних експлоітів, як для RFI, так й інших уразливостей, мені доводилося зіштовхуватися з деякими “бонусами”, що залишили їх розробники . В своєму пості RSnake зупинився саме на Remote File Include експлоітах. Він наводить три приклади, розглядаючи потенційні проблеми, котрі можуть виникнути при необережному використанні експлотів.

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