Похакані сайти №196

20:07 19.07.2012

Після попереднього дослідження похаканих сайтів, приведу нову інформацію про взломані сайти. З числа українських сайтів.

  • http://new.zmiivrda.gov.ua (хакерами з BROTHERS TEAM) - 22.05.2012 - похаканий державний сайт, зараз сайт вже виправлений адмінами
  • http://www.gorodok-vlada.gov.ua (хакерами з iranhack security team) - 27.05.2012 - похаканий державний сайт, зараз сайт вже виправлений адмінами
  • http://tsymbaliuk.com (хакером AL.MaX HaCkEr) - 07.05.2012, зараз сайт вже виправлений адмінами, але дефейс все ще розміщений на окремій сторінці сайта
  • http://razom.cv.ua (хакером AL.MaX HaCkEr) - 07.05.2012, зараз сайт вже виправлений адмінами, але дефейс все ще розміщений на окремій сторінці сайта
  • http://dlyadoma.kiev.ua (хакером AL.MaX HaCkEr) - 07.05.2012, зараз сайт вже виправлений адмінами, але дефейс все ще розміщений на окремій сторінці сайта

Добірка уразливостей

17:27 19.07.2012

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

  • Arbor Networks Peakflow SP web interface XSS (деталі)
  • Squiz CMS Multiple Vulnerabilities (деталі)
  • Swoopo Gold Shop CMS v8.4.56 - Multiple Web Vulnerabilities (деталі)
  • Webify Product Series - Multiple Web Vulnerabilities (деталі)
  • News Script PHP v1.2 - Multiple Web Vulnerabilites (деталі)
  • Vulnerability in Mono (деталі)
  • Commentics 2.0 <= Multiple Vulnerabilities (деталі)
  • Multiple vulnerabilities in web@all (деталі)
  • Mybb 1.6.8 ‘announcements.php’ Sql Injection Vulnerabilitiy (деталі)
  • traq-2.3.5_CSRF_XSS_SQL_INjeCTION_vulns (деталі)

Сучасний стан з паролями на сайтах

22:46 18.07.2012

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

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

Від загальної кількості акаунтів таких облікових записів може бути небагато, але тим не менш вони є. Наприклад, в БД користувачів solor.da-kyiv.gov.ua, таких акаунтів було 4 (де логін співпадав з паролем). Це 7,14% від загальної кількості акаунтів, а якщо прибрати акаунти дублікати, то вийде 7,84% від загальної кількості.

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

Я давно звертаю увагу на уразливості, що дозволяють дізнаватися логіни - Information Leakage та Abuse of Functionality (Login Enumeration). В статті Виявлення логінів через Abuse of Functionality уразливості я писав на цю тему. За останні 5 років я приводив багато таких уразливостей в WordPress, Drupal та багатьох інших CMS і форумних движках, а також на багатьох сайтах. Найбільше такі дірки поширені серед форумних движків і всі розробники таких движків ігнорують їх, лише розробник IPB в 2009 році, після мого повідомлення, виправив всі такі уразливості в новій версії движка IPB 3.0.

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

Обхід захисту в Apache mod_security

20:16 18.07.2012

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

Уразливі версії: Apache mod_security 2.6.

Можливо обійти перевірки при одночасному використанні Content-Disposition: attachment і Content-Type: multipart.

Добірка експлоітів

17:20 18.07.2012

В даній добірці експлоіти в веб додатках:

  • PoC for multiple vendors ftpd (libc/glob) resource exhaustion (деталі)
  • MyBlog <=0.9.8 Multiple Vulnerabilities (Information Leakage, XSS) (деталі)
  • Pluck Local File inclusion (деталі)
  • Virtual Support Office-XP Multiple Vulnerabilities (Broken Authentication, SQL Injection, XSS, Arbitrary File Upload, FPD) (деталі)
  • GL-SH Deaf Forum <=6.5.5 Multiple Vulnerabilities (LFI, File Upload, XSS) (деталі)

Міжсайтовий скриптінг в Microsoft Dynamics AX

22:46 17.07.2012

Виявлена Cross-Site Scripting уразливість в Microsoft Dynamics AX.

Уразливі версії: Microsoft Dynamics AX 2012.

Міжсайтовий скриптінг при відображенні URL.

  • Microsoft Security Bulletin MS12-040 - Important Vulnerability in Microsoft Dynamics AX Enterprise Portal Could Allow Elevation of Privilege (2709100) (деталі)

Інфіковані сайти №127

20:15 17.07.2012

Після попереднього дослідження інфікованих сайтів, приведу нову інформацію про заражені сайти. З числа українських сайтів.

  • http://if.gov.ua - інфікований державний сайт - інфекція була виявлена 27.06.2012. Зараз сайт не входить до переліку підозрілих.
  • http://topspeed.ua - інфекція була виявлена 22.04.2012. Зараз сайт не входить до переліку підозрілих.
  • http://med-dovidka.com.ua - інфекція була виявлена 31.05.2012. Зараз сайт не входить до переліку підозрілих.
  • http://1tv.com.ua - інфекція була виявлена 19.04.2012. Зараз сайт не входить до переліку підозрілих.
  • http://viva.ua - інфекція була виявлена 22.06.2012. Зараз сайт не входить до переліку підозрілих.

