Архів для категорії 'Статті'

Іконковий ніндзя

20:28 10.09.2011

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

“Icon Ninjas” Internet Security PSA

В даному відео ролику, розробленного на замовлення Гугла та інших компаній для Internet Security PSA, демонструється типовий процес атаки через Інтернет (така собі соціальна реклама). І закликається Інтернет-користувачів слідкувати за безпекою власного комп’ютера виконуючи стандартні і давно відомі кроки для захисту ПК.

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

Silverlight: захист і напад

22:45 09.09.2011

В статті Silverlight: защита и нападение розповідається про методи захисту та атаки на Silverlight додатки. Про безпеку при розміщенні Silverlight-додатків на веб сайтах.

В даній статті розглянуті наступні аспекти пов’язані з безпекою Silverlight:

  • Модель безпеки Silverlight.
  • Sandbox.
  • Мережева взаємодія.
  • Десктопні додатки Silverlight.
  • Експлуатація уразливостей Silverlight-контролів.
  • Як зробити Silverlight-контроли більш безпечними.

Флеш не єдина RIA платформа в Інтернеті, тому варто також звертати увагу на безпеку платформи Silverlight.

Обхід захисту на images.google.com

16:08 08.09.2011

В 2007 я виявив уразливості на images.google.com (в пошуці по зображенням), про які розповів під час проекту MOSEB, та www.google.com та translate.google.com (в онлайн перекладачі). І тоді Гугл проігнорував дані уразливості, а в 2009 році я виявив, що вони частково (втихаря) виправили дірку в пошуці по зображенням - шляхом обмеження адрес, на які можна зайти через даний функціонал. І я тоді одразу ж розробив метод обходу даного обмеження, про що зараз вам розповім.

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

Але це обмеження обходиться наступним чином. Можна взяти вже готову сторінку (з зображенням в даному випадку), яка проіндексована Гуглом - це може бути як сторінка на сайті нападника, яку він підготував для атаки і дав пошуковцю її проіндексувати, або це може бути сторінка взломаного сайта. Після чого, на цю сторінку розміщується malware чи інший контент (наприклад, для фішинга), і використовується робочий URL на images.google.com для проведення атаки.

Що цікаво, якщо розмістити на сторінці html-код для проведення фішинг атаки на користувачів Google, то бот скоріше за все цього не виявить. Тому можна буде не після індексації розміщувати цей код на сайт, а навіть до індексації - бот пошуковця спокійно проіндексує такі сторінки.

Аналогічний метод може використовуватися і на інших сайтах Гугла (так само й на сайтах інших пошукових компаній), де використовується обмеження по URL. Що тільки на заіндексовані сторінки, що є в БД системи, можна зайти при перегляді зображень, або може бути зроблений редирект (в редиректорі пошуковця).

Експлоіт для Apache mod_isapi

19:13 03.09.2011

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

Apache 2.2.14 mod_isapi Dangling Pointer

В даному відео ролику демонструється процес використання експлоіта для веб сервера Apache, зокрема для уразливості Apache 2.2.14 mod_isapi Dangling Pointer. Дана уразливість в Апачі дозволяє виконати довільний код на сервері з правами системи (SYSTEM на ОС Windows).

Атака відбувається при локальному запуску експлоіта, який створює шел на 4444 порту сервера. Рекомендую подивитися дане відео для розуміння векторів атак на веб сервери.

Ефективне використання клоакінгу проти веб антивірусів

22:45 02.09.2011

В своїх статтях Обхід систем для пошуку вірусів на веб сайтах (де я розповідав про використання клоакінгу) та Обхід поведінкового аналізу, або шкідливе ПЗ наносить удар у відповідь (де я розповідав про обхід систем, що базуються на поведінковому аналізі) я описав різні методи, які дозволяють обходити веб антивіруси. І для протидії шкідливому ПЗ на сайтах веб антивіруси повинні їх враховувати.

І нещодавно я виявив, що Гугл почав використовувати підробку (spoofing) User-Agent для своїх ботів. Що може бути пов’язано як раз з бажанням покращити ефективність роботи своєї системи виявлення вірусів на сайтах - щоб за допомогою клоакінга (а підробка UA є різновидом клоакінга) деклоакнути віруси на веб сайтах. З однієї сторони пошукові системи забороняють використовувати клоакінг проти них (відносять це до “чорних методів”), а ось тут виявляється, що і вони самі іноді полюбляють його використовувати :-) .

Але він використовує спуфінг неефективно і при продуманому використанні клоакінгу, шкідливе ПЗ може ефективно приховуватися від ботів Гугла та від ботів будь-яких пошукових систем, в тому числі тих, що мають вбудовані антивіруси.

Якщо раніше бот Гугла називав себе в заголовку User-Agent як “Googlebot” (наприклад, “Googlebot/2.1″), то з недавніх пір він іноді іменує себе як “MOZILLA 5.0″. З однієї сторони це може допомогти деклоакнути приховане malware на сайтах, але з іншої сторони цього недостатньо. Тому що просунуті віруси можуть перевіряти не тільки User-Agent, але й IP, а також робити зворотній пошук в DNS.

