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

Пропоную вашій увазі добірку цікавих новин на тему безпеки.

За повідомленням news.bcm.ru, нещодавно стало відомо, що Google AdWords рекламує заражені сайти. Фахівці компанії Symantec з’ясували, що з якоїсь причини Google не перевіряє сайти рекламодавців на віруси в автоматичному режимі. Це призводить до розміщення даних інфікованих сайтів в рекламних посиланнях в результатах пошуку Гугла (що дозволяє обійти блокування інфікованих сайтів в результатах пошуку).

За повідомленням techlabs.by, PandaLabs опублікувала прогнози на 2010 рік. Антивірусна лабораторія PandaLabs в кінці грудня представила свій аналітичний анонс того, що нам варто очікувати в 2010 році. Найбільш змістовні прогнози стосуються Windows 7, мобільних телефонів, Mac та кібер-війн.

За повідомленням biz.liga.net, Google платить по $500 за кожну знайдену в Chrome уразливість. За кожну знайдену в браузері Google Chrome уразливість розробники обіцяють заплатити до $500, а за виявлення дійсно серйозних уразливостей нагорода складе до 1337$. При цьому повідомлення про дірки можуть стосуватися як самого браузера, так і операційної системи, випущеної на базі Chrome, а також плагинів, що входять в офіційну збірку.

Даний підхід Google перейняла у Mozilla, яка також платить $500 за кожну знайдену в їх браузері уразливість (вже декілька років). При цьому я раджу як Google, так і Mozilla замість популізму про плату за знайдення дірок, повиправляти всі ті уразливості в їх браузерах, про які я повідомив їм в 2008-2009 роках, що вони проігнорували і так і залишили свої браузери дірявими.

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

• http://montagnik.com.ua - інфекція була виявлена 14.01.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 1 раз протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
• http://aviris.com.ua - інфекція була виявлена 01.02.2010. Зараз сайт не входить до переліку підозрілих. Зато входить до переліку підозрілих його піддомен http://www.shop.aviris.com.ua.
• http://robotazp.com.ua - інфекція була виявлена 29.11.2009. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 7 разів протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
• http://tmcltd.com.ua - інфекція була виявлена 29.11.2009. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 2 рази протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
• http://stalservise.com - інфекція була виявлена 01.02.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 1 раз протягом останніх 90 днів. Зараз сайт входить до переліку підозрілих.

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

• onepound shop 1.x products.php SQL Injection Vulnerability (деталі)
• Admin News Tools 2.5 (fichier) Remote File Disclosure Vulnerability (деталі)
• ILIAS LMS <= 3.9.9/3.10.7 Arbitrary Edition/Info Disclosure Vulns (деталі)
• Infinity <= 2.0.5 Arbitrary Create Admin Exploit (деталі)
• Greenwood Content Manager 0.3.2 Local File Inclusion Exploit (деталі)
• PHPGenealogy 2.0 (DataDirectory) RFI Vulnerability (деталі)
• ZenPhoto 1.2.5 Completely Blind SQL Injection Exploit (деталі)
• dB Masters Multimedia’s Content Manager 4.5 SQL Injection Vulnerability (деталі)
• Sguil/PADS SQL Injection / Server Crash Vulnerability (деталі)
• (’dest’) Blind (SQLi) EXPLOIT Kjtechforce mailman Beta-1 (деталі)

Виявлене цілочислене переповнення в mod_proxy під Apache.

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

Цілочислене переповнення, що приводить до переповнення динамічного буфера при розборі відповіді сервера в кодуванні chunked.

• Mod_proxy from apache 1.3 - Integer overflow which causes heap overflow (деталі)

Як я вже писав неодноразово, ПриватБанк погано слідкує за безпекою власних сайтів, що добре видно по численним уразливостям на www.privatbank.ua та www.blog.privatbank.ua, що я знаходив. А також нещодавно я писав про захист персональних даних в ПриватБанку, де згадав про те, як даний банк допускає витоки персональних даних своїх клієнтів. І з часом я напишу про нові дірки на сайтах ПБ.

До вищенаведеного розповім одну історію, про яку дізнався в грудні 2009 року. В грудні я розпочав надавати послуги по обміну WebMoney <-> LiqPAY, виводу WebMoney <-> Visa <-> та виводу WebMoney <-> Приват24. І на початку грудня мій друг пішов в ПриватБанк, щоб відкрити валютний рахунок для використання в даному проекті.

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

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

І ще розповім одну історію про ПриватБанк, цього разу про акцептацію чеків в LiqPAY.

На офійіному сайті LiqPAY стосовно прийому чеків (Гугла та інших) нічого не згадується про комісію (про існування якої, в тому числі й в ПриватБанку, я знаю з власного досвіду переведення чеків в готівку). Лише заявляється, що “у день перевірки оригіналу чека зазначена в ньому сума зараховується на ваш рахунок”. Але це не відповідає дійсності. Бо зазначену в чеці суму не зарухують із-за наявності комісії банку, яку віднімуть з суми чеку, тому зарахована сума буде меншою.

Я вияснив комісію банку по акцептації чеків в LiqPAY (в Приват24 розцінки ті самі):

до 1000 доларів - тільки 3% (мінімум 20 грн.),
від 1000 до 10000 доларів - $24 + 3%,
від 10000 до 50000 доларів - $44 + 3%.

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

