Архів за Лютий, 2007

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

15:13 17.02.2007

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

  • omnistar article manager [multiples injection sql] (деталі)
  • WORK System E-Commerce (g_include) Remote File Inclusion Vulnerability (деталі)
  • encapscms 0.3.6 - Remote File Include by Firewall (деталі)
  • ELOG Web Logbook Remote Denial of Service Vulnerability (деталі)
  • Drake CMS v 0.2 XSS exploit (деталі)
  • Updated apache-mod_auth_kerb packages fixes DoS vulnerability (деталі)
  • SiteXpress SQL Injection (деталі)
  • Multiple PHP remote file inclusion in Lizge V.20 Web Portal (деталі)
  • PHP remote file inclusion vulnerability in dotProject (деталі)
  • SQL-ін’єкція в Cool Manager (деталі)

СУБД Oracle вразлива до нового класу уразливостей

20:26 16.02.2007

Дослідницька компанія NGS Software і незалежний фахівець з безпеки Девід Лічфілд стверджують, що знайшли новий клас уразливостей, до яких вразлива СУБД Oracle.

Експерти говорять, що уразливості дозволяють зловмиснику запустити SQL-код, що дозволить викрасти конфіденційну інформацію. “Даний клас уразливостейтей не є супер критичним, однак у більшості випадків успішна атака майже гарантує хакеру одержання даних, що зберігаються в СУБД”, - говорить Лічфілд.

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

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

За словами Лічфілда, написання зловмисного коду вимагає деяких навичок, однак Oracle не зможе випустити патч для даної уразливості, тому що вона стосується самої суті роботи БД.

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

По матеріалам http://www.secblog.info.

Уразливість на www.newson.info

19:18 16.02.2007

30.11.2006

У вересні, 27.09.2006, я знайшов Cross-Site Scripting уразливість на проекті http://www.newson.info (новинний сайт, на якому до речі є розділ Безпека). Про що найближчим часом сповіщу адміністрацію проекту.

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

16.02.2007

XSS:

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

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

17:08 16.02.2007

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

  • Ultimate PHP Board <= 2.0 (header_simple.php) File Include Exploit (деталі)
  • PHP Classifieds <= 7.1 (detail.php) Remote SQL Injection Exploit (деталі)
  • Quick.Cms.Lite <= 0.3 (Cookie sLanguage) Local File Include Exploit (деталі)
  • SazCart <= 1.5 (cart.php) Remote File Include Vulnerability (деталі)
  • iPrimal Forums Users(ChangePass) 3xPl0!t (деталі)

Уразливості в Yandex-Direct

23:30 15.02.2007

18.11.2006

Деякий час тому (у вересні) я знайшов XSS уразливість на itnews.com.ua. Після додаткового досліження вияснилось, что окрім власної XSS уразливісті на даному сайті, є також ще одна уразливість (Cross-Site Scripting) - в коді Яндекс-Директ.

Про даний тип уразливостей я вже згадув в записі Хакінг сайту через уразливості в коді зовнішніх систем (подібні уразливості мають місце і в кодах інших систем, в тому числі й систем контекстної реклами, про що я ще напишу додатково). Детальна інформація про дану уразливість з’явиться пізніше (одразу за інформацією про основну XSS уразливість на itnews.com.ua).

Яндексу потрібно слідкувати за використанням кода власної системи контекстної реклами (і не допускати подібних ситуацій).

15.02.2007

Cross-Site Scripting уразливість в Яндекс-Директ коді (XSS в DOM).

На веб сторінці з кодом даної системи контекстної реклами, наприклад на сторінці з пошуком по сайту (як це було на itnews.com.ua), в будь-якому з передаваємих скрипту параметрів (або навіть в усіх параметрах) може бути уразливість, наприклад в параметрі page. Якщо він не обробляється відповідним чином.

XSS в DOM:

Всі сайти які використовують Директ можуть бути уразливими. Тому треба обробляти всі параметри, що передаються скрипту системи контекстної реклами в коді веб сторінки.

Росію накрила хвиля кіберзлочинів

22:23 15.02.2007

У Росії зростає хвиля комп’ютерних злочинів, що носять уже не хуліганський характер, а спрямовані на одержання економічної вигоди. У 2006 році в РФ зареєстровано 14 тис. кабірзлочинів - аналогічна цифра називалася в 2005 році. Авторами таких злочинів переважно є не окремі “ентузіасти”, а організовані злочинні групи.

Відповідно до діючого законодавства Російської Федерації, за несанкціоноване проникнення в комп’ютерні мережі передбачається покарання у вигляді штрафу, як максимум - позбавлення волі на термін до 7 років. Російські правоохоронці вважають, що ці міри недостатні для ефективної боротьби з кіберзлочинцями. Наприклад, у США дане питання вирішене більш жорстко - за антисоціальні дії хакер може відсидіти за ґратами до 20 років.

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

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

