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

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

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

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

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

Зокрема те, що з 22.09.2011 не працює дірявий сайт www.foxtrot.com.ua - це цілком може бути пов’язано з обшуками, що з недавніх пір проводить МВС в офісах Фокстрота. І в подібній ситуації може опинитися будь-який власних дірявого сайта.

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

В статті Безопасность расширений Google Chrome - привычные векторы атак в контексте аддонов для браузера розповідається про безпеку розширень до браузерів, зокрема до Google Chrome. Про вектори атак через доповнення до браузера.

В даній статті розглянуті наступні аспекти безпеки розширень Google Chrome:

• XSS.
• Кукіси.
• Дані веб браузера як ціль для атаки.
• Фішинг.
• Ризики, пов’язані з використання JSON.
• Впроваджуємі скрипти.

Використання стандартних веб технологій (таких як HTML, CSS і JavaScript) для розробки доповнень, призводить до появи уразливостей в аддонах до браузерів, аналогічних тим, які ми зустрічаємо у веб додатах. Тому розробникам доповнень до браузерів (так само як і плагінів, таких як Flash та інші) слід краще слідкувати за безпекою власних програм.

В презентації Mc Graw Hill Hacking Exposed Web 2.0, наводиться повний текст книги “Hacking Exposed Web 2.0″. В якій розповідається про вразливий до хакінгу Web 2.0. Про те, які ризики безпеки існують в Веб 2.0 додатках та як від них захиститися.

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

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

• Privacy-invasive software
• Keystroke logging
• Cross-application scripting
• Evasion (network security)
• Uncontrolled format string

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

“Icon Ninjas” Internet Security PSA

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

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

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

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

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

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

В 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. Тому розробникам захисних механізмів потрібно коректно їх реалізовувати.