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

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

Добірка цікавого чтива на тему web security (статті з Вікіпедії):

• Cookie stuffing
• Cross-site cooking
• Evil twin (wireless networks)
• Ghost Rat
• HTTP header injection

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

DNS Rebinding with Robert RSnake Hansen

В даному відео ролику RSnake розповіє про DNS Rebinding атаки. Про те як працює DNS, як відбувається DNS Rebinding в браузерах, яким чином на це можна вплинути і для яких атак це може бути використано. Рекомендую подивитися дане відео для розуміння DNS Rebinding атак.

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

Обмірковуючи тему захисту від вірусів на сайтах я виявив, що можливий обхід систем для пошуку вірусів на веб сайтах, зокрема тих, що вбудовані в пошукові системи. Це можливо через використання клоакінга, коли аналізується User Agent, і якщо це пошукова системи, то шкідливий код не виводиться, якщо ж браузер - то виводиться. Подібне можна реалізувати в шкідливих скриптах (Perl, PHP та інших), розміщенних на інфікованих сайтах, або на сайтах зловмисників, на які посилаються інші сайти, зокрема в тегах script та iframe.

Зазначу, що використання методики клоакінга я вже зустрічав в шкідливих скриптах при їх дослідженні в останні роки. Зокрема я стикався з перевірками на реферер (подібний підхід може застосовуватися і для User Agent). І дана методика захисту шкідливого коду від систем для пошуку вірусів створює серйозний виклик даним системам.

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

В своїй презентації Essential PHP Security, Arne Blankerts розповів про основну безпеку PHP. Це доповідь з конференці ZendCon 2009.

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

Добірка цікавого чтива на тему web security (статті з Вікіпедії):

• Browser exploit
• Clickjacking
• Cross-site request forgery
• DNS rebinding
• Directory traversal

Раніше я вже писав про атаки на веб сайти та їх наслідки, які пов’язані з SEO - це атака для блокування сайта в пошукових системах та вплив на ранжування сайта через його уразливості. А зараз розповім про інший аспект також пов’язаний з SEO.

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

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

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

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

Одним з навайжливіших SEO показників сайта є його ранжування в результатах пошуку. І через дірки на сайті можна впилавати на ранжування сайта в результатах пошуку в пошукових системах.

Як я розповідав в статті Атака для блокування сайта в пошукових системах, через дірки на сайті, він може бути заблокований в пошукових системах (зокрема в Google, Yahoo та Яндекс). Коли сайт буде взломаний і на ньому буде розміщений шкідливий код, після чого пошукові системи помітять даний сайт як інфікований в результатах пошуку.

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

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

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

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

Injecting Malicious Code via phpBB

В даному відео ролику демонструється Code Execution атака на phpBB. Коли при доступі до адмінки, що можна зробити через різні дірки в движку, можна виконувати довільний код (довільні системні команди) через phpBB за допомогою спеціального методу, розробленого автором даного відео.

Для цього в адмінці виконується спеціальний SQL запит, що дозволяє в движку виконувати довільні системні команди. Після чого автор виконує декілька команд, в тому числі додає новий акаунт адміністратора в систему. Рекомендую подивитися дане відео для розуміння Code Execution атак.

Пропоную ознайомитися з мою статтею про тестування систем пошуку вірусів на веб сайтах, що я провів на цьому тижні.

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

Тестування систем пошуку вірусів на веб сайтах

Мною були дослідженні наступні системи:

1. Web Virus Detection System.
2. Google.
3. Yahoo.
4. Yandex.
5. Norton Safe Web.
6. McAfee SiteAdvisor.
7. StopBadware.

З результатами тестування можете ознайомитися в даній статті.

This is English version of my Anthology of attacks via captchas article.

Earlier I made anthology of attacks via redirectors (opened and closed) in my articles Redirectors: the phantom menace and Attacks via closed redirectors. And in this article I’ll make anthology of attacks via captchas.

CAPTCHA - it’s security web applications, which designed to protect web sites against automated requests. But captchas not only badly handle with protection against automated requests, but they also create possibilities for other attacks at the sites and their visitors. There are many different attacks via captchas, which I’ll tell about in this article.

Attacks via captchas.

Besides direct captcha bypass, there also can be made many other attacks via them. Here is a list of all attacks via captchas which I know:

• Captcha bypass.
• Redirector attacks.
• Cross-Site Scripting attacks.
• SQL Injection attacks.
• CSRF attacks.
• Information leakages.
• Denial of Service attacks.

Captcha bypass.

Multiple Insufficient Anti-automation vulnerabilities occur in captchas, which allow to bypass captchas for sending of automated requests. Which I told about in details in my project Month of Bugs in Captchas.

Redirector attacks.

In Google’s captcha there is Redirector vulnerability, which allow to redirect visitors to arbitrary sites.

Cross-Site Scripting attacks.

In captcha for Nucleus and in plugins Peter’s Random Anti-Spam Image, Math Comment Spam Protection, Captcha!, Cryptographp, WP-ContactForm and CapCC for WordPress there are Cross-Site Scripting vulnerabilities (reflected and persistent), which can be used for XSS attacks.

SQL Injection attacks.

In captcha for Nucleus and in plugin CapCC for WordPress there are SQL Injection vulnerabilities, which can be used for attacks on the sites.

CSRF attacks.

In plugins Captcha! and CapCC for WordPress there are Cross-Site Request Forgery vulnerabilities, which can be used for CSRF-attacks. Including for exploitation of Insufficient Anti-automation (in both captchas) and SQL Injection (in second captcha) vulnerabilities.

Information leakages.

In captcha for Nucleus there are Full path disclosure and SQL DB Structure Extraction vulnerabilities, and in plugin CapCC for WordPress there is Full path disclosure vulnerability. Which lead to leakage of information at the site.

Denial of Service attacks.

There can be conducted DoS attacks via captchas (via SQL Injection and Denial of Service vulnerabilities in them). Which I wrote about in details in my article DoS attacks via captchas.

Conclusions.

Instead of protecting of web sites against automated requests, captchas often pose a threat to security of web sites and their visitors. So developers of captchas and owners of web site which use them need always to check security of their captchas.