• Phorum : Permanent Cross-Site Scripting Vulnerabilities (деталі)
• New python-dns packages fix DNS response spoofing (деталі)
• Kaminsky DNS Cache Poisoning Flaw Exploit (деталі)
• New pdns-recursor packages fix predictable randomness (деталі)
• Multiple Cisco Products Vulnerable to DNS Cache Poisoning Attacks (деталі)
• DNS vulnerability impact on the libc stub resolver (деталі)
• Drupal 6 Date/Calendar XSS Vulnerability (деталі)
• Joomla! < 1.5.12 Multiple Full Path Disclosure vulnerabilities (деталі)
• CodeIgniter Global XSS Filtering Bypass Vulnerability (деталі)
• GMAIL-LITE Arbitrary File Upload 0.10 <= (деталі)

Кеш пошукових систем може бути корисним інструментом в умілих руках. Існує чимало можливостей використання кешу для хакерів.

Можливості кешу пошуковців:

1. Пошук уразливостей сайта в кеші.
2. Пошук уразливостей сайта в сніпеті.
3. Немає записів в логах сайта.
4. Обхід обмежень на доступ до сайта.
5. Наявність уразливостей в кеші.
6. Завжди можна отримати інформацію з сайта.
7. Визначення часу, коли сайт працював востаннє.
8. Визначення часу, коли сайт був взломаний.
9. Розповсюдження шкідливого коду.

Пошук уразливостей сайта в кеші.

В кеші пошуковців можна знайти уразливості сайта, наприклад Full path disclosure та інші Information Leakage уразливості, що вже були виправлені на сайті. Зокрема подібну уразливість я виявив на www.stat24.com.ua.

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

Пошук уразливостей сайта в сніпеті.

В сніпетах пошуковців (дані з кеша, що виводяться в результах пошуку) можна знайти уразливості сайта, наприклад Full path disclosure та інші Information Leakage уразливості, що вже були виправлені на сайті.

Немає записів в логах сайта.

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

Обхід обмежень на доступ до сайта.

Якщо для вас обмежений доступ до сайта (по IP), але дозволений доступ для ботів пошуковців, то можна дістати інформацію з кеша пошуковця.

Наявність уразливостей в кеші.

В самому кеші пошукових систем також можуть бути уразливості. Зокрема я знаходив XSS уразливість в Яндексі, що мала місце в кеші пошуковця.

Завжди можна отримати інформацію з сайта.

Можна отримати інформацію з сайта навіть якщо він в даний момент не працює (зовсім перестав працювати чи тимчасово, наприклад в результаті атаки).

Визначення часу, коли сайт працював востаннє.

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

Визначення часу, коли сайт був взломаний.

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

Розповсюдження шкідливого коду.

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

28.08.2009

Нещодавно, 26.08.2009, я знайшов Full path disclosure, SQL Injection та Cross-Site Scripting уразливості в системі Hydra Engine. Це українська CMS. Дані уразливості я виявив на одному сайті, де використовується даний движок. Про що найближчим часом повідомлю розробникам.

Детальна інформація про уразливості з’явиться пізніше. Спочатку повідомлю розробникам системи.

30.01.2010

Full path disclosure:

http://site/search/’/

SQL Injection:

http://site/search/'%20and%20version()%3E5--%20/

XSS:

http://site/search/'1%3Cbody%20onload=alert(document.cookie)%3E/

Дані уразливості виправлені. Але виправлені неякісно, тому всі три уразливості знову працюють при невеликій зміні коду. Про що я вже повідомив розробнику Hydra і він працює над їх виправленням.

Уразлива версія Hydra Engine 1.0.

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

• Ebay Clone 2009 Multiple SQL Injection Vulnerabilities (деталі)
• Opial 1.0 Arbitrary File Upload/XSS/SQL Injection Vulnerabilities (деталі)
• d.net CMS Arbitrary Reinstall/Blind SQL Injection Exploit (деталі)
• Censura 1.16.04 (bSQL/XSS) Multiple Remote Vulnerabilities (деталі)
• Php AdminPanel Free version 1.0.5 Remote File Disclosure Vuln (деталі)
• Traidnt UP 2.0 Remote Blind SQL Injection Exploit (деталі)
• Mobilelib Gold v3 Local File Disclosure Vulnerability (деталі)
• Virtualmin < 3.703 Multiple Local/Remote Vulnerabilities (деталі)
• DJ Calendar (DJcalendar.cgi TEMPLATE) File Disclosure Vuln (деталі)
• Blind (SQLi) EXPLOIT Online Grades & Attendance v3.2.6 (деталі)

У червні, 15.06.2009, я знайшов Insufficient Anti-automation уразливість на сайті http://www.google.com. Подібна уразливість також є на http://www.google.com.ua, як і на інших регіональних доменах Гугла.

Раніше я вже писав про уразливості на www.google.com (в тому числі й про інші Insufficient Anti-automation уразливості). Зазначу, що подібні уразливості поширені на сайтах Google і з часом компанія їх виправляє (зокрема додає капчі), як й інші дірки. Але їх все ще вистачає у Гугла.

Insufficient Anti-automation:

http://www.google.com/quality_form

В даній формі немає захисту від автоматизованих запитів (капчі).