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

29.08.2009

У січні, 09.01.2009, я знайшов Full path disclosure, Insufficient Anti-automation та Cross-Site Scripting уразливості на проекті http://zhelem.com. Про що найближчим часом сповіщу адміністрацію сайта.

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

09.03.2010

Full path disclosure:

http://zhelem.com/cgi-bin/nb/admin/index.php?lang=1

http://zhelem.com/cgi-bin/nb/admin/pwlost.php?lang=1

http://zhelem.com/cgi-bin/nb/admin/usered.php?lang=1&mode=comment&input_entrynr=44&entrylang=en

Insufficient Anti-automation:

http://zhelem.com/cgi-bin/nb/admin/usered.php?lang=en&mode=comment&input_entrynr=44&entrylang=en

Логін і пароль фіксовані та задані на сторінці.

XSS:

• alert(document.cookie)
• alert(document.cookie)
• цікавий
• html включення

Дані уразливості досі не виправлені.

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

• Tenrok 1.1.0 (UDD/RCE) Multiple Remote Vulnerabilities (деталі)
• Portel v2008 (decide.php patron) Blind SQL Injection Vulnerability (деталі)
• OpenNews 1.0 (SQLI/RCE) Multiple Remote Vulnerabilities (деталі)
• AccessoriesMe PHP Affiliate Script 1.4 (bSQL-XSS) Multiple Vulns (деталі)
• LM Starmail 2.0 (SQL Injection/File Inclusion) Multiple Vulnerabilities (деталі)
• TYPO3 CMS 4.0 (showUid) Remote SQL Injection Vulnerability (деталі)
• PHP Script Forum Hoster (Topic Delete/XSS) Multiple Vulnerabilities (деталі)
• Typing Pal <= 1.0 (idTableProduit) SQL Injection Vulnerability (деталі)
• Logoshows BBS 2.0 (forumid) Remote SQL Injection Vulnerability (деталі)
• Novell Netware 6.5 (ICEbrowser) Remote System Denial of Service Exploit (деталі)

У серпні, 18.08.2009, я виявив Cross-Site Request Forgery, Full path disclosure та Denial of Service уразливості в Mantis (MantisBT). Уразливості виявив на одному сайті, який використовує дану систему. Про що найближчим часом повідомлю розробникам.

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

Давно хотів розповісти про цей аспект роботи з Google. Ще в 2007 році Гугл ввела систему захисту від автоматизованих запитів в своій пошуковій системі. І дана система захисту від автоматизованих запитів в Гуглі потребує покращення.

Звичайно подібна система дозволяє Гуглу боротися з різними програмами, які намагаються використовувати їх пошукову систему для власних пошуків. Як різними інтернет сервісами, так і вірусами та хробаками. Ті сайти, які потребуватимуть легально використовувати пошукові можливості Гугла, можуть отримати від компанії власний ключ Google Search API.

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

Ось приклад роботи даної системи від trovich.

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

10.11.2009

Виявлена можливість впровадження даних в SSL в Apache.

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

Можливість підміни даних пов’язана з переузгодженням протоколу без перевстановлення з’єднання.

• Vulnerabilitiy in Apache (деталі)

08.03.2010

Додаткова інформація.

Виявлена можливість впровадження даних в SSL в багатьох інших додатках окрім Apache.

• TLS Protocol Session Renegotiation Security Vulnerability (деталі)
• TLS Renegotiation Vulnerability: Proof of Concept Code (Python) (деталі)
• Vulnerabilitiy in proftpd (деталі)
• TLS / SSLv3 vulnerability explained (New ways to leverage the vulnerability) (деталі)
• TLS / SSLv3 vulnerability explained (DRAFT) (деталі)
• Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability (деталі)

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

• EMC Dantz Retrospect 7 backup Client PlainText Password Hash Disclosure Vulnerability (деталі)
• EMC Dantz Retrospect 7 backup Client 7.5.116 Remote Memory corruption Vulnerability (деталі)
• EMC Dantz Retrospect 7 backup Server Authentication Module Weak Password Hash Arithmetic Vulnerability (деталі)
• EMC Dantz Retrospect 7 backup Client 7.5.116 NULL-Pointer reference Denial of Service Vulnerability (деталі)
• Jetty Persistent XSS in Sample Cookies Application (деталі)
• Remote File Inclusion In AIOCP (деталі)
• IronPort Encryption Appliance / PostX and PXE Encryption Vulnerabilities (деталі)
• Docebo Multiple SQL-Injection Vulnerabilities (деталі)
• vBulletin - Multiple Versions - Cross Site Script Redirection (деталі)
• DreamPoll 3.1 Vulnerabilities (деталі)

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

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

