Архів для категорії 'Статті'

Створення ActiveX експоіта в Metasploit

20:02 15.12.2009

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

milw0rm exploit 2 metasploit (activex)

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

Аудит по стандарту PCI DSS

22:40 12.12.2009

В статті Правила пентеста - аудит по стандарту PCI DSS розповідається про методології пентестингу і про стандарт PCI DSS. А також про методику проведення аудиту безпеки по стандарту PCI DSS (Payment Card Industry Data Security Standard).

В статті наводяться наступні аспекти PCI DSS аудиту:

  • Визначення границь дослідження, що проводиться.
  • Network-layer penetration tests.
  • Application-layer penetration tests.
  • Вибір цілей для проникнення:
    • Експлуатація уразливостей у мережевих сервісах.
    • Аналіз розмежування доступу.
    • Атака типу брутфорс.
  • Аналіз захищеності web-додатків.
  • Аналіз захищеності СУБД.

Проведення аудиту безпеки по стандарту PCI DSS необхідно для тих сайтів банків та e-commerce сервісів, що працюють з кредитними картами.

Створення експоіта в Metasploit

22:46 04.12.2009

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

milw0rm exploit 2 metasploit

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

Fingerprinting of Apache web server

22:41 28.11.2009

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.

Визначення веб сервера Apache

22:44 27.11.2009

Ще 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

22:44 24.11.2009

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

Anonymous Voice Vlan Hack

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

XSS атаки через помилки при запитах до БД

22:46 21.11.2009

Раніше я вже розповідав про 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 уразливостей в повідомленнях про помилки при запитах до БД. Щоб не допускати подібних уразливостей.

Безпека VoIP

20:11 18.11.2009

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

Ін’єкція фідів - атаки через RSS і Atom фіди

22:44 14.11.2009

В своїй статті 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 атаки через фіди.

Як зробити файл таким, що не виявляється антивірусами

22:44 12.11.2009

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

How to Make File Undetected by AVs

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