У 2015 році майже три десятка великих банків Росії стали жертвами хакерських атак, втрати від яких тільки з жовтня минулого року складають близько двох мільярдів рублів за даними ЦБ РФ . Можна говорити, що зловмисники переорієнтувалися з клієнтів банків - фізичних та юридичних осіб, на самі банки.

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

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

• ін'єкції (SQL-ін'єкції, XPATH-ін'єкції, XSS),
• небезпечна настройка елементів інфраструктури (веб-сервера, DNS-сервера),
• доступ до файлів по небезпечним прямими посиланнями,
• використання ПЗ з відомими критичними уразливими,
• відкрите перенаправлення.

Найголовніше - це результати

В результаті проведеного дослідження було виявлено понад 60 вразливостей на 41 банківському сайті. Таким чином, майже три чверті з аналізованих банків мали недоліки в системі захисту своїх сайтів.

На 7 з 56 сайтів були виявлені вразливості високого ступеня критичності. Це означає, що у зловмисників була можливість зламати сайти 7 банків, прикладаючи мінімум зусиль. У ряді випадків це дозволило б потрапити у внутрішню мережу банку і провести атаку на критичні активи, наприклад, на АРМ КБР (Автоматизоване робоче місце клієнта Банку Росії (АРМ КБР) - програмний комплекс для відправки платіжних документів від банку в ЦБ РФ.

Зведена статистика по банках наведена на малюнку нижче.

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

Уразливості низького ступеня критичності самі по собі небезпеки не несуть, але надають зловмисникові інформацію, яка може стати в нагоді для експлуатації інших вразливостей в ході реалізації більш складних атак.

Копнемо трохи глибше

Серед вразливостей високого ступеня критичності частіше всіх зустрічалися ін'єкції, в т.ч. SQL-ін'єкції. Такі ін'єкції дозволяють впровадити в легітимний запит до системи управління базою даних веб-додатки довільний SQL-код. наприклад:

http://example.com/news.php?id=10 UNION SELECT 1, username, password, 1 FROM admin

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

Хорошим тоном при розробці вважається використання технології ORM , Яка дозволяє значно спростити роботу з СУБД. В якості приємного бонусу сучасні бібліотеки ORM також дозволяють убезпечити додаток від SQL-ін'єкцій.

Небезпечна конфігурація є причиною появи приблизно половини всіх вразливостей. У цю категорію потрапляють використання застарілого ПЗ на веб-серверах і відсутність базових засобів захисту, наприклад, web application firewall.

Також до небезпечної конфігурації можна віднести можливість доступу до резервних копій (наприклад, example.com/db_dump.zip) і службових файлів і елементів інтерфейсу адміністратора (особливо якщо для адміністрування не потрібно авторизація).

Джерело бід на 99%

У більшості випадків джерелом вразливостей на сайтах є люди, яким властиво допускати помилки, в тому числі ненавмисно. Наведемо характерні приклади, які були виявлені в ході дослідження:

1. На одному з сайтів була виявлена уразливість Heartbleed в криптографическом програмному забезпеченні OpenSSL, що дозволяє несанкціоновано читати оперативну пам'ять веб-сервера. При експлуатації цієї уразливості на невисоконагруженних серверах досить швидко вдається отримати приватний ключ шифрування веб-сервера, що дозволяє зловмисникові розшифровувати трафік TLS / SSL-з'єднань з сайтом. Патч, що усуває цю вразливість, був випущений 2 роки тому.

2. У мережі можна зустріти багато файл-менеджерів, що пропонують простий спосіб їх вбудовування в уже існуючий сайт. Не у всіх з них є які-небудь механізми аутентифікації користувача. Мабуть, найяскравіший приклад - CKFinder. Розробники пропонують користувачам самостійно реалізувати механізм аутентифікації. Як можна здогадатися, роблять це не все. В результаті будь-який бажаючий може керувати вмістом безлічі сайтів .

3. Величезна кількість технологічного сміття, що залишилося після розробки, було виявлено на проаналізованих сайтах. Таке сміття дозволяє дізнатися не тільки подробиці про внутрішній устрій сайту, але часом і отримати доступ до його вихідного коду, що полегшує подальший пошук вразливостей зловмисникові. Наприклад, під час запуску сайту часто забувають видалити службові каталоги систем управління версіями (.git, .svn, .hg і т.д.). Структура цих каталогів така, що знаючи формат зберігання даних (а він, як правило, документований), можна завантажити собі по одному файлу весь вміст сховища, тобто вихідний код сайту. Володіючи вихідним кодом, зловмисникові набагато простіше шукати уразливості і недокументовані можливості сайту.

Що ж робити?

Зловмисники поступово усвідомлюють, що чим зробити багато дрібних крадіжок у клієнтів, простіше вкрасти один раз велику суму у банку. Як показує недавній інцидент з фішинговими листами від підробленого FinCERT , Зловмисники також обізнані про внутрішню кухню забезпечення ІБ в банках. Пора приділити увагу актуальним загрозам - атакам на сайти банків (та інші ресурси, доступні з інтернету), атакам на АРМ КБР, фішингу з соціальною інженерією, і вжити заходів щодо захисту.

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