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

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

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

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

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

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

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

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

І нещодавно я виявив, що Гугл почав використовувати підробку (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. Це друга стаття з серії статей про методи обходу блокування на сайтах.

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

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

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

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

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

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

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

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

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

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

В різних формах на сайтах, зокрема в формі логіна, можуть використовуватися такі захисні методи як капча та тимчасове блокування. В формі логіна дані методи захищають від 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.

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

Exploit for Firefox (CVE-2011-0073)

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

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

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

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

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

Ідея цього методу в мене виникла ще в травні, одразу після мого виступу на конференці UISG та ISACA Kiev Chapter з доповіддю про системи виявлення інфікованих веб сайтів. Тоді, після мого виступу, багато людей вирішили поговорити зі мною в кулуарах на цю тему, і задали багато цікавих питань про веб антивіруси і мою WebVDS. І зокрема в розмові ми торкнулися методів обходу таких систем, де я і розповів про клоакінг, про який писав в вищезгаданій статті в 2010 році. А вже як повернувся додому, в мене виникла нова ідея, про яку я зараз розповім.

Повідінковий аналіз вважається більш ефективним методом виявлення шкідливого програмного забезпечення ніж сигнатурний чи еврестичний метод. Серед веб антивірусів є лише дві системи, які відомі мені, що використовують повідінковий аналіз. Це вбудовані антивіруси в пошукових системах Google і Yandex. В Яндексі повідінковий аналіз додали на початку 2010 року і, по заяві компанії, вони одночасно використовують як першу технологію (від Sophos, що явно базується на сигнатурах), так і другу. Зазначу, що обидві ці системи приймали участь в моєму минулорічному тестуванні систем пошуку вірусів на веб сайтах, в якому з семи учасників Гугл заяняв 1 місце, а Яндекс 7 місце.

Для обходу поведінкового аналізу шкідливе ПЗ може використати наступні методи:

1. Виявлення факту, що веб сторінка запущена в браузері в віртуальній машині. Враховуючи, що через JS/VBS неможливо визначити це, то єдиний ефективний варіант - це клоакінг, про який я розповідав вище. Але просунуті веб антивіруси можуть боротися з ним, тому необхідний інший варіант.

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

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

В своїй презентації Guidelines on Securing Public Web Servers, представники National Institute of Standards and Technology (NIST) розповідають про забезпечення безпеки публічних веб серверів. Це офіційні рекомендації американського NIST (датовані 2007 роком).