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

Продовжуючи розпочату традицію, після попереднього відео про хак голосового VLAN, пропоную новий відео секюріті мануал. Цього разу відео про створення експоіта в Metasploit. Рекомендую подивитися всім хто цікавиться цією темою.

milw0rm exploit 2 metasploit

В даному відео ролику демонструється використання Metasploit Framework для створення експлоіта (використовуючи дані з іншого експлоіта). Зокрема демонструється процес використання MSF-eXploit Builder, що є складовою Metasploit Framework. Рекомендую подивитися дане відео для розуміння інструментарія середовища MSF.

This is English version of my Fingerprinting of Apache web server article.

Already at 10.09.2006 I created method of fingerprinting of Apache web server. This method based on feature of Apache, which I found at that time during security researches at my localhost (on Apache 1.3.23).

Feature of Apache.

There is interesting feature of Apache web server, which lie in that for accessing to file it’s possible to not set its extension. As I found recently, this future concerned with MultiViews option (if it’s turned on, which is by default).

I.e. for accessing to file robots.txt at the site, request can be made to file robots.txt:

http://site/robots.txt

Or request can be made to file robots (without extension):

http://site/robots

I.e. with making of request to file without setting of its extension, Apache will show file (which can have arbitrary extension at the server) after making of auto-addition of extension.

At that it concerns only those extensions, which is known by Apache. I.e. those ones, MIME type of which is known by Apache (which sets in settings of web server, particularly in mime.types). Order of auto-addition of extensions also sets in settings of web server.

For example, according to settings of my Apache, if to place test.html, test.txt and test.xml at the server, then at request to file test:

http://site/test

Content of test.xml will be shown, i.e. xml extension is going first. Html extension is going next and after that is txt extension.

Fingerprinting of Apache.

This feature can be used for identification of Apache.

For this it’s needed to find any working file at the server, which name and extension is known. For example, page.html. And after that to send two requests: http://site/page.html and http://site/page.

If in both cases there will be shown content of the same file and, which is the most important, there will be no error 404, then this web server is Apache.

Searching for hidden information.

Also this feature can be used for searching for hidden information at the sites. On which this feature of Apache will lead to information leakage.

For example, if there is a file secret.ext at the site, which extension (ext) can be complex (non-standard), or can be standard. To find this file there is no need to guess its full name (with extension), and it’ll be enough to guess only name without extension. Which allows to find this hidden file much faster.

http://site/secret

I have happened to use this feature of Apache on own experience during security audit to find hidden information at the site, admin of which didn’t expect that somebody would find this information.

Affected versions.

This feature works in Apache 1.x - tested in Apache 1.3.23 and Apache 1.3.37. Also it works in Apache 2.x, but I haven’t happened to meet such sites on Apache 2.x. So all versions of Apache with turned on MultiViews have this feature.

For example, Google also isn’t using extensions in some scripts at their sites - http://www.google.com/search - but they are using server GWS and it’s there such name set for web application. Besides Apache I haven’t happened to meet other web servers with such feature.

Ще 10.09.2006 я розробив методику визначення веб сервера Apache (fingerprinting). Дана методика базується на особливості Apache, яку я тоді, під час секюріті досліджень, виявив в себе на localhost (на Apache 1.3.23).

Особливість Apache.

Цікава особливість веб сервера Apache полягає в тому, що для доступу до файла, можна не вказувати його розширення. Як я нещодавно вияснив, ця особливість пов’язана з опцією MultiViews (якщо вона ввімкнена, що є по замовчуванню).

Тобто для доступу до файла robots.txt на сайті, можна зробити запит до файла robots.txt:

http://site/robots.txt

Або можна зробити запит до файла robots (без розширення):

http://site/robots

Тобто зробивши запит до файла без вказання його розширення, Апач виведе файл (який може мати довільне розширення на сервері) зробивши автодоповнення розширення.

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

Наприклад, відповідно до налаштуваннь мого Apache, якщо на сервері розмістити test.html, test.txt і test.xml, то при запиті до файла test:

http://site/test

Виведеться зміст test.xml, тобто першим йде розширення xml. Наступним йде розширення html і потім вже розширення txt.

Визначення Apache.

