Positive Technologies про причини витоку інформації через пошукові системи.
Рейтинг статті: / 3
НайгіршеНайкраще 
Вівторок, 09 серпня 2011, 14:15
Витік данихДнями компанія Positive Technologies провела вебінар на тему «Чому стався Russian.Leaks?», присвячений випадкам масштабних витоків конфіденційної інформації через пошукові системи.
У ході заходу представники компанії пояснили, що послужило причиною останніх витоків, і розповіли про заходи запобігання подібних інцидентів.
У 2011 році в Рунеті стався цілий ряд витоків конфіденційної інформації через пошукові системи. Обговорення цієї теми почалося з витоку інформації з порталу wiki.yandex-team.ru, що стався в березні цього року: мережа внутрішньої вікі-документації для службового користування працівників «Яндекса» була проіндексована пошуковим роботом Google.
Найгучніший скандал пов'язаний з витоком SMS-повідомлень абонентів «Мегафон», відправлених з сайту оператора, про що стало відомо 18 липня.
В цей же день в блогах широко обговорювався аналогічний витік з сайту sms.prm.ru, де встигли відзначитися абоненти МТС, «Вимпелкому» («Білайн») і «Мегафона».
Потім, 25 липня, з'явилася інформація про замовлення в інтернет-магазинах, а наступного дня - про замовлення залізничних та авіаквитків.
Як зазначив доповідач - технічний директор компанії Positive Technologies Сергій Гордейчик, дане явище не нове: техніка пошуку конфіденційної інформації в пошукових машинах і веб-архівах відома давно. Відомим є термін Google Hacking Database - це збірка прийомів, за допомогою яких з пошукових машин можна витягати конфіденційну інформацію, шукати вразливі сервіси і т. д. У цілому було відзначено, що витік через пошукові системи трапляються по всьому світу, проте у зазначених вище випадках є декілька цікавих моментів.
Традиційно витік пов'язаний з найпростішими помилками в реалізації веб-сайтів. Це недостатня аутентифікація, коли сторінки веб-сервера, які повинні бути захищені від дистанційного перегляду, не проводять авторизацію користувача; веб-сайти, які дозволяють індексацію каталогів; невірні дозволу файлової системи сайтів, і небезпечна індексація, коли через локальні форми пошуку можна отримати конфіденційну інформацію з сайту.
До таких традиційних витоків доповідач відніс кілька випадків, що мали місце бути в рамках обговорюваної хвилі. Так, в фотоальбомах streamphoto.ru опубліковане користувачем посилання на закритий згодом альбом залишалося доступним в кеші. У соціальній мережі «В Контакте» приховані фотографії та посилання на них не видалялися навіть після видалення облікового запису. 27 липня було зафіксовано, що Google проіндексував відкритий файловий архів, що містить документи під грифом «Для службового користування» в доменах *. gov.ru.
У зв'язку з цим Сергій Гордейчик привів «інтернет-правило Міранди», сформульоване експертом з питань інформаційної безпеки Михайлом Емельянніковим на Positive Hack Days 2011: «Все, що Ви вказали про себе у соціальній мережі, блозі, форумі, чаті, якомусь загальнодоступному сервісі, буде зберігатися там вічно і завжди може бути використане проти Вас».
Більш складні уразливості традиційно експлуатуються вручну в рамках конкурентної розвідки. Це може бути підбір файлів і посилань - Brute Force, підбір простих імен користувачів і паролів до FTP-і файлових сховищ та інші методи добування інформації без злому ресурсів. Але в рамках останніх витоків у кеш пошукової машини потрапили дані, які до цього могли бути доступні тільки кваліфікованому хакеру.
Пояснюючи, як це могло статися, Сергій Гордейчик розповів, що після відправки веб-форми, будь-то SMS або замовлення, сайти повертали користувачеві сторінку статусу, яка містила детальну інформацію про передані дані, наприклад, номер телефону та текст повідомлення або найменування замовлення, його вартість та ім'я замовника. Ця сторінка ідентифікується унікальним значенням виду http://site/script/?id =, знаючи яке можна було переглянути сторінку.
Додаткова перевірка запиту по cookie або IP не виконувалася, тобто для отримання доступу до сторінки було досить знати це випадкове значення. Запобігти появі конфіденційної інформації в пошукових машинах повинно використання унікального значення в адресі і обмеження часу життя сторінки, тобто пошуковики просто не повинні були знати про існування такого посилання.
Зараз є офіційна відповідь «Яндекса», де представник інформаційної безпеки компанії Володимир Іванов повідомляє: «Ми вивчили ситуацію і з'ясували, що адреси сторінок з деяких хостів стали відомі «Яндексу» через встановлену на сайтах «Метрику». А оскільки в robots.txt цих сайтів заборони на індексацію сторінок не містилося, вони стали перебувати в «Яндексі». Особливо хочемо відзначити, що відвідування користувачем сторінки за допомогою браузера з встановленим «Яндекс.Бар» не приводило і не призводить до її індексації».
«Яндекс.Метрика» є сервісом, що дозволяє збирати статистику відвідування сайту. При установці на сайті лічильника даного сервісу адреси сторінок, включаючи унікальні значення, передаються в «Яндекс», який індексує і кешує їх. В результаті, навіть якщо на основному сайті сторінки видалялися, їх вміст залишався в кеші «Яндекса». Сергій Гордейчик додав, що в даний час «Яндекс» змінив поведінку «Метрики», знизивши ймовірність індексації подібних сторінок.
В офіційній відповіді Володимир Іванов згадав панель інструментів «Яндекс.Бар». Як пояснив доповідач, даний сервіс був під підозрою, тому що він передає адреси відвідуваних сторінок на сайти bar-navig.yandex.ru і backup-bar-navig.yandex.ru, і було висловлено припущення, що ці адреси також можуть бути використані пошукової машиною. За неофіційними заявами «Яндекса», передані UPL не беруть участь в індексації, а використовуються тільки для визначення тематичного індексу цитування. Однак при подальшому аналізі «Яндекс.Бара» виникло кілька запитань, на які Сергій Гордейчик дав відповіді.
Перше питання полягає в тому, що буде при використанні панелі інструментів «Яндекс», якщо при роботі з банком через Інтернет всі запити передаються по HTTPS. В даному випадку «ЯндексБар» буде передавати інформацію про зашифровані сторінки у відкритому вигляді. Здавалося б, те, що в мережі буде доступна адреса інтернет-банку, не грає ролі. Однак тут виникає інше питання: чи буде в цьому випадку передаватися конфіденційна інформація у відкритому вигляді? Відповідь на це питання позитивна в тому випадку, якщо служба дистанційного банківського обслуговування передає значення в параметрах URL-запиту.
Також доповідач згадав про те, що конфіденційна інформація у відкритому вигляді може бути передана в разі використання функції «Перевірка орфографії» в «Яндекс.Бар». Також Сергій Гордейчик звернув увагу на технологію «Вебвізор» в сервісі «Яндекс.Метрика», яка дозволяє записувати дії відвідувачів сайтів, будь то заповнення форм на сторінках або просто рух миші. У даному випадку також вся введена інформація буде зберігатися в базах даних «Яндекса».
На закінчення вебінару Сергій Гордейчик дав кілька порад, як запобігти витоку інформації через пошукові системи.
Адміністраторам веб-сайтов, як і взагалі всім користувачам, рекомендується уважно читати ліцензійні угоди, «шукати себе» в пошукових машинах і тестувати сайт за допомогою автоматичних утиліт, акуратно ставитися до зовнішніх компонентів, що встановлюються на сайт, і стежити за пов'язаними з ними уразливими, це стосується в тому числі банерних мереж, а також використовувати передовий досвід у галузі безпеки.
Корпоративним адміністраторам, які хочуть, щоб інформація з внутрішнього сайту не потрапляла в Інтернет по незахищених каналах, доповідач порекомендував фільтрувати на міжмережевих екранах різні лічильники, трафік «барів» і аналогічних програм.
Інтернет-користувачам також рекомендується уважно читати ліцензійну угоду і фільтрувати різні лічильники за допомогою додаткових компонентів, таких як NoScript, AdBlock, або вбудованих можливостей браузера.
Як післямова доповідачем було відзначено, що вебінар не мав мети показати недоліки «Яндекса»: акцент був зроблений на дану систему через те, що розглянуті витоки були пов'язані з нею, однак більшість пошукових машин мають схожі функції і схожі проблеми.
(Джерело RU: ict-online.ru)
 
>
КнигаНовиниПрактика пошукуПартнериПро нас
Підтримка та дизайн: Могильний С.С. Шаблон: Joomla Templates by BuyHTTP Joomla Hosting