Добірка уразливостей

16:28 17.07.2012

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

  • HP Business Availability Center (BAC) Running on Windows, Remote Cross Site Scripting (XSS) (деталі)
  • Jobs Portal v3.0 NetArtMedia - Multiple Web Vulnerabilities (деталі)
  • Simple Forum PHP 2.1 - SQL Injection Vulnerabilities (деталі)
  • Cells Blog CMS v1.1 - Multiple Web Vulnerabilities (деталі)
  • MYRE Real Estate Mobile 2012|2 - Multiple Vulnerabilities (деталі)
  • HP Onboard Administrator (OA), Remote Unauthorized Access, Unauthorized Information Disclosure, Denial of Service (DoS), URL Redirection (деталі)
  • Cross-Site Scripting vulnerabilities in Nagios XI < 2011R3.0 (деталі)
  • SQL injection in Serendipity (деталі)
  • Multiple vulnerabilities in TinyWebGallery (деталі)
  • Airlock WAF overlong UTF-8 sequence bypass (деталі)

Обхід Cross Origin в Google Chrome

22:47 14.07.2012

Продовжуючи розпочату традицію, після попереднього відео про хакінг баз даних і тонких клієнтів, пропоную нове відео на веб секюріті тематику. Цього разу відео про обхід Cross Origin в Google Chrome. Рекомендую подивитися всім хто цікавиться цією темою.

Google Chrome Cross Origin Bypass

В ролику демонструється Cross Origin Bypass уразливість в браузері Google Chrome. Що дозволяє виконати JavaScript код на одному сайті в контексті іншого сайта. В даному ролику JS код виконується на сайті розробника експлоіта в контексті www.google.com, з виведенням вмісту кукіса для сайта Гугла.

Атака відбувається при відвідуванні в Chrome спеціально створеного веб сайта, що містить код експлоіту. Рекомендую подивитися дане відео для розуміння векторів атак на браузери.

XSS, Redirector та CSRF уразливості в WordPress

17:21 14.07.2012

Після семи попередніх уразливостей в Akismet, ось нові дірки. У лютому, 23.02.2012, я знайшов Cross-Site Scripting, Redirector та Cross-Site Request Forgery уразливості в плагіні Akismet для WordPress. Він є core-плагіном (починаючи з версії WP 2.0), тому ці уразливості також стосуються самого WordPress. Це друга порція уразливостей в плагіні Akismet.

Раніше я вже писав про XSS, Redirector та FPD уразливості в WordPress.

XSS:

Якщо включена опція “Auto-delete spam submitted on posts more than a month old” і відправці спам коментарю для посту, який старше 30 діб, можлива XSS і Redirector атаки (and they can be conducted as on logged in admins and users, as on any visitors of the site). Вразливі всі версії Akismet з даним функціоналом (до версії 2.5.6).

Потрібно відправити POST запит http://site/wp-comments-post.php (подібно до мого попереднього експлоіту для XSS в коментарях) з вказанням заголовка Referer. Це можна зробити через Flash або інші методи.

Referer: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

На веб серверах IIS редирект відбувається через заголовок Refresh, а на інших веб серверах - через заголовок Location.

Redirector (URL Redirector Abuse):

Атака відбувається при вищенаведених умовах. Потрібно відправити POST запит http://site/wp-comments-post.php (подібно до мого попереднього експлоіту для Redirector в коментарях) з вказанням заголовка Referer. Це можна зробити через Flash або інші методи.

Referer: http://attackers_site

При цьому в останній версії Akismet 2.5.6 ці дві уразливості вже виправлені (причому приховано, без жодного згадування в readme.txt). Схоже, що це трапилося після моєї березневої чи квітневої публікації про XSS і Redirector уразливості через редиректори в WP.

CSRF:

В Akismet < 2.0.2 (WordPress < 2.0.11) взагалі не було захисту від CSRF, окрім поля введеня API key. Починаючи з версії Akismet 2.0.2 захист з'явився, але не в усьому фунціоналі.

CSRF уразливість в функції збереження конфігурації. Через POST запит до скрипта http://site/wp-admin/plugins.php ?page=akismet-key-config можна змінювати конфігурацію.

Атака спрацює лише на WP < 2.0.3 (де не було захисту від CSRF в движку) в старих версіях Akismet (таких як 2.0.2 і попередні та деяких наступних).

CSRF уразливість в функції "Check network status". При GET запиті до сторінки http://site/wp-admin/plugins.php ?page=akismet-key-config відбується запит до чотирьох серверів Akismet з кешуванням запиту.

Для відправки запитів до серверів Akismet в обхід кешування, можна відправити POST запит до цієї сторінки. При активних CSRF запитах можна створити навантаження на сервери Akismet (особливо якщо атакувати з багатьох серверів).

WordPress Akismet CSRF.html

Уразливі Akismet 2.5.6 та попередні версії та WordPress 2.0 - 3.4.1.