Дану особливість можна використати для ідентифікації Apache.

Для цього потрібно виявити будь-який робочий файл на сервері, ім’я і розширення якого відомі. Наприклад, page.html. І потім послати два запити: http://site/page.html і http://site/page.

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

Пошук прихованої інформації.

Також дану особливість можна використати для пошуку прихованої інформації на сайтах. На яких дана особливість Apache призведе до витоку інформації.

Наприклад, якщо на сайті є файл secret.ext, розширення якого (ext) може бути складним (нестандартним), а може бути й стандартним. Для виявлення цього файлу не потібно вгадувати його повне ім’я (з розширенням), а достатньо буде вгадати лише ім’я без розширення. Що дозволить значно швидше виявити цей прихований файл.

http://site/secret

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

Вразливі версії.

Дана особливість працює в Apache 1.x - перевірено в Apache 1.3.23 і Apache 1.3.37. Також вона працює в Apache 2.x, але мені не доводилося зустрічати подібні сайти на Apache 2.x. Так що всі версії Apache з ввімкненим MultiViews мають дану особливість.

Наприклад, Гугл також не використовує розширення у деяких скриптів на своїх сайтах - http://www.google.com/search - але в них сервер GWS і це в них таке ім’я задане для веб додатка. Окрім Apache мені не доводилося зустрічати інших веб серверів з подібною особливістю.

Продовжуючи розпочату традицію, після попереднього відео про те, як зробити файл таким, що не виявляється антивірусами, пропоную новий відео секюріті мануал. Цього разу відео про хак голосового VLAN. Рекомендую подивитися всім хто цікавиться цією темою.

Anonymous Voice Vlan Hack

В даному відео ролику демонструється методика проведення хака анонімного голосового VLAN. Методика показана на прикладі обладнання Cisco. Рекомендую подивитися дане відео для розуміння методів атаки на VLAN.

Раніше я вже розповідав про XSS уразливості на 404 сторінках. І ще в 2008 році я запланував розповісти про один цікавий і поширений напрямок XSS атак - це атаки через помилки при запитах до БД.

Cross-Site Scripting уразливості мені доводилося знаходити у різних веб додатках, а також у браузерах та веб серверах. І окрім XSS дірок на Error 404 сторінках, також часто я зустрічав XSS уразливості в повідомленнях про помилки при запитах до Баз Даних (XSS через SQL Error).

Стандартний вектор атаки у випадку XSS через SQL Error - це вказання XSS-коду в якості значення параметра, що передається до БД (при цьому потрібно, щоб даний SQL запит став некоректним). Що призведе до виведення повідомлення веб додатку про помилку при запиті до БД, з вказанням рядка запиту, де наявна помилка, і до виконання JavaScript коду в браузері користувача.

XSS:

http://site/script?param=%27%3Cscript%3Ealert(document.cookie)%3C/script%3E

Подібні уразливості я знаходив неодноразово на різних сайтах та в різних веб додатках, зокрема в WordPress, Relay та Hydra Engine.

Наприклад, в WordPress для виконання JS-коду в повідомленні про помилку, потрібно було послати спеціальний символ (в данному випадку %A0), про що я вже розповідав детально.

XSS:

http://site/?s=%A0%3Cscript%3Ealert(document.cookie)%3C/script%3E

В деяких випадках (зокрема у PHP-додатках, що використовують MySQL), потрібно використовувати не тег script, а тег body для проведення XSS атаки, щоб код був повністю виведений в помідомленні про помилку в SQL запиті. Як, наприклад, у випадку уразливості на www.zemerl.com.

XSS:

http://site/script?param='%20and%20%3Cbody%20onload=alert(document.cookie)%3E

Зазначу, що ще в 2006 році була знайдена уразливість в PHP, що пов’язана з функцією mysql_error. Яка повертає в нефільтрованому вигляді значення помилки останнього SQL-запиту в MySQL, що може призвести до XSS атаки. Дана уразливість була виявлена в PHP 4.4.x та 5.1.x. Тому веб додатки, що використовують дану функцію і виводять її результати, можуть бути вразливі до XSS.

Так що веб розробники завжди повинні перевіряти свої розробки на наявність XSS уразливостей в повідомленнях про помилки при запитах до БД. Щоб не допускати подібних уразливостей.

