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

Продовжуючи тему експлоітів для PHP, пропоную вам наступну добірку.

Цього разу есплоіти в функціях glob() та ntuser_getuserlist() в PHP версії 5.2.3 та в розширенні Perl Extension.

• PHP 5.2.3 glob() Remote DoS Exploit (деталі)
• PHP 5.2.3 php_ntuser ntuser_getuserlist() Local Buffer Overflow PoC (деталі)
• PHP Perl Extension Safe_mode Bypass Exploit (деталі)

На цьому тижні, 13 та 14 жовтня, в Україні в Києві відбудеться конференція BlogCamp 2007.

BlogCamp - це конференція (або як її називають, “неконференція”) для країн СНГ і Балтії по новим медіа, блогам, Веб 2.0 и всьому, що з цим пов’язано. Про даний захід ви можете детальніше дізнатися на офіційному сайті - BlogCamp CIS and Baltics.

Я планую прийняти участь в конференції та виступити з доповіддю на тему “Безпека блогосфери” (Security of Blogosphere). Тому всіх хто зможе завітати на Блогкамп та всіх бажаючих поспілкуватися зі мною запрошую на мою доповідь на конференції. Доповідь відбудеться в суботу 13.10.2007 о 15.30.

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

12 щорічне опитування CSI (Computer Security Institute - Інститут комп’ютерної безпеки), у якому взяли участь 494 фахівця з безпеки з держустанов і приватних організацій, став важливою віхою в історії інформаційної безпеки. Уперше самою головною проблемою для себе компанії назвали загрозу, що виходить від інсайдерів, а не від вірусних атак. Так, у 2006 р. з інсайдерською загрозою зіштовхувалися 59% респондентів, а із серйозною вірусною проблемою - 52%. На третьому місці по небезпеці (50% респондентів) виявилася загроза втрати носіїв з конфіденційними даними (насамперед, ноутбуків).

Ще одним значимим підсумком опитування CSI став той факт, що середній збиток від проблем з безпекою виріс у два рази - з $168000 до $350000. Подібний ріст зафіксований уперше за останні п’ять років - до 2007 р. збиток від безпеки тільки падав. “Фахівці давно говорили про ріст складності кібератак і професіоналізму шахраїв. Однак тільки в нинішньому році цей ріст трансформувався в реальний збиток для компаній”, - заявив Роберт Річардсон, автор дослідження і директор CSI.

По матеріалам http://bin.com.ua.

В цьому році була анонсована (та вийшла перша версія) технології Silverlight. Дана технологія від Microsoft - це аналог Flash від Adobe. Новий формат і плігін для браузера, що додасть мультимедія у Веб. Флеш зараз займає лідируючі й стабільні позиції серед мультимедійних технологій в Інтернеті, але конкуренція піде на користь. Тому подивимося, що з Silverlight вийде.

Flash не виділяється високим рівнем безпеки, про що я регулярно згадувую в новинах. Останнього разу я писав про декілька уразливостей в Adobe Flash Player. І нову мультимедійну технологію від Microsoft також не омине ця участь - уразливості в ній знайдуть обов’язково, тому Silverlight відкриває нові горизонти атак.

В записі Silverlight - the New Attack Vector, автор наводить наступний цикл життя цієї технології в контексті безпеки.

Квітень - запуск Silverlight.

Травень - секюріті компанії почнуть робити заяви про те, що “Silverlight expected to be next major attack vector”.

Червень - перший секюріті патч для Silverlight випущений у Вівторок Патчів.

Липень - перша підтверджена 0-day уразливість в Silverlight.

Серпень - перший Silverlight хробак.

Вересень - користувачі Apple почнуть робити закиди Microsoft стосовно уразливостей в технології Silverlight.

На даний момент цей прогноз не відбувся повністю, у зв’язку з незначним поширенням Silverlight, але у неї все ще попереду.

Існує такий різновид уразливостей як PHP Include. В даному разі мова йде про Remote PHP Include (Remote File Inclusion, RFI). І відповідно проводяться RFI атаки з використанням скриптів (коли до сайту підключається віддалений скрипт). Для більшої ефективності, а також для маскування, подібні скрипти (переважно шели) окрім того що мають різноманітні назви та розширення (зокрема відмінні від php), також використовується тактика “зовнішнього сервера”.

