Архів за Квітень, 2010

Цікаве чтиво на тему web security

22:43 23.04.2010

Продовжуючи розпочату ще в 2006 році традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему web security (статті з Вікіпедії):

Уразливість в Переходи для DataLife Engine

19:12 23.04.2010

11.02.2010

У червні, 29.06.2009, я знайшов Cross-Site Scripting уразливість в модулі Переходи для DataLife Engine (DLE). Уразливість виявив на сайті http://kinozalka.com, що використовує даний модуль для движка DLE. Про що найближчим часом повідомлю розробникам.

Раніше я вже писав про уразливість в Tagcloud для DLE.

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

23.04.2010

XSS:

Це persistent XSS уразливість. Що дозволяє провести атаку через заголовок Referer, у випадку коли на сайті виводяться лінки на безпосередні запити в пошукових системах.

Referer: http://www.google.com/search?q=xss"><script>alert(document.cookie)</script>

Уразливі Переходы v.6.9 та попередні версії.

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

15:21 23.04.2010

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

  • Saphplesson 4.3 Remote Blind SQL Injection Exploit (деталі)
  • MicroCMS 3.5 (SQL/LFI) Multiple Remote Vulnerabilities (деталі)
  • Joomla Component com_jlord_rss (id) Blind SQL Injection Exploit (деталі)
  • Joomla com_foobla_suggestions (idea_id) SQL Injection Vulnerability (деталі)
  • AdsDX 3.05 (Auth Bypass) Remote SQL Injection Vulnerability (деталі)
  • NaviCOPA Web Server 3.01 Remote Source Code Disclosure Vulnerability (деталі)
  • phpPollScript <= 1.3 (include_class) Remote File Inclusion Vulnerability (деталі)
  • Elite Gaming Ladders 3.2 (platform) SQL Injection Vulnerability (деталі)
  • Joomla Component com_album 1.14 Directory Traversal Vulnerability (деталі)
  • ProFTPd with mod_mysql Authentication Bypass Exploit (деталі)

SEO при дірявому сайті, як допомога зловмисникам

22:49 22.04.2010

Раніше я вже писав про атаки на веб сайти та їх наслідки, які пов’язані з SEO - це атака для блокування сайта в пошукових системах та вплив на ранжування сайта через його уразливості. А зараз розповім про інший аспект також пов’язаний з SEO.

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

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

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

Таким чином власник сайта, що не слідкує за його безпекою, вкладаючи гроші в SEO і/або рекламу свого сайта (якщо його сайт вже інфікований чи буде інфікований), лише створить умови для зараження вірусами більшої кількості користувачів. І лише допоможе (за власні кошти) зловмисникам отримати більшу вигоду.

SQL Shell

19:01 22.04.2010

Вчора вийшла нова версія програми SQL Shell v.1.0.3. В новій версії:

  • Додана підтримка усіх відповідей з помилками.
  • Додана опція порта по замовчуванню для хоста.
  • Покращена обробка пробілів в значенні вразливого скрипта.

SQL Shell є консольним інтерфейсом для проведення SQL Injection атак.

Скачати: SQL_Shell_v.1.0.3.rar.

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

15:29 22.04.2010

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

  • Oracle 10g CTXSYS.DRVXTABC - plsql injection (деталі)
  • Oracle Updates for Multiple Vulnerabilities (деталі)
  • Oracle Updates for Multiple Vulnerabilities (деталі)
  • Sheedravi CMS SQL Injection Vulnerability (деталі)
  • AXIS 70U Network Document Server - Privilege Escalation and XSS (деталі)
  • Multiple vulnerabilities in LineWeb 1.0.5 (деталі)
  • FreeWebshop.org: multiple vulnerabilities (деталі)
  • AproxEngine Multiple Vulnerabilities (деталі)
  • Another SQL injection in ProFTPd with mod_mysql (probably postgres as well) (деталі)
  • Re: Another SQL injection in ProFTPd with mod_mysql (probably postgres as well) (деталі)

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

22:44 21.04.2010

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

  • http://www.marosvita.org.ua (хакером B0T_25 з Azdefacers)
  • http://shela.org.ua (хакером Delp0rt3r)
  • http://androgen.com.ua (хакерами з UAH-Crew)
  • http://mediator.uz.ua (хакером fatalflex07) - причому спочатку сайт був взломаний 22.03.2010 fatalflex07, а вже 06.04.2010 взломаний TeXaS. Схоже, що сайт постійно хакається, як і деякі інші сайти в Уанеті
  • http://avtonews.cv.ua (хакером TeXaS)

Уразливості на adbroker.ru

19:09 21.04.2010

23.01.2007

У жовтні, 21.10.2006, я знайшов SQL Injection та Full path disclosure уразливості на відомому проекті http://adbroker.ru (веб брокер). Про що найближчим часом сповіщу адміністрацію проекту.

Про даного брокера я вже згадував стосовно уразливостей на adbroker.ru.

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

21.04.2010

SQL Injection:

http://adbroker.ru/user_messages.php?action=read&mid=-1'%20or%201='1
http://adbroker.ru/user_messages.php?action=delete&mid=-1'%20or%201='1
http://adbroker.ru/user_partner.php?action=your_adv&sid=-1'%20or%201='1

Можливе читання і видалення внутрисистемних повідомленнь довільних користувачів, та виконання довільних SQL команд.

Full path disclosure:

http://adbroker.ru/user_partner.php

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

Адміни adbroker.ru довго не хотіли виправляти ці дірки (так само як вони не виправили інші уразливості) і я відклав їх оприлюднення, щоб дати їм шанс виправити їх. До того ж, вони мені з 2006 року не віддали $100, що я заробив в даному брокері. Але вони ні дірки не виправляли, ні на листи не відповідали, ні грошей так і не віддали.

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

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

15:12 21.04.2010

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

  • PHP Pro Bid Remote Blind SQL Injection Exploit (деталі)
  • BigAnt Server 2.50 GET Request Remote BOF Exploit (SEH) 0day (деталі)
  • BRS Webweaver 1.33 /Scripts Access Restriction Bypass Vulnerability (деталі)
  • HotWeb Rentals (details.asp PropId) Blind SQL Injection Vuln (деталі)
  • Three Pillars Help Desk v3 (Auth Bypass) SQL Injection Vulnerability (деталі)
  • iBoutique.MALL 1.2 (cat) Remote Blind SQL Injection Vulnerability (деталі)
  • BigAnt Server 2.50 GET Request Remote BOF Exploit (SEH) Universal (деталі)
  • NetAccess IP3 (ping option) Command Injection Vulnerability (auth) (деталі)
  • Joomla Component com_djcatalog SQL/bSQL Injection Vulnerabilities (деталі)
  • CVE-2009-1979 PoC. Working at least on Oracle 10.2.0.4 win32 (деталі)

Вплив на ранжування сайта через його уразливості

22:45 20.04.2010

Одним з навайжливіших SEO показників сайта є його ранжування в результатах пошуку. І через дірки на сайті можна впилавати на ранжування сайта в результатах пошуку в пошукових системах.

Як я розповідав в статті Атака для блокування сайта в пошукових системах, через дірки на сайті, він може бути заблокований в пошукових системах (зокрема в Google, Yahoo та Яндекс). Коли сайт буде взломаний і на ньому буде розміщений шкідливий код, після чого пошукові системи помітять даний сайт як інфікований в результатах пошуку.

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

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

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