По матеріалам http://news.liga.net.

P.S.

Про подібну статистику комп’ютерних злочинів в Україні я писав. У нас кіберзлочинів за рік відбувається в 24 рази менше ніж в РФ.

Захист flash-роликів

20:44 15.02.2007

В п’ятнадцатому номері своєї розсилки Macromedia Flash: всё что вы хотите о нём знать, що вийшов наприкінці минулого року, я опублікував свою статтю “Захист flash-роликів”. Яку пропоную зараз вашій увазі, думаю дана тема вас зацікавить.

Прочитати статтю Защита flash-роликов на російській мові ви можете в архіві розсилки, зараз же презентую україномовну версію статті.

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

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

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

Одним з методів захисту є перевірка URL сайта. Для заборони запуску флешки локально чи на іншому сайті.

Для цих цілей використовується наступний код. Це приклад алгоритму захисту при перевірці на адресу сайта.

У першому кадрі флешки можна вставити мувікліп з перевіркою, з наступним кодом:

onClipEvent (load) {
 if (_url != "http://mlfun.org.ua/flash.swf") { // if path is incorrect
  stop();
  // повідомлення в текстовому полі message (в тому ж першому кадрі)
  _root.message = "Ви запускаєте флешку не з http://mlfun.org.ua";
 }
 else { // path is OK
  GotoAndPlay(2);
 }
}

Чи можна у випадку некоректного шляху перейти на кадр 2, де знаходиться напис “Хакерам вхід заборонений” і “stop();”. А у випадку коректного - перейти наприклад на кадр 3.

Щодо захисту коду самої флешки, щоб його неможливо було підглянути (і скопіювати).

Як я вже сказав, усе ламається. Мені практично не потраплялися флешки які не можна було б витягти із сайта і запустити в себе локально (як би не намагалися їхні автори), тому що всі захисти можна обійти. Самим реальним методом захисту є прив’язка до скрипта на сайті. І вже на perl, php чи ін. розробляються захисні механізми. Що вже виходить за рамки однієї лише флеш технології.

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

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

Але приведений мною вище код цілком підійде проти ламерів.

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

18:17 15.02.2007

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

  • Kerio WebSTAR local privilege escalation (деталі)
  • Links smbclient command execution (деталі)
  • Selenium FTP Server Directory Traversal (деталі)
  • Wheatblog [multiple xss (post) & full path disclosure] (деталі)
  • Conxint FTP MKD DIR and GET Directory Transversal (деталі)
  • LandShop Real Estate [multiple injection sql & xss] (деталі)
  • bitweaver <=1.3.1 [injection sql (post) & xss (post)] (деталі)
  • PHP-інклюдинг в Empire CMS (деталі)
  • MySQL before 5.0.25 and 5.1 before 5.1.1 vulnerability (деталі)
  • PHP include in the mosListMessenger Component for Mambo and Joomla! (деталі)

XSS уразливості в WordPress 2.0

21:49 14.02.2007

В листопаді минулого року (03.11.2006) я знайшов Cross-Site Scripting уразливості в движку WordPress 2.0. Дані уразливості зокрема я знайшов на сайті www.mozilla-team.org.ua (про що я писав нещодавно), адмінам якого я повідомив, і вони працюють над виправленням (планують оновити движок на більш нову версію).

Уразливими є версії WordPress 2.0 та потенційно 2.0.1 і 2.0.2. WP 2.0.3 вже не вразливий. Як і всі наступні версії WordPress: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1 (нещодавно як раз вийшов WordPress 2.1).

XSS:

Уразливості в файлі wp-register.php.

POST запит на сторінці http://site/wp-register.php:

"><script>alert(document.cookie)</script>В полях: Ім’я користувача та E-Mail.

Це лише деякі з уразливостей в движку WordPress, що були в попередніх версіях движка, які я не використовував (сам почав використовувати WP з версії 2.0.3), але котрі знаходив на різних сайтах в Мережі. І це окрім тих уразливостей, які я знайшов у наступних версіях движка, про які я писав: Численні уразливості в WordPress, Нові уразливості в WordPress, Чергові уразливості в WordPress.

Проксування запитів через Microsoft XMLHTTP

19:53 14.02.2007

Виявлена уразливість в Microsoft Windows XMLHTTP, яка дозволяє проксувати запити через XMLHTTP.

Уразливі продукти: Windows XP, Windows Vista.

Через недостатню перевірку запиту користувача ActiveX об’єкт Msxml2.XMLHTTP може бути використаний для проксування HTTP-запиту через браузер клієнта. Тобто браузер може бути використаний як бекдор (для проведення різноманітних атак в Інтернеті через браузер відвідувачів сайта).

  • Web 2.0 backdoors made easy with MSIE & XMLHttpRequest (деталі)