І нещодавно, 03.03.2010, я виявив, що tinyurl.com почав активно використовуватися для поширення malware. Тому що Гугл виявив інфекцію на даному сайті, зокрема в його редиректорах (подібне використання tinyurl.com могло бути й раніше, але лише нещодавно я це виявив).

Це добре, що Google почав перевіряти на інфікованість і сервіси редирекції. Зокрема на tinyurl.com Гугл виявив 363 редиректори, з яких на 112 була виявлена підозріла активність за останні 90 днів. Частина сайта tinyurl.com була внесена до переліку сайтів із підозрілою активністю 7 разів протягом останніх 90 днів і за цей час tinyurl.com був посередником зараження 52 сайтів.

Що цікаво, TinyURL почали звертати увагу на використання їхнього сервісу для атаки на користувачів, і почали попереджати про можливість небезпеки при редирекції через них на деякі URL (потенційно вони можуть співробітничати з тим же Гуглом). Вони виводять сторінку “Warning - this URL may be harmful” з повідомленням про небезпеку даної адреси і пропонують користувачеві, якщо він бажає, самому перейти по лінці.

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

10.07.2009

У жовтні, 01.10.2008, я знайшов SQL Injection, SQL DB Structure Extraction та Cross-Site Scripting уразливості на проекті http://www.a-counter.com. Про що найближчим часом сповіщу адміністрацію проекту.

Раніше я вже писав про уразливість на www.a-counter.com.

Детальна інформація про уразливості з’явиться пізніше.

06.03.2010

SQL Injection:

http://www.a-counter.com/cgi-bin/ratecat?code=%22'%20or%20version()=4.1%20or%201='

SQL DB Structure Extraction:

http://www.a-counter.com/cgi-bin/ratecat?code=’%221

XSS:

• alert(’XSS’)

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

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

• Blink Blog System (Auth Bypass) SQL Injection Vulnerability (деталі)
• Payment Processor Script (shop.htm cid) SQL Injection Vulnerability (деталі)
• elgg <= 1.5 (/_css/js.php) Local File Inclusion Vulnerability (деталі)
• MOC Designs PHP News 1.1 (Auth Bypass) SQL Injection Vulnerability (деталі)
• In-Portal 4.3.1 (index.php env) Local File Inclusion Vulnerability (деталі)
• Perl$hop e-commerce Script Trust Boundary Input Parameter Injection (деталі)
• Shopmaker CMS 2.0 (bSQL/ LFI) Multiple Remote Vulnerabilities (деталі)
• MyBackup 1.4.0 (AFD/RFI) Multiple Remote Vulnerabilities (деталі)
• Irokez CMS 0.7.1 Remote SQL Injection Vulnerability (деталі)
• FlatPress 0.804-0.812.1 Local File Inclusion to Remote Command Execution vulnerability exploit (деталі)

Як я нещодавно згадував, в цьому році житель Луцька дістав базу даних Укртелекома і намагався її продати, після чого був пійманий міліцією. При тому, що подібні диски з Базою 09 продаються в Україні вже багато років, зокрема в Києві. Тому Укртелеком сам постійно створює подібні витоки даних, що й дозволяє створювати подібні БД та поширювати їх на компакт дисках.

І раніше я вже писав про уразливість на сайті Укртелекома, що дозволяє отримати всі дані з їхньої БД (в тому числі потенційно й ті, яких не знайдеш в Базі 09). Так що можливість витоків даних від Укртелекома цілком зрозуміла.

Нещодавно, 21.02.2010, досліджуючи це питання за Базою 09, я зайшов на http://www.kyiv.ukrtelecom.ua і виявив Information Leakage уразливість. Що призводить до витоку даних про абонентів Укртелекома.

В своїй онлайновій базі Служба 109, Укртелеком видає забагато інформації. Він видає не тільки телефон, але й призвіще, ініціали (невірно) і вулицю (без дома і квартири). При цьому дозволяє використовувати wildcard-символи.

Хоча сам заявляє про “пошук телефону абонентів квартирного сектору”, тобто повинен тільки телефони видавати. Тобто він дає завеликий витік інформації. За допомогою даного сервісу можна знайти забагато інформації, навіть не маючи Бази 09.