В своїй презентації The Black Bag Security Review (VoIP Security), Dan York розповідає про безпеку VoIP. Він розглядає технологію Voice over IP в контексті безпеки.

В своїй статті Feed Injection in Web 2.0 Robert Auger розповідає про атаки через фіди. Про можливість проведення XSS, CSRF та інших атак через RSS і Atom фіди.

До речі, про файл HackingFeeds.pdf та UXSS уразливість через даний pdf-файл я вже згадував в минулому році .

В статті наводяться можливі вектори атак, зони виконання коду (Remote і Local) та ризики в різних зонах. А також ризики різних типів читачів фідів, можливості поширення коду через фіди та ризики в різних стандартах (RSS і Atom).

З цією темою я знайомий вже давно - як прочитав дану статтю в 2006 році. І хоча інформації про уразливості в браузерах пов’язаних з фідами в останні роки майже не з’являлося (за виключенням двох дірок в Opera), але нещодавно тема атаки через фіди стала знову актуальною. Коли були виявлені уразливості в Opera та Google Chrome, що дозволяють проводити XSS атаки через фіди.

Продовжуючи розпочату традицію, після попереднього відео про XSS та HTML Injection атаки в ICQ 6, пропоную новий відео секюріті мануал. Цього разу відео про те, як зробити файл таким, що не виявляється антивірусами. Рекомендую подивитися всім хто цікавиться цією темою.

How to Make File Undetected by AVs

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

This is English version of my Dark home article.

After the article Dark side of bookmarks, I’ll draw you attention to another aspect of security which concerned with web browsers.

There is such useful functionality in browsers as Home Page (homepage). To which browser is going at his start (if it’s set accordingly). At first sight this functionality doesn’t betoken any problems with security for users of the browsers, but it’s not so. There are several attacks, which can be conducted via homepage function. I planned to tell about it already in 2008 and I’d tell you about it in my article “Dark home”.

Note, that if in my practice I saw attacks via bookmarks few times, then attacks via homepage function I saw many times. Particularly there are programs, which at their installation on computer (including secretly) are changing homepage setting in IE.

Attacks via homepage function.

There are possible next attacks via homepage function:

1. Spam.
2. Phishing.
3. Malware spreading.
4. DoS attacks.

This browsers’ functionality creates conditions for conducting of persistent attacks, because adjusted homepage are saving in settings of the browsers at computers of the users. So every of above-mentioned attacks is persistent attack, which can trigger at the next start of the browser, or when user will press Home button in his browser. So probability of triggering of this attack is much higher, then at attack via bookmarks.

Methods of conducting of attacks.

The next methods can be used for setting of malicious homepages:

1. Social engineering: inscriptions “Set your homepage” at the sites under control of offenders (where code for redirection or other code is placed, which will trigger on next visit of the site).
2. Hacking of the sites and changing of codes in links “Set your homepage” to codes with malicious link, or putting of such links at the sites under control of offenders.
3. Using of viruses for changing of existent settings of homepage to malicious link in victim’s browser.
4. Using of attacks with active (looped) proposition to set as homepage (in Internet Explorer), so as to let victim to accidentally set this site as homepage (or to force her to do it).

Attacks in different browsers.

Among above-mentioned methods of attacks all four work in Internet Explorer, and in other browsers only attacks 1 and 3. So at attack on users of all browsers, and especially alternative ones, methods of social engineering, or viruses can be used. At using of viruses, during of changing of homepage settings in browser, it’s needed also to check if browser is set in such way, to start with a blank page, and if it’s set in this way, then to change this option, to let browser starts with homepage.

At attack on users of Internet Explorer, attacks 2 and 4 can be used. For this it’s needed to use the code of setting as Homepage (which works only in IE).

<a href="#" onClick="this.style.behavior='url(#default#homepage)';this.setHomePage('http://badsite')">Set your homepage!</a>

Spam.

Advertising site can be set as homepage. So homepage function can be used for spam spreading. And besides of site advertising in such way, it also can be used for turning of statistic of this site (in different ratings).

Phishing.