Тобто не атакувати сайт з включенням скрипта зі свого сервера (що для тестування підійде, але не для реальної атаки), а включати php скрипт з іншого сайта. Це можуть бути сайти на безкоштовних хостінгах, різноманітні файл сервери, сайти де можливий аплоадінг файлів та на похаканих сайтах - де розміщується атакуючий php скрипт. Причому виконання php на даних сайтах не обов’язкове, головне щоб файл був на них розміщений, а виконання вже буде відбуватися на сайтах вразливих до RFI.

В своєму записі PHP Include Robots, RSnake навів приклад великої кількості PHP Include роботів - скриптів для проведення даних атак. Наведені скрипти можуть використовуватися для більш прихованих атак (для проведення початкових перевірок сайтів на наявність RFI уразливостей). До речі в коментарях до посту був наведений ще чималий список таких скриптів.

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

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

Питання:

1) What type of organization do you work for?
a) Security vendor / consultant (60%)
b) Enterprise (9%)
c) Government (9%)
d) Educational institution (5%)
e) Other (14%)
No Answer (2%)

2) How would you rate your technical expertise in web application security?
a) Guru (21%)
b) Expert (47%)
c) Intermediate (28%)
d) Novice (2%)
e) I am Nessus (0%)
No Answer (2%)

3) What was your background before entering the web application security field?
a) Software Development (53%)
b) IT (16%)
c) QA (0%)
d) Product/Project Management (2%)
e) I’ll never tell! (2%)
f) Other (please specify) (23%)
No Answer (2%)

4) From your experience, how many security professionals “get” web application security?
a) All or almost all (0%)
b) Most (19%)
c) About half (26%)
d) Some (49%)
e) None or very few (7%)

5) What are your thoughts about the Universal XSS vulnerability in Adobe’s Acrobat Reader Plugin?
a) Really bad (53%)
b) Bad (37%)
c) Never heard of it (2%)
d) Nothing new here, move along (5%)
e) Please stop with the FUD! (2%)

6) During your web application vulnerability assessments, how many websites where that DID NOT have at least one relatively severe vulnerability?
a) All or almost all (2%)
b) Most (2%)
c) About half (2%)
d) Some (19%)
e) None or very few (74%)

7) What’s your preferred acronym for Cross Site Request Forgery?
a) CSRF (58%)
b) XSRF (19%)
c) Neither, I prefer Session Riding (7%)
d) No preference (16%)

8) Does using Ajax technology open up new website attacks?
a) Yes (9%)
b) Yes, it adds some new things (35%)
c) No, but it increases the attacks surface (40%)
d) Nothing new here, move along (5%)
e) Other (9%)
No Answer (2%)

9) Your recommendation about using web application firewalls?
a) Two thumbs up (21%)
b) One thumb up (47%)
c) Thumbs down (12%)
d) Profane gesture (9%)
No Answer (5%)

10) How would describe the current state of web browser security?
a) Rock solid (2%)
b) Could be better (51%)
c) Swiss cheese, fix it! (44%)
No Answer (2%)

11) Name your Top 3 web application security resources.

Перша трійка:
http://ha.ckers.org
http://www.owasp.org
http://jeremiahgrossman.blogspot.com

12) What are your Top 3 tools to find vulnerabilities in websites?

Перша трійка:
Paros
Burp Suite
By Hand / My Brain

13) What are the Top 3 types of website attacks we’re most likely to see a lot more of in 2007?

Перша трійка:
Cross-Site Scripting
Cross-Site Requests Forgery
Web Worms

14) What was your information security New Year’s resolution?

Перша трійка:
Less projects, more quality
To spend more time with my wife and less time thinking about security.
Finding vulnerabilities in FireFox

15) What’s the first thing you have or plan to learn/research/try/code/write in 2007?

Перша трійка:
XSS/CSRF combo attacks
Adding embedded Ruby support to a popular hex editor to make it the Emacs of reverse engineering.
Universal XSS Worm, but only as a PoC and personal information gain.

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

Як видно з відповідей на питання 4, респонденти вважають, що не всі секюріти професіонали (і навіть лише невелика частина) розуміються на веб безпеці. Про що я також регулярно нагадую, коли пишу про дірки на секюріти сайтах. І як видно з відповідей на питання 5, більшість (як і я) вважає універсальну XSS в PDF небезпечною уразливістю. З питання 9 видно, що думки з приводу фаєрволів для веб додатків (WAF) розділилися. До речі, Джеремія серед оприлюднених цитат привів і мою, про те, що WAF зараз не дуже корисні, і що я розробив техніку обходу WAF (зокрема mod_security), про що я планую написати статтю.