Зокрема для даного бота IP рівний 66.249.66.102, а домен - crawl-66-249-66-102.googlebot.com. Що дозволяє через резолвінг IP визначати, що це саме Googlebot. І навіть, якщо зробити інше доменне ім’я, але в записах WHOIS буде вказано, що цей IP належить Гуглу, то вірус може використати цю інформацію для створення списку IP (або робити запити до WHOIS в реальному часі) по яким буде приховувати себе від даних ботів.

Тобто ефективний клоакінг відбувається одразу по декільком параметрам: User-Agent, IP і DNS. І це давно відомі речі в світі клоакінгу (і коли я розробляв свою систему Web VDS я враховував не тільки User-Agent, але й інші параметри). І тому розробникам веб антивірусів, в тому числі пошукових систем з вбудованими антивірусами, потрібно це враховувати.

Обхід блокування по IP на сайтах

22:44 31.08.2011

В статті Обхід капч та блокування на сайтах я розповідав про один з методів обходу капч та блокування. А зараз я розповім вам про обхід блокування по IP. Це друга стаття з серії статей про методи обходу блокування на сайтах.

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

При наявності на сайті блокування по IP (на годину, чи 24 годину, чи навіть постійно блокування), зокрема в формах аутентифікації, що спрацьовує після декількох невдалих спроб логіна, є можливість обійти дане блокування. Що стане в нагоді при Brute Force атаках.

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

Для проведення Brute Force атаки з обходом блокування потрібно зробити наступні кроки:

1. Створити робочий акаунт на цільовому сайті.

2. Виявити межу блокування - після скількох невдалих спроб логіна відбувається блокування (наприклад, 15).

3. Використати метод обходу для проведення Brute Force атаки з метою підбору паролів.

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

І таким чином блокування по IP обходиться і можна нескінченно брутфорсити з одного IP. Тому розробникам захисних механізмів потрібно коректно їх реалізовувати.

Як захисти веб додатки з OWASP

19:11 27.08.2011

В своїй презентації How to secure web applications with OWASP, Santosh Satam розповідає про забезпечення безпеки веб додатків з використанням OWASP. Він розповідає про організацію OWASP, її проекти та інструменти.

Обхід капч та блокування на сайтах

22:42 20.08.2011

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

Це перша стаття з серії статей про методи обходу блокування на сайтах. Друга стаття - Обхід блокування по IP на сайтах.

Вперше я розробив подібну методику в 2009 році (та оприлюднив її торік), коли виявив уразливість на www.4post.com.ua, що дозволяла блокувати доступ користувача до сайта при спеціальному запиті. А при видаленні сесійного кукіса дане блокування можна було обійти. Про даний метод атаки я писав в статті Використання захисних механізмів для блокування доступу до сайта. Аналогічні можливості обходу блокування я неодноразово знаходив на різних сайтах в 2009-2011 роках.

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

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

В квітні я оприлюднив Brute Force уразливість в MyBB, коли з’являлася капча в формі логіна, яку можна було обійти використовуючи session reusing with constant captcha bypass method (який описаний в проекті MoBiC). Розробники тоді не виправили дану та інші уразливості (в випущеній MyBB 1.6.3). Але як нещодавно вияснив, вони встановили в нових версіях MyBB 1.6.3 і 1.6.4 по замовчуванню інший метод захисту (який є також і в попередніх версіях движка і використовується на більшості форумів на MyBB). Цей захисний метод замість капчі використовує обмеження на кількість спроб, але даний захист легко обійти використовуючи вищенаведений метод.

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

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

Експлоіт для Firefox

22:47 19.08.2011

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

Exploit for Firefox (CVE-2011-0073)

В даному відео ролику демонструється процес використання експлоіта для Mozilla Firefox, зокрема для уразливості MFSA 2011-13 Mozilla Firefox Nstreerangedangling Pointer Vulnerability. Дана уразливість в Firefox, що призводить до пошкодження пам’яті в браузері, була оприлюднена в травні.

Атака відбувається при відвідуванні в Firefox спеціально створеного веб сайта, що містить код експлоіту. Рекомендую подивитися дане відео для розуміння векторів атак на браузери.

Експлоіт для Microsoft Internet Explorer

22:41 04.08.2011

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

Exploit for Internet Explorer (CVE-2011-1256/MS11-050)

В даному відео ролику демонструється процес використання експлоіта для Internet Explorer, зокрема для уразливості MS11-050 IE mshtml!CObjectElement Use After Free. Дана уразливість в IE, що призводить до пошкодження пам’яті в браузері, була оприлюднена в червні (і виправлена в червневому вівторку патчів).

Атака відбувається при відвідуванні в IE спеціально створеного веб сайта, що містить код експлоіту. Рекомендую подивитися дане відео для розуміння векторів атак на браузери.