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

Нещодавно була виявлена уразливість міжсайтового скриптінга в шаблонах до WordPress. Зокрема вразливими виявилися шаблони Blix <= 0.9.1, BlixKrieg <= 2.2 та Blixed <= 1.0.

Про XSS дірку в стандартній темі движка я вже згадував. Цього разу подібна XSS уразливість в інших шаблонах для WP.

Уразливість існує через недостатню перевірку вхідних даних у параметрі “s” скрипта index.php (в пошуці по сайту). Віддалений користувач може за допомогою спеціально сформованого запиту виконати довільний код сценарію в браузері жертви в контексті безпеки уразливого сайта.

• Межсайтовый скриптинг в различных шаблонах к WordPress (деталі)

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

Цього разу есплоіти в розширенні bz2 для PHP 5.2.3, в функції glob() в PHP 5.2.3 та обхід обмежень в PHP 5.2.0 і 4.4.

• PHP 5.2.3 bz2 com_print_typeinfo() Denial of Service Exploit (деталі)
• PHP 5.2.3 glob() Denial of Service Exploit (деталі)
• PHP 5.2.0 and 4.4 restrictions bypass (деталі)

В WordPress виявлена Shell injection уразливість. Про що я згадував нещодавно (в останній версії WordPress 2.2.1 дана уразливість була виправлена). Remote shell injection дірка наявна в додатку PHPMailer, якого використовує Вордпрес та деякі інші движки.

Уразливі версії WP 2.2 та потенційно 2.1.x (гілка 2.0.x не вразлива, томущо не використовує PHPMailer).

Дана уразливість має місце в PHPMailer 1.7, коли налаштоване використання sendmail. В цьому разі віддалений нападник може виконувати довільні шел команди за допомогою шел метасимволів в функції SendmailSend в class.phpmailer.php.

• PHPMailer command execution (деталі)
• PHPMailer 0day remote command execution (деталі)

В записі Місяць багів в PHP: після вечірки я писав, що Стефан опублікував один новий баг вже після завершення проекту Місяць багів в PHP. І от як я нещодавно дізнався, коли відвідав його сайт, він повідомив про ще один баг.

Як повідомляється на офіційному сайті Month of PHP Bugs, деякий час тому, були опубліковані деталі про одну уразливість в PHP.

• PHP ext/session Session Cookie Parameter Injection Vulnerability (деталі)

Новий afterparty баг в MOPB видався цікавим . Користувачам PHP варто слідкувати за оновленнями.

Деякий час тому в WordPress були знайдені редиректори - це такий клас уразливостей, про який я писав в статті Редиректори. Зараз розповім про один з редиректорів в WP (про два його варіанти), а пізніше розповім про інший.

Redirector:

Уразливість в скрипті wp-login.php (в двох частинах коду, тому можливі два варіанта атаки).

Основний:
http://site/wp-login.php?redirect_to=http://websecurity.com.ua&action=logout
Тільки для залогінених користувачів:
http://site/wp-login.php?redirect_to=http://websecurity.com.ua

Даний редиректор знайшов mybeNi. Уразливими є всі наявні на даний час версії WordPress <= 2.2.1. Тому всі сайти на Вордпресі вразливі до даної атаки (доки не випрявлять цю уразливість).

Рік тому, 18.07.2006, мій проект розпочав свою роботу. Так що сьогодні виповнюється рік з моменту початку офіційної роботи проекту Websecurity - Веб безпека (24.06.2006 сайт розпочав роботу, а 18.07.2006 я офіційно відкрив проект). З чим вас і себе поздоровляю .

За цей час було зроблено чимало (зокрема був проведений MOSEB) і ще багато чого заплановано. Багато цікавого ще попереду, тому слідкуйте за новинами.

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

Оновив сьогодні тест з веб безпеки, в якому ви можете перевірити свої знання з веб безпеки. Тестування базуєтья на моїй системі тестування FlashTestSystem.

В новій версії додав 10 нових запитань, зокрема по третьому та четвертому розділу мого Посібника з безпеки. Тепер у тесті 20 запитань на web security тематику (котрі базуються на перших чотирьох розділах мого посібника).

Вдалого тестування .

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

Ось самі останні експлоіти та уразливості в IPB (для 2.1.x та 2.2.x версій движка):

• Debug Mode password change vulnerability Affects Invision Power Board 2.0.0 to 2.1.7 (деталі)
• IPB (Invision Power Board) 2.1.X and 2.2.X Full Path Disclusure (деталі)
• Межсайтовый скриптинг в Invision Power Board (деталі)

Позавчора Джеремія в своєму в записі First multi-site XSS WebMail Worm (PoC) повідомив про те, що з’явився перший мультидоменний вебпоштовий XSS хробак.

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

На сайті автора хробака - A proof of concept of a XWW - cross webmail worm, наводиться опис коду (PoC) даного XSS хробака. Сам код нешкідливий, він є лише демонстрацією можливості створення реальних вебпоштових XSS вірусів.

До речі, на сайті автора також є відео демонстрація роботи його хробака . Доволі цікаве відео.

Три дні тому я знайшов уразливість в сервері Apache, коли досліджував безпеку одного веб сайта. Cross-Site Scripting уразливість на сторінці з 404 помилкою - це сторінка 404 Not Found, котра виводиться у випадку, коли запитана сторінка сайта не існує.

XSS:

В URL задається неіснуюча сторінка сайта, адреса якої містить необхідний код:

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

Уразливим є Apache 2.0.54 (Debian GNU/Linux) Server.

Окрім Cross-Site Scripting атаки, при подібній уразливості також можлива атака Content Spoofing (з метою фішингу).

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