З питання 6 видно, що респонденти вважають, що більшість сайтів мають серйозні уразливості. І як видно з питання 10, більшість опитаних (95%) вважає, що безпека браузерів потребує покращення. До речі, ha.ckers.org, зайнявший перше місце по результатам питання 11, є також і моїм улюбленим webappsec ресурсом. А результати питання 13 сильно перетинаються з моїми прогнозами на 2007 рік (більше XSS, фішинга та веб хробаків).

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

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

Локальні пошукові системи бувають декількох типів:

• власні скрипти (зроблені під сайт, в тому числі й безкоштовні скрипти),
• вбудовані пошукові движки в CMS,
• пошукові системи сторонніх виробників (як відомих пошукових систем, так і менш відомих вендорів).

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

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

Серед уразливих популярних локальних пошуковців я писав про наступні: PicoSearch, Яndex.Server (Free Edition та Enterprise), AltaVista local search engine, Google Custom Search Engine (що я оприлюднив в рамках MOSEB) та Google Search Appliance (а рік тому я писав про іншу XSS в Google Search Appliance).

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

Нещодавно, 25.09.2007, вийшла нова версія WordPress 2.3.

Дана версія WordPress 2.3 - це значне оновлення движка. В цьому релізі додана підтримка тегування, оповіщень про оновлення плагінів, покращене управління URL та багато іншого.

Серед нових функцій даної версії:

1. Вбудована підтримка тегування (tagging), котру можна використовувати разом з категоріями (для своїх записів). Також додані імпортери для декількох Вордпресових плагінів для підтримки тегів, щоб можна було перенести дані з них до нової системи тегів.
2. Нова система оповіщення про оновлення плагінів.
3. Покращені механізми управління URL записів та сторінок (додана підтримка канонічних URL). Що зробить сайт більш зручним як для користувачів, так і пошукових систем.
4. Нова функція очікування огляду запису для блогів, котрі ведуть декілька авторів.
5. Новий просунутий WYSIWYG функціонал.

Нові функції для розробників:

1. Повна підтримка Atom 1.0, включно з протоколом публікації.
2. Використання jQuery, який на “800% швидше”.
3. За системою тегування, котру бачать користувачі, стоїть потужна система тахономії, що додає багато гнучкості.
4. Імпортери були перероблені, для кращого використання пам’яті. І тепер можна додавати імпортери через плагіни.
5. Через хуки та фільтри тепер можна перевизначити багато функціоналу (більше ніж раніше).
6. Новий $wpdb->prepare() підхід до виконання SQL запитів.
7. Виправлено чимало багів і зроблено чимало покращень.

Деякий час тому в WordPress була виявлена Cross-Site Scripting уразливість (комбінована XSRF+XSS). Вона дозволяє через адміністратора сайта провести XSRF+XSS атаку.

Уразливість полягає в тому, що в коментарях адміністратора дозволені html теги (що дозволяє публікувати JavaScript код). І враховуючи те, що відсутня перевірка джерела запиту, можлива Cross-Site Request Forgery атака. Що дозволить атакувати адміна, для проведення XSS атаки на сайт, для розміщення в коментарях необхідного коду.

Уразлива версія WordPress 2.1.0 та попередні версії.

• Wordpress <= v2.1.0 (деталі)

Як повідомив нещодавно pdp в своєму записі IE pwns SecondLife, він виявив у відомій онлайн грі SecondLife уразливість, котра дозволяє через Internet Explorer атакувати користувачів даної гри. Що може бути використано як для отримання конфеденційної інформації про користувача, так і для викрадення його грошей (котрі наявні в його акаунті, а в цій грі фінансова складова дуже розвинена).

Уразливість доволі цікава. І вона використовує такий різновид атаки, як експлоітація URI, котра вже раніше була виявлена в IE, про що я писав, коли через IE виконувалася атака на Firefox. Тоді Mozilla випустила виправлення (причому декілька разів) для Фаєрфокса, а Microsoft не визнала вини свого браузера в цьому векторі атаки. Про експлоітацію URI я ще розповім додатково.

В даному випадку, для атаки на SecondLife через IE, використовується декілька уразливостей (URI exploitation, CSRF та Information leakage) поєднаних в одну атаку. І враховуючи, що Microsoft не візьме на себе відповідальності за їх IE “URI фічу” , то SecondLife потрібно самим виправляти їх програму.