Just as in case of spam, homepage function can be used for phishing. But in this case, besides conducting of attack via methods 1, 2 and 4, the most effective will be method 3. So as to let virus to find (in history, in bookmarks or in homepage settings), which bank the victim is using, and to set phishing site of this bank as homepage. So as to let victim to run browser and right away proceed to phishing site, which pose itself as a site of her bank.

Malware spreading.

Attack will be conducting via setting link on exploit for browser as homepage. Which will execute malicious code in browser of the user, after start of the browser, and will install virus at his computer.

DoS attacks.

Attack will be conducting via setting link on DoS exploit as homepage. After starting of the browser by the user, his browser will crash or freeze. At that it will be persistent attack, which will be repeated at every start of the browser, so user will can’t use it at all, until he change this option.

Mechanism of setting as homepage also can be used by itself for conducting of DoS attack on browsers. This attack I called DoS via homepage. Internet Explorer 6, Internet Explorer 7 and previous versions (and possible next versions too) are vulnerable to it.

Conclusions.

Attacks via homepage function are completely real and dangerous. So users of the browsers must be careful in Internet and don’t set any site as homepage. And it’s advisable to set own browser is such way, so at start not homepage opens, but a blank page.

Після статті Темна сторона закладок, зверну вашу увагу на ще один аспект безпеки пов’язаний з веб браузерами.

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

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

Атаки через функцію домашньої сторінки.

Можливі наступні атаки через функцію домашньої сторінки:

1. Спам.
2. Фішинг.
3. Поширення шкідливого коду.
4. DoS атаки.

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

Методи проведення атак.

Для встановлення шкідливих хоумпейджів можуть застосовуватися наступні методи:

1. Соціальна інженерія: надписи “Зробіть своєю домашньою сторінкою” на сайтах підконтрольних зловмисникам (де розміщений код для редирекції чи інший код, що спрацює при наступному відвідуванні сайта).
2. Взлом сайтів і зміна кодів у лінках “Зробити своєю домашньою сторінкою” на коди з шкідливою лінкою, або встановлення подібних лінок на сайтах підконтрольних зловмисникам.
3. Використання вірусів для зміни існуючих налаштувань домашньої сторінки на шкідливу лінку у браузері жертви.
4. Використання атак з активною (зацикленою) пропозицією додати в якості Homepage (в Internet Explorer), щоб жертва випадково зробила даний сайт своєю домашньою сторінкою (або змусити її це зробити).

Атаки в різних браузерах.

Серед вищенаведених методів атак в Internet Explorer працюють всі чотири, а в інших браузерах лише атаки 1 і 3. Тому при атаці на користувачів всіх браузерів, і особливо альтернативних, можна використати методи соціальної інженерії, або віруси. При використанні вірусів, під час зміни налаштувань домашньої сторінки в браузері, потрібно також перевірити чи не налаштований браузер таким чином, щоб запускатися з пустою сторінкою, і якщо він налаштований саме так, то змінити цю опцію, щоб браузер запускався з домашньою сторінкою.

При атаці на користувачів Internet Explorer, можна використати атаки 2 і 4. Для цього потрібно використати код встановлення в якості Homepage (що працює лише в IE).

<a href="#" onClick="this.style.behavior='url(#default#homepage)';this.setHomePage('http://badsite')">Зроби своєю домашньою сторінкою!</a>

Спам.

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

Фішинг.

Так само як і у випадку спаму, функція домашніх сторінок може використовуватися для фішингу. Але в цьому випадку, окрім проведення атаки через методи 1, 2 і 4, особливо ефективними буде метод 3. Щоб вірус виявив (в історії, закладках чи налаштуванні домашньої сторінки), яким банком користується жертва, і встановив в якості домашньої сторінки фішинг сайт даного банку. Щоб жертва запустила браузер і одразу перейшла на фішерський сайт, який видає себе за сайт саме її банку.

Поширення шкідливого коду.

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

DoS атаки.

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

Також механізм встановлення в якості домашньої сторінки сам може бути використаний для проведення DoS атаки на браузери. Дану атаку я назвав DoS через хоумпейдж. До неї уразливі Internet Explorer 6, Internet Explorer 7 та попередні версії (та потенційно й наступні версії).

Висновки.

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