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

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

Зокрема нещодавно я писав стосовно фішинг-атак, де зазначав, що фішинг-атаки на клієнтів українських банків відбуваються регулярно. Подібні атаки мали місце в 2006, 2007, 2008 і 2009 році. І головне, що на подібні атаки ведуться люди, які стають жертвами фішерів - подібні випадки були в попередні роки і в цьому році (хоча той випадок, про який повідомила СБУ, виглядає дещо підозрілим, але він є ціклом імовірним).

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

В своїй презентації Фішинг-атаки через Інтернет, я навів приклади фішерських атак. Серед методів фішинг-атак я виділив наступні:

• Зараження комп’ютера користувача банківським трояном.
• Підробка банківського сайта.
• Використання уразливостей банківського сайта.

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

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

Продовжу тему “Warning” Гугл хакінга (”Warning” Google hacking). Котрий є різновидом Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.

Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію стосовно даних сайтів. За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information leakage уразливості на різноманітних сайтах в Інтернеті.

Новий перелік “варнінг” пошукових запитів:

Warning: “filename cannot be empty”

Warning: constant

Warning: Unable to access

Warning: convert “function.convert”

Warning: “cannot read from”

Warning: copy

Warning: failed to open stream

Warning: curl “function.curl”

Warning: “No such file or directory”

Warning: current “function.current”

В своїй презентації HDIV (HTTP Data Integrity Validator), Bisan розповідає про HTTP Data Integrity Validator. Даний фреймворк являє собою опенсорсний Java Web Application Security Framework.

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

В статті наводяться наступні методи Blind SQL Injection атак:

• Повний перебір,
• Бінарний (двійковий) пошук,
• Використання find_in_set() і подібних функцій,
• Використання find_in_set() + more1row.

Якщо методи повного перебору і бінарного пошуку вже давно відомі, то методи з використанням find_in_set() є новими, і вони дозволяють ще більше пришвидшити сліпі SQL ін’єкції.

Зазначу, що методи з використанням find_in_set() мають ряд обмежень порівняно з методом бінарного пошуку. Тому на власній практиці я вже багато років використовую саме бінарний пошук для Blind SQL Injection і буду використовувати й надалі. Але сучасні розробки в галузі Blind SQL Injection потрібні, щоб ще більше пришвидшити дані атаки.

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

ICQ 6 HTML EXECUTION AND CRASH

В даному відео ролику демонструється проведення HTML Injection атаки в ICQ 6. Враховуючи, що ICQ 6 використовує движок Internet Explorer, можна проводити XSS та HTML Injection атаки, в тому числі використовуючі уразливості в IE для виконання коду та DoS атак.

Використання движків браузерів, зокрема IE, в інших додатках, створює умови для проводення Cross-Application Code Execution (тобто Cross-Application Scripting) та Cross-Application DoS атак. Рекомендую подивитися дане відео для розуміння векторів міжпрограмних атак та небезпеки подібних уразливостей.

В статті Защита сайта с помощью .htaccess и .htpasswd розповідається про захист сайта за допомогою .htaccess і .htpasswd на веб сервері Apache.

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

В даній статті розповідається про файли .htaccess і .htpasswd та процес їх створення. Всі приклади використовують базову (basic) аутентифікацію.

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

Advanced Mysql Injection in Joomla

В даному відео ролику наочно демонструється проведення SQL Injection атаки на движок Joomla, зокрема для зчитування локальних файлів на сайті. Рекомендую подивитися дане відео для розуміння векторів атаки за допомогою SQL ін’єкцій та небезпеки подібних уразливостей.

Як я писав рініше, в Інтернеті зараз є три пошукові системи, що повідомляють про зараженість сайта - це Google, Yahoo та Яндекс. Причому, якщо перші два блокують доступ до такого ресурсу (і потрібно вручну набирати адресу сайта, щоб перейти на нього), то Яндекс не блокує доступ, а лише повідомляє про небезпеку.

Раніше я писав про можливість закриття сайтів через їх взлом, коли через дефейс і/або розміщення вірусів сайт може бути закритим. Окрім цього можлива атака на сайт з іншою ціллю. Можлива атака на сайт з метою його блокування в пошукових системах.

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

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

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

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

Exploiting SW Vulnerabilities

В даному відео ролику демонструється процес знаходження уразливості в Windows-бібліотеці з використанням дебагера OllyDbg. Та створення для неї експлоіта (на Perl) для атаки на сервер через Інтернет. Рекомендую подивитися дане відео для розуміння процесу створення експлоітів та векторів атак через Інтернет.

This is English version of my Attacks via closed redirectors article.

In my article Redirectors: the phantom menace I wrote about attacks with using of open redirectors. Besides using of open redirectors for various attacks, closed redirectors also can be used.

Open redirectors - are redirectors which set address for redirection in URL (http://site/redirector.php?url=http://site2). Closed redirectors don’t set address for redirection in URL and have necessary addresses in DB, from which they take them by id (http://site/closed_redirector.php?id=1).

Closed redirectors considered more secure in comparison with open ones, but, as it’s clear from my article, they also can be used for many attacks (when there is possibility to set in them necessary URLs, or if they already were set). To closed redirectors belong as redirection services (such as TinyURL and others), as different counters, ratings and banner systems, where necessary URL is set in DB and is accessible by id. I.e. if you have access, for example, to banner system at the site, and can set arbitrary value of URL for banner (to which user will go at click on it), then you can conduct various attacks.

I meet many times in Internet cases of using of closed redirectors for different attacks. And also used them by myself during finding of vulnerabilities at the sites (for bypassing of filters and WAF). And I wrote about some of these attacks at my site.

Attacks via closed redirectors.

There are possible next attacks via closed redirectors:

• Redirection.
• Bypass of spam-filters.
• Bypass of flash restrictions.
• XSS attack via jar: URI in Firefox.
• CSRF attacks on a site.
• Hidden attacks on other sites.
• Image leakage in Firefox.
• Denial of Service attacks.
• Cross-Site Scripting attacks.
• Bypass of protection filters.

If there were 12 attacks via open redirectors, then there are possible 10 attacks via closed redirectors (one new attack from them). You can read in detail about these attacks in my article.

In case of such attacks as Redirection, Bypass of spam-filters, Bypass of flash restrictions, XSS attack via jar: URI in Firefox, CSRF attacks on a site, Hidden attacks on other sites, Image leakage in Firefox, the attack itself occurs almost equally for open and closed redirectors. In case of Denial of Service attacks it’s necessarily needed to use of closed redirector, i.e. there are possible two variants of an attack: using of open and closed redirector, using of two closed redirectors.

In case of Cross-Site Scripting attacks there are such attacks, which are possible with closed redirectors, particularly at redirection services such as TinyURL. These are attacks #3 and #5, which are described in my article Cross-Site Scripting attacks via redirectors. And I’ll tell more in detail about tenth attack.

Bypass of protection filters.

Redirection services (which are closed redirectors) allow to create new addresses for already existent addresses of the sites. Which allows to use them for bypass of the filters (including WAF) at the sites. It can be used in case of need to place a link or at conducting of XSS attacks. You can read in detail about this attack in my article Using of redirection services for bypass of the filters.