Архів за Липень, 2010

Новини: російські хакери, атаки в Facebook та студент-хакер

22:44 31.07.2010

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

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

Захід знайшов нову глобальну загрозу. Місце “Аль-Каїди” зайняла всесвітня мережа російськомовних хакерів.

За повідомленням hackzona.com.ua, Sophos попереджає про нові атаки в Facebook. Антивірусна компанія Sophos в минулому місяці попередила про те, що кілька сотень тисяч користувачів соціальної мережі Facebook стали жертвами атаки типу Сlickjacking або так званого “угону кліків”.

За повідомленням www.crime-research.ru, у Вінницькій області СБУ піймала студента-хакера. Співробітники Управління Служби безпеки України у Вінницькій області затримали студента, що шляхом комп’ютерного взлому незаконно втрутився в роботу інтернет-сайта Могилів-Подільського міської ради.

СБУ встановило, що 20-літній студент одного з вінницьких вузів замінив логін і пароль у системі керування сайтом міськради, що дало можливість іншим користувачам мережі Інтернет одержати доступ до деяких його розділів.

Вийшов WordPress 3.0.1

18:26 31.07.2010

Нещодавно, 29.07.2010, вийшла нова версія WordPress 3.0.1. Вихід нової версії WP співпав в часі з анонсом мого проекту День багів в WordPress 2 :-) .

WordPress 3.0.1 це багфікс випуск 3.0 серії. В якому розробники виправили різноманітні баги. Всього було виправлено близько 50 багів.

Уразливості на hackua.com

15:17 31.07.2010

15.12.2009

У квітні, 24.04.2009, я знайшов Abuse of Functionality та Insufficient Anti-automation уразливості на сайті http://hackua.com. Про що найближчим часом сповіщу адміністрацію сайта.

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

31.07.2010

Abuse of Functionality:

Логіні користувачів є їх іменами на форумі, що дозволяє визначити логіни в системі.

Abuse of Functionality:

На сторінці http://hackua.com/register.php?do=register в полі Логін можна визначити логіни користувачів в системі. Це також можна зробити через POST запит до скрипта http://hackua.com/ajax.php. Дана уразливість дозволяє провести Login Enumeration атаку.

Insufficient Anti-automation:

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

Insufficient Anti-automation:

http://hackua.com/sendmessage.php?do=sendtofriend&t=1001

http://hackua.com/sendmessage.php

http://hackua.com/register.php?do=register

На даних сторінках наявна слабка текстова капча (коли потрібно ввести лише одну і ту саму фразу).

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

Результати Дня багів в WordPress 2

23:58 30.07.2010

Сьогодні я провів проект День багів в WordPress 2 (Day of bugs in WordPress 2). За цей день я опублікував чимало уразливостей в WordPress. Всього 8 дірок - це Information Leakage, Full path disclosure, Cross-Site Request Forgery та Cross-Site Scripting уразливості в різних версіях WP.

В своєму проекті я опублікував різні цікаві уразливості в WP, в тому числі CSRF уразливість, що дозволяє проводити вельми оригінальну атаку, яку я назвав атака для відправки бакапа по емайлу (Email me backup attack). І з часом я ще оприлюдню нові уразливості в WordPress.

XSS уразливість в WordPress 2.7 - 2.8.1

22:41 30.07.2010

Продовжую проект День багів в WordPress 2. Зараз я оприлюдню результати мого дослідження однієї Cross-Site Scripting уразливості в WordPress, що була оприлюднена в липні 2009 року.

В минулому році була виявлена Cross-Site Scripting уразливість в WordPress 2.8.1. Яка мала місце в параметрі url при відправці коментарів. Уразливість виявив iso^kpsbr і він представив експлоіт, що редиректив на сайт вказаний в полі url, при наведені курсором на відповідний текст. Це strictly social XSS.

По-перше, я визначив вразливі версії движка (чого не було зроблено автором експлоіта). Як я перевірив, уразливі версії WordPress 2.7 - 2.8.1. Попередні версії невразливі, лише в WP 2.7 відбулися зміни в коді обробки коментарів, що призвели до появи XSS уразливості. В версії 2.8.2 уразливість була виправлена.

По-друге, я розробив експлоіт, який не робить onClick через onMouseOver для редерекції на сайт, а безпосередньо проводить XSS атаку - в даному випадку це звичайний alert. Незважаючи на обмеження на доступні символи, проведення XSS атак з використанням цієї уразливості цілком реальне (хоча розробники WP заявляли, що уразливість дозволяє лише редиректити на інші сайти, як це було зроблено в згаданому експлоіті, але в своєму експлоіті я продемонстрував можливість й інших атак, зокрема доступу до кукісів). Атака відбувається через onMouseOver (тобто це strictly social XSS).

XSS:

WordPress XSS.html

Код спрацює при відвіданні адміном сторінки для перевірки коментарів (http://site/wp-admin/edit-comments.php) та наведенні курсором на відповідний текст. Також код спрацює на сторінці з даним коментарем (http://site/?p=1), коли будь-який користувач чи відвідувач сайта наведе курсор на відповідний текст, якщо коментар був дозволений адміном, або він автоматично був дозволений для публікації (при відповідних налаштуваннях сайта - коли немає премодерації, або коли даний користувач вже має коментарі на даному сайті). А також код спрацює на сторінці Dashboard (http://site/wp-admin/index.php) в блоці Recent Comments при наведенні курсором на відповідний текст.

CSRF, Information Leakage та Full path disclosure в WordPress

20:11 30.07.2010

Продовжую проект День багів в WordPress 2. Зараз я оприлюдню Cross-Site Request Forgery уразливість в WordPress, що я знайшов 05.06.2007, та Information Leakage, що я знайшов 02.08.2009, та Full path disclosure, що я знайшов 29.07.2010.

CSRF:

Враховуючи, що в плагіні WordPress Database Backup немає захисту від CSRF, то за допомогою даної CSRF уразливості можна атакувати адміна. Це може бути зроблено для форсування бекапа, щоб через раніше згадану Information Leakage уразливість дістати бекап з БД сайта, або з метою створення великої кількості бекап файлів, щоб зайняти вільне місце на сервері. Або щоб отримати бекап на емайл. Дані CSRF-атаки можливі, якщо плагін WP-DB-Backup активований.

За допомогою CSRF-атаки можна зробити бекап будь-яких таблиць, як всіх, так і вибірково (наприклад таблиці з користувачами wp_users). В даному експлоіті робиться бекап з таблицею wp_users:

WordPress Database Backup CSRF.html

А також можна просто послати собі бекап (наприклад, з таблицею wp_users) на емайл:

WordPress Database Backup CSRF2.html

Це атака для відправки бакапа по емайлу (Email me backup attack).

Як я вже зазначав, даний витік інформації в бекапі БД найбільш небезпечний в зв’язку з тим, що в бекапі знаходиться логін та хеш адміна. Що можуть бути використані для отримання доступу до сайта. Це було дуже актуально до виходу WordPress 2.5, в якому переробили систему авторизації, після того як Steven Murdoch звернув увагу розробників WP на Cookie Authentication уразливість в WordPress. І з версії 2.5 в WP використовується новий метод авторизації через кукіси, але навіть в нових версіях движка витік бекапів все рівно є небезпечним і його не варто допускати.

Уразливі WordPress 2.0.11 та попередню версії, в поставку яких входив плагін WordPress Database Backup. Також уразливий плагін WP-DB-Backup 2.0 та попередні версії в будь-яких версіях WordPress (WP 2.9.2 та попередні версії і потенційно WP 3.0 та 3.0.1).

Захист від даної уразливості.

Як я вже згадував, в версії 2.1 плагіна додали захист від CSRF, тому остання версія плагіна WP-DB-Backup 2.2.2 невразлива до CSRF. Тому варто оновити плагін до останньої версії.

Information Leakage (через Privileges unchecked):

В червні 2007 я вже знайшов Information Leakage уразливість в плагіні WordPress Database Backup. А в серпні 2009 я знайшов нову уразливість пов’язану з даним плагіном (що є наслідком Privileges unchecked уразливості, яка була оприлюднена в липні 2009). Дана уразливість дозволяє дізнатися шлях до папки бекапів, а також виявити префікс таблиць в БД.

Privileges unchecked уразливість в WP була знайдена CORE в 2009 році. Вони використали моє дослідження про Local File Inclusion в WP (багато з яких працюють навіть з акаунтом Subscriber), про які я писав в грудні 2007 року під час першого проекту Day of bugs in WordPress. Дані дірки були виправлені в WP 2.3.2, але, як виявили CORE, LFI атаки на папку plugins все ще можливі (в зв’язку з відсутністю перевірок привілеїв у WP).

Дана уразливість може бути використана в парі з попередньою Information Leakage уразливістю, для виявлення повного шляху до бекапів та скачування бекапів БД сайта. Знаючи ім’я папки можна легко виявити ім’я файла (до 1000 комбінацій, якщо знати ім’я бази в MySQL, префікс та дату) та скачати бекап. Також знання префікса таблиць в БД стане в нагоді при SQL Injection атаці.

Витік інформації відбувається при доступі через admin.php до плагіну WP-DB-Backup:

http://site/wp-admin/admin.php?page=wp-db-backup.php

Якщо плагін WordPress Database Backup активований, то маючи акаунт з мінімальними правами (Subscriber) можна дізнатися шлях до бекапу і префікс таблиць.

Уразливі WordPress 2.8 та попередні версії. Уразливість стосується лише WP, а не плагіна (через дану уразливість можна атакувати й інші плагіни). В WordPress 2.8.1 дана Privileges unchecked уразливість вже виправлена, тому дана атака не працює.

Захист від даної уразливості.

Для захисту можна або оновити WordPress до невразливої версії, або оновити плагін до останньої версії. Починаючи з версії 2.1 плагіна (в тому числі в останній версії WordPress Database Backup 2.2.2) дана уразливість вже не працює (навіть в старих вразливих версіях движка), зате з’явилася Full path disclosure дірка.

Full path disclosure:

В WP-DB-Backup мають місце дві Full path disclosure уразливості:

http://site/wp-admin/admin.php?page=wp-db-backup.php

Уразливість працює з плагіном WordPress Database Backup 2.1 і вище. Вона працює у користувачів з будь-якими правами (навіть Subscriber) в усіх версіях WordPress (до WP 2.8.1) через використання вищезгаданої Privileges unchecked уразливості.

http://site/wp-content/plugins/wp-db-backup.php

Уразливість працює в усіх версіях WordPress Database Backup (в тому числі вона не виправлена і в останній версії WP-DB-Backup 2.2.2) в усіх версіях WordPress.

Захист від даних уразливостей.

Для захисту можна самому виправити дані Full path disclosure уразливості (як й інші FPD в WordPress).

Information Leakage та Full path disclosure уразливості в WordPress

17:29 30.07.2010

Сьогодні, в День багів в WordPress 2, я оприлюднюю багато цікавих уразливостей в WP. Першими я оприлюдню Information Leakage та Full path disclosure уразливості в WordPress, що я знайшов 05.06.2007, під час проведення проекту MOSEB.

Information Leakage:

В плагіні WordPress Database Backup (WP-DB-Backup) можливий доступ до бекапів БД сайта на WordPress через вгадування повного шляху до них. Бекапи можуть створюватися вручну адміном, або автоматично. Для атаки потрібно, щоб бекапи зберігалися на сайті (хоча б деякий час). WP-DB-Backup - це популярний плагін (що постачався з WordPress 2.0.x), що лише з сайту wordpress.org був викачаний 546218 разів (за станом на сьогодні).

Уразливі WordPress 2.0.11 та попередню версії, в поставку яких входив плагін WordPress Database Backup, а також всі версії WordPress (2.9.2 та попередні версії), при використанні даного плагіна (офіційно він сумісний з WP 2.9.2 та попередніми версіями і потенційно може працювати з WP 3.0 та 3.0.1).

Повний шлях до файлу з бекапами наступний:

http://site/wp-content/backup-xxxxx/database_wp_20070605_704.sql.gz

Щоб дістатися до бекапу, потрібно виявити ім’я папки та ім’я файла. Причому їх виявляти можна окремо - спочатку виявити папку, а вже потім файл.

1. Ім’я папки (backup-xxxxx) - це “backup-” + 5 символів md5-алфавіту і це 1048576 комбінацій.

2. Ім’я файла - це ім’я бази сайта в MySQL (database) + “_” + префікс (wp) + “_” + дата створення бекапу в форматі YYYYMMDD (20070605) + “_” + число від 000 до 999 (704) + “.sql.gz”.

Ім’я бази може співпадати з доменом або папкою на сервері, де розміщений сайт (так часто роблять провайдери), тому для визначення імені бази можна використати Full path disclosure уразливість (яких велика кількість в WP).

Префікс за замовчуванням дорівнює “wp”. Якщо префікс нестандартний, то його можна дізнатися за допомогою інших уразливостей в WP, зокрема SQL DB Structure Extraction (про які я писав раніше).

Дане число від 000 до 999 - це Swatch Internet time і це 1000 комбінацій. Якщо знати точний час створення файлу бекапу, наприклад, при CSRF-атаці (про яку я ще розповім), то можна визначити дане число. Наприклад, якщо файл був створенний в 12:00:00 на сервері, то це число буде дорівнювати 500.

Так що в звичайному випадку, коли ім’я бази, префікс та дата відомі, доведеться зробити до 1048576 комбінацій (папка) + до 1000 комбінацій (файл) = до 1049576 комбінацій (повний шлях до файлу). В середньому це 524788 комбінацій, що можна достатньо швидко підібрати при швидкому Інтернет-з’єднані.

Захист від даної уразливості.

Для захисту треба зробити відповідний файл .htaccess. І розмістити, наприклад, в папці wp-content, для заборони викачування бекапів з папки з бекапами. Що я використовую відтоді як знайшов дану уразливість.

Це можна обійти за допомогою Arbitrary file deletion уразливості, про яку я писав в грудні 2007 року. Для її використання потрібно провести CSRF-атаку на адміна. Дана атака спрацює в WP-DB-Backup <= 2.0.

http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=.htaccess

Якщо .htaccess розмістити в папці з бекапами, то він може бути видалений. Причому навіть з виправленою Directory Traversal - в папці з бекапами файли все рівно можна витерти. Тому .htaccess потрібно розміщувати не в папці с бекапами, а в папках вищого рівня, наприклад, в папці wp-content.

Враховуючи, що WordPress Database Backup плагін створює пусті index.php в папці з бекапами для захисту від витоку інформації про бекапи, то за допомогою Arbitrary file deletion уразливості (при CSRF-атаці на адміна) це можна обійти:

http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=index.php

Тоді не доведеться вгадувати ім’я файла. Це спрацює на всіх версіях WordPress з даним плагіном (WP-DB-Backup <= 2.0).

А якщо Directory Traversal дірка не виправлена, то можна пришвидшити процес знаходження папки з бекапами (backup-xxxxx) за допомогою Arbitrary file deletion уразливості (при CSRF-атаці на адміна), та витерти index.php в папці wp-content:

Для WordPress <= 2.0.3 (WP-DB-Backup <= 1.7):

http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=../index.php

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

Даний витік інформації в бекапі БД найбільш небезпечний в зв’язку з тим, що в бекапі знаходиться логін та хеш адміна. Що можуть бути використані для отримання доступу до сайта. Це було дуже актуально до виходу WordPress 2.5, в якому переробили систему авторизації, після того як Steven Murdoch звернув увагу розробників WP на Cookie Authentication уразливість в WordPress. І з версії 2.5 в WP використовується новий метод авторизації через кукіси, але навіть в нових версіях движка витік бекапів все рівно є небезпечним і його не варто допускати.

Full path disclosure:

В WP-DB-Backup мають місце дві Full path disclosure уразливості, які виникають при відповідних POST запитах. Вони працюють лише при наявності відповідних прав у користувача (зокрема у адміна).

WordPress Database Backup Full path disclosure.html

WordPress Database Backup Full path disclosure2.html

Дані уразливості працюють в плагіні WordPress Database Backup 2.0 та попередніх версіях в будь-яких версіях WordPress.

Захист від даних уразливостей.

Для захисту можна або самому виправити дані Full path disclosure уразливості (як й інші FPD в WordPress), або ж оновити плагін до останної версії WP-DB-Backup 2.2.2.

З WordPress 2.0.11 постачається версія 1.8 плагіна. Як я нещодавно перевірив, в версії 2.1 плагіна виправили Full path disclosure та інші уразливості. Тому остання версія плагіна WordPress Database Backup 2.2.2 невразлива до CSRF та до Full path disclosure (а також невразлива до раніше згаданих Directory Traversal, Arbitrary file deletion, DoS та XSS). Але остання версія плагіна все ще вразлива до Information Leakage.

Недостатня безпека технології ClickOnce від Microsoft

22:48 29.07.2010

Виявлена можливість проведення MITM-атак при використанні технології ClickOnce від Microsoft.

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

Не заборонене встановлення непідписаних елементів.

День багів в WordPress 2

18:37 29.07.2010

Анонсую проект День багів в WordPress 2 (Day of bugs in WordPress 2), який я проведу завтра. В якому я оприлюдню чимало цікавих уразливостей в WordPress, що я знайшов в 2007, 2009 та 2010 роках (і до яких вразливі різні версії движка).

Проект День багів в WordPress (Day of bugs in WordPress) я провів у грудні 2007 року і вже давно планував провести новий проект, але лише зараз знайшов час. В попередньому проекті, що я провів 30.12.2007, я оприлюднив 81 уразливість - це Arbitrary file edit, Local File Include, Directory Traversal та Full path disclosure уразливості. З них 49 Full path disclosure, 1 Arbitrary file edit і 31 Local File Include та Directory Traversal. Якщо б я вирішив зробити не “день багів”, а “місяць багів” (з публікацією по одній дірці), то цих уразливостей вистачило б майже на три проекти :-) .

В першому записі 16 уразливостей та в другому 65 уразливостей. Тобто всього 81 уразливість в WordPress в рамках даного проекту (чимало з яких розробники так досі й не виправили). В новому проекті буде опубліковано менше дірок, але всі вони будуть достатньо цікаві. Всього 8 уразливостей в WP.

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

15:22 29.07.2010

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

  • HP OpenView NNM ovsessionmgr.exe userid/passwd Heap Overflow Vulnerability (деталі)
  • HP OpenView NNM ovlogin.exe CGI userid/passwd Heap Overflow Vulnerability (деталі)
  • Hewlett-Packard OpenView NNM Snmp.exe Oid Variable Buffer Overflow Vulnerability (деталі)
  • TomatoCMS “q” SQL Injection Vulnerability (деталі)
  • TomatoCMS Script Insertion Vulnerabilities (деталі)
  • PolyPager 1.0rc10 (fckeditor) File Upload Security Issue (деталі)
  • Palo Alto Network Vulnerability - Cross-Site Scripting (XSS) (деталі)
  • SAP Business One 2005 Remote Buffer Overflow Vulnerability (деталі)
  • phpvidz Administrative Password Disclosure (деталі)
  • Multiple vulnerabilities in Kapitalist/capitalist (деталі)