Зламати сейф: Результати тестування на проникнення в банк
Хранителі фінансових фортець - роль тестування на проникнення
У сучасному цифровому світі, де постійно існує небезпека витоку даних і кібератак, неможливо переоцінити важливість зміцнення захисту від кіберзлочинності. У міру того як технології безперервно розвиваються, розвиваються і тактики та методи, які використовують кіберзлочинці. У відповідь на ці безперервні загрози організації, особливо ті, що працюють у фінансовому секторі, опиняються в постійній боротьбі за оцінку і зміцнення своїх заходів безпеки.
Фінансові установи, зокрема банки, є головною мішенню для кіберзлочинців через величезні масиви конфіденційних фінансових і персональних даних, які вони зберігають у своїх цифрових сховищах. Наслідки одного порушення безпеки в таких установах можуть бути катастрофічними - від величезних фінансових втрат і серйозного репутаційного збитку до штрафних санкцій з боку регулюючих органів. Тому фінансові організації змушені займати проактивну позицію, коли йдеться про захист їхніх систем і збереження скарбниці даних.
У межах цієї статті ми вирушимо в подорож у сферу тестування на проникнення з особливим акцентом на його застосування у фінансовому секторі. Наша мета - висвітлити значення цієї практики і зрозуміти, як вона служить для фінансових установ необхідним захистом від постійно мінливого ландшафту кіберзагроз.
Крім того, ми розглянемо переконливий приклад успішного тесту на проникнення в банк. У цьому конкретному випадку було виявлено критичні вразливості як технічного, так і бізнес-логічного характеру. Варто зазначити, що з метою забезпечення конфіденційності та безпеки клієнта всі ідентифіковані дані, що ідентифікуються, і назву банку було анонімізовано. Це підкреслює першорядну важливість угод про нерозголошення (NDA) і взаємної довіри між клієнтом і командою тестування на проникнення.
Визначення поля бою - обсяг випробування на проникнення
Нещодавно XYZ Bank, відома фінансова установа, відома своєю прихильністю до безпеки та інновацій, звернулася до нашої компанії CQR за допомогою у зміцненні свого цифрового захисту. Мета була чіткою: комплексний тест на проникнення та оцінка безпеки, спрямована на оцінку надійності їхнього веб-додатку.
У цій спільній роботі клієнт довірив нам два рахунки, ретельно розроблені для відображення профілів реальних банківських клієнтів. На ці рахунки було зараховано певну суму валюти, щоб полегшити виконання фінансових транзакцій під час тестування.
Працюючи в рамках підходу тестування "сірого ящика", наша місія полягала у виявленні вразливостей, як технічних, так і в сфері бізнес-логіки, які потенційно можуть становити загрозу безпеці банку.
У цьому проекті час мав вирішальне значення, оскільки на проведення власне тестування на проникнення було відведено 1,5 місяці. Що стосується розміру нашої команди з тестування на проникнення, то ми вирішили залучити чотирьох висококваліфікованих і досвідчених фахівців на власний розсуд. Їхній досвід охоплював різні аспекти кібербезпеки, що забезпечило ретельну та різнобічну перевірку цифрової інфраструктури банку.
Під час тестування на проникнення ми застосували багатогранну стратегію. Вона охоплювала оцінку вразливостей, атаки грубої сили, тестування на експлуатацію, глибоку розвідку та великий збір даних. Кожен аспект відігравав життєво важливу роль у моделюванні реальних загроз і наданні цілісної оцінки стану безпеки банку.
Вивчення виявлених слабких місць у системі безпеки:
Уразливість № 1
Обхід 2FA та несанкціоноване заволодіння акаунтом
Під час нашої оцінки веб-додатку банку було виявлено кілька вразливостей, які, будучи об'єднаними разом, призвели до заволодіння рахунком. Ці вразливості включали
- Програма повертала помилку "Неправильний пароль" замість "Недійсні облікові дані" при спробі входу в систему, що дозволяло знаходити існуючі облікові записи методами грубої сили.
- Відсутність обмеження швидкості, що дозволяє атакувати невідомі параметри, такі як OTP, методом грубої сили.
- Відсутність валідації файлів cookie в додатку, що дозволяє ініціювати зміну пароля в акаунті іншого користувача шляхом маніпуляції з одним параметром (який відносно легко отримати).
Щоб відтворити цю атаку, ми виконали такі дії:
Зайдіть на сайт і перейдіть у розділ "Забули пароль?".
Введіть адресу електронної пошти, увімкніть функцію перехоплення і введіть будь-який SMS-код, перехопивши запит, що містить цей код.
POST /api/client/pwd/recovery?otp=1234&refid=XEqVyp6j7zLSVANzrVkGUrw6JwR67T
Ми помітили, що "refid" не змінювався під час кожного нового запиту, що дало нам змогу перебрати всі можливі комбінації кодів (10 000) без обмежень за швидкістю. На щастя, на 1 567-й спробі ми знайшли відповідне значення "otp" (1567), і сервер відповів 200 OK, надавши нам доступ до обходу 2FA.2.
Отримавши ці знання, ми вирішили досліджувати далі. Знаючи, що сервер не перевіряє cookies, і розуміючи, як ідентифікувати будь-який обліковий запис (у нашому випадку логін був admin@xyz_bank.com), ми спробували змінити пароль за допомогою функції відновлення пароля.
Ми перехопили запит на зміну пароля для нашого облікового запису через Password Recovery:
PATCH /api/client/pwd/recovery?update_password=Test12345&refid=XEqVyp6j7zLSVANzrVkGUrw6JwR67T
Де "refid" був ідентифікатором нашого облікового запису, а "update_password" було встановлено значення "Test12345“.
Після цього ми спробували увійти в систему під логіном "admin@xyz_bank.com", використовуючи неправильний пароль. Сервер видав помилку "Неправильний пароль". Це підтвердило, що обліковий запис "admin@xyz_bank.com" існував у системі, просто ми ще не знали пароль. За допомогою цього запиту нам вдалося перехопити ідентифікатор облікового запису "refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x.”
Потім ми використовували ідентифікатор облікового запису і встановили новий пароль для нього:
PATCH /api/client/pwd/recovery?update_password=Hackers_PASSWORD&refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x
Ми переконалися, що пароль до облікового запису іншого користувача дійсно був успішно змінений. Ми увійшли в систему, використовуючи логін "admin@xyz_bank.com" і наш новий пароль, "Hackers_PASSWORD". Потім ми провели брутфорсинг 2FA-коду за параметром "otp", який, на щастя, вдалося виконати на 2 143-му запиті.
POST /api/client/pwd/recovery?otp=2143&refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x
Таким чином, ми успішно авторизувалися в обліковому записі іншого користувача.
Ми негайно повідомили банку про цю критичну вразливість, як того вимагає протокол пентестування. Крім того, ми рекомендували впровадити сувору перевірку облікових даних, запровадити обмеження швидкості спроб автентифікації, особливо для таких чутливих операцій, як перевірка OTP, і впровадити належну перевірку файлів cookie для підвищення безпеки та запобігання несанкціонованим діям. Ці заходи спрямовані на зміцнення безпеки веб-додатку банку та зниження ризику виникнення подібних вразливостей у майбутньому.
Уразливість № 2
Маніпуляції з валютою - прибуток від помилок округлення
Уявіть собі ситуацію, коли під час обміну валюти з LocalCoin на NewCoin можна було швидко придбати 1,00 NewCoin лише за 1474,50 LocalCoin, тоді як офіційно встановлений банком курс продажу становив 1482,00 LocalCoin за 1,00 NewCoin. Така значна розбіжність у 7,50 LocalCoin за 1 NewCoin давала змогу користувачам з легкістю збільшувати свої баланси в геометричній прогресії.
Суть цієї вразливості полягала в неправильному округленні дробових чисел у системі - незначна на перший погляд помилка, яка мала серйозні наслідки.
Для усунення цієї вразливості було рекомендовано правильно налаштувати обробку транзакцій обміну валюти. Зокрема, необхідно було вжити заходів, щоб запобігти виконанню користувачами транзакцій, коли введена користувачем сума LocalCoin була меншою за 1,00 одиниці іноземної валюти за курсом банку на момент транзакції. Реалізувавши цей коригувальний захід, який включає в себе не тільки коригування обробки транзакцій, а й належну перевірку округлення в системі, банк зміг ефективно запобігти використанню користувачами цієї розбіжності і зберегти цілісність своїх операцій з обміну валюти.
Уразливість № 3
Уразливість маніпулювання валютними курсами
Під час тестування веб-додатку XYZ Bank на проникнення ми виявили суттєву вразливість, яка дозволяла користувачам маніпулювати курсами валют у своїх інтересах. Цей недолік дозволяв користувачам здійснювати обмін NewCoin на ForeignCoin за курсом купівлі банку, а не за передбачуваним курсом продажу.
Ба більше, у рамках цієї транзакції користувачі мали можливість не тільки обміняти свої ForeignCoin назад на NewCoin, а й зробити це за курсом, нижчим, ніж курс продажу банку, отримавши таким чином прибуток. Використовуючи цю вразливість за допомогою двох послідовних транзакцій, користувачі могли підтримувати свій баланс ForeignCoin, накопичуючи при цьому додаткові NewCoin.
Ця вразливість була пов'язана з неправильним округленням дробових чисел у системі, що призводило до розбіжностей між офіційними курсами валют і тими, які реально застосовувалися під час транзакцій.
Загалом, ця вразливість давала змогу користувачам обмінювати валюту за вигідними курсами, що в кінцевому підсумку призводило до несправедливої фінансової вигоди. Для вирішення цієї проблеми ми рекомендували впровадити сувору політику обміну валюти, щоб не дозволити користувачам змінювати курси на стороні клієнта. Крім того, рекомендується переглянути правила округлення в системі, щоб гарантувати, що клієнти не зможуть використовувати валютні перекази між своїми рахунками для нарахування додаткових коштів.
Ця вразливість наражала банк XYZ на потенційні фінансові втрати через неправильний розрахунок обмінних курсів, підкреслюючи важливість надійних заходів безпеки у фінансовому секторі.
Уразливість № 4
Проблема експлуатації облікових даних за замовчуванням
Крім того, під час тестування на проникнення веб-додатка банку XYZ ми натрапили на вразливість серйозного значення - портал надавав користувачам підвищені привілеї при введенні загальних облікових даних "admin" і "admin". Ця точка входу, яка нічого не підозрює, відчиняла двері до домену адміністратора, наділяючи користувачів потужними можливостями, які потенційно могли порушити й пошкодити основну структуру застосунку.
Ця вразливість продемонструвала ризики, пов'язані з налаштуваннями за замовчуванням і передбачуваними шляхами адміністративного доступу. Використання загальних облікових даних за замовчуванням і шляхів, які легко вгадуються, надавало неавторизованим користувачам ненавмисний доступ до чутливих функцій, які мали бути суворо захищені.
Щоб відтворити цю вразливість, зловмисник може виконати такі нескладні дії:
1. Перейдіть за таким посиланням: https://XYZ_Bank.com/admin/login
2. Увійдіть в обліковий запис, використовуючи стандартні облікові дані "admin" і "admin".
У разі успішного входу користувач отримував необмежений доступ до панелі адміністратора, що давало змогу здійснювати потенційно шкідливі дії в ролі адміністратора. Ця вразливість являла собою значний ризик для безпеки і конфіденційності програми.
По-перше, ми порадили змінити стандартні облікові дані на унікальні та складні, щоб запобігти несанкціонованому доступу. По-друге, ми запропонували налаштувати шляхи входу в систему, щоб усунути передбачуваність. Крім того, ми запропонували впровадити двофакторну аутентифікацію (2FA) для додаткового рівня безпеки, а також розгорнути на сторінках входу в систему завдання CAPTCHA для протидії автоматичним атакам. І нарешті, для запобігання спробам грубої сили було рекомендовано обмеження швидкості, що в сукупності підвищило рівень безпеки XYZ Bank.
Уразливість № 5
Небезпечне пряме посилання на об'єкт (IDOR) -
Уразливість необмеженого доступу до даних
Під час комплексного тестування веб-додатка банку на проникнення ми виявили критичну вразливість, відому як Insecure Direct Object Reference (IDOR). Ця вразливість, тісно пов'язана з контролем доступу, виникає, коли додаток використовує введені користувачем дані для прямого доступу до об'єктів, що призводить до несанкціонованого доступу до конфіденційної інформації.
Щоб відтворити цю вразливість, необхідні два облікові записи користувачів: User1 і User2. Наступні кроки розкривають проблему:
1. Увійдіть у застосунок під ім'ям User1 і надішліть запит на підтримку в банк через розділ "Інформація" > "Підтримка користувачів" > "Надіслати запит у банк".
2. Перехватите запрос и загрузите документ в запрос поддержки.
3. надішліть запит і вкажіть шлях, де спочатку зберігався документ, а саме "absolutePath” parameter.
4 Тепер відкрийте URL у браузері з параметром "absolutePath" і додайте в запит токен Bearer: https://XYZ_Bank.com/api/blobs/security/{{User1RandomString}}?token={{User1’s Bearer Token}}. Переконайтеся, що документ завантажено.
5. Потім увійдіть у додаток, використовуючи облікові дані користувача User2, і створіть запит до служби підтримки, виконавши ті самі дії, що й раніше. Знайдіть рядок "absolutePath" документа для користувача User2.
6. Тепер змініть випадковий рядок у полі "absolutePath" користувача1, щоб збігтися з "absolutePath" документа користувача User2. Відкрийте URL-адресу: https://XYZ_Bank.com/api/blobs/security/{{User2RandomString}}?token={{User1’s Bearer Token}}. Ви помітите, що документ користувача User2 завантажується з використанням токена Bearer користувача User1.
Цю вразливість було виявлено на 11 кінцевих точках у веб-додатку для кількох банківських сервісів.
Потенційний вплив цієї вразливості дуже великий, оскільки вона дає змогу будь-якому користувачеві маніпулювати "absolutePath" для доступу, завантаження або маніпулювання даними іншого користувача. Для розв'язання цієї проблеми ми настійно рекомендували впровадити сувору перевірку процесів ідентифікації та авторизації користувачів з використанням усіх зумовлених параметрів, а не покладатися тільки на один параметр. Таким чином банк зможе знизити ризик несанкціонованого доступу до даних і захистити конфіденційність призначеної для користувача інформації.
Уразливість № 6
Міжсайтовий скриптинг (XSS) - загроза неконтрольованого введення даних користувачем
Під час оцінки веб-додатку банку ми виявили критичну вразливість, відому як міжсайтовий скриптинг (XSS). Цей недолік виникає, коли застосунок не може належним чином перевірити дані, які вводить користувач, що призводить до потенційних скриптових атак, які можуть поставити під загрозу дані користувача і безпеку застосунку.
У цьому випадку застосунок не перевіряв належним чином дані, що надаються користувачем, що давало змогу зловмисникам впроваджувати спеціально створені URL-адреси або завантажувати шкідливі файли. Такі атаки можуть призвести до різних загроз, включно з відкритим переспрямуванням, перехопленням сеансу та багато іншого. Щоб відтворити атаку, зловмиснику достатньо було відвідати підроблену URL-адресу, наприклад:
https://XYZ_Bank.com/searching.html?keywords=%3Cscript%3Ealert(document.cookie)%3C/script%3E
Цей URL (розшифроване значення: https://XYZ_Bank.com/searching.html?keywords=<script>alert(document.cookie)</script>) викликає спливаюче вікно, що відображає сесійні файли cookie користувача, що дає змогу розкрити конфіденційну інформацію. Ця вразливість може потенційно розкрити дані користувача і призвести до різних ризиків безпеки.
Вплив цієї XSS-вразливості дуже великий, оскільки вона дає змогу зловмисникам виконати довільний код у браузері користувача. Для зниження цього ризику ми рекомендуємо використовувати надійні конфігурації брандмауера і ретельну перевірку введення перед виконанням даних, наданих користувачем. Використання значення "nonce" може запобігти виконанню зовнішнього JavaScript. Крім того, рекомендується обмежити зберігання шкідливих і несанкціонованих розширень файлів, що підвищить загальну безпеку програми.
Виконавши ці рекомендації, банк зможе захистити своїх користувачів від потенційних атак на основі сценаріїв і зберегти цілісність свого веб-додатка.
Classification of Bank Penetration Test Results
У результаті проведеної нами оцінки безпеки систем банку їх було розподілено за категоріями серйозності:
10 висновків класифіковано як критичні/високі, 11 - як середні, 13 - як низькі та 1 - як інформаційні.
Ця класифікація дає змогу отримати повне уявлення про систему безпеки банку:
Висновок
Проведений нами тест на проникнення в системи банку виявив не тільки очікувані вразливості середнього та низького ступеня тяжкості, а й такі серйозні проблеми, як "обхід 2FA і несанкціоноване захоплення акаунта", про які ми розповідали раніше. Ці дані підкреслюють нагальну необхідність регулярного тестування на проникнення у фінансові установи. Виявлені вразливості, починаючи від обходу 2FA і закінчуючи маніпуляціями з курсами валют і XSS-загрозами, ілюструють різноманітні вектори атак, які можуть використовувати зловмисники. Визначення поля бою, розуміння масштабів таких тестів на проникнення і своєчасне усунення вразливостей мають першорядне значення для захисту цілісності фінансових установ.
Розкриваючи ці вразливості, ми наголошуємо на важливості надійних протоколів безпеки та постійної пильності, необхідної в епоху швидкого розвитку кіберзагроз. Проведення ретельних тестів на проникнення - це не просто передова практика, це необхідний захід захисту не тільки самої установи, а й, що ще важливіше, конфіденційної фінансової інформації її клієнтів.
Інші Послуги
Insomnia Security Scanner
AI-powered web application security scanner by CQR. Automated vulnerability discovery, exploit verification, and detailed reporting for modern applications.
Дізнатися більше
Захист інфраструктури CRYEYE
Аудит безпеки за допомогою CryEye забезпечує інформаційну безпеку підприємства, захищаючи всю інфраструктуру.
Дізнатися більше Тестування на проникнення
Знайдіть вразливості у всій інфраструктурі вашого бізнесу раніше, ніж це зроблять хакери! У межах консалтингу з тестування на проникнення ми підберемо методи пентестів та інші індивідуальні рекомендації з кібербезпеки для вашого бізнесу.
Дізнатися більше Соціальна Інженерія
Simulate real-world phishing, vishing, and pretexting attacks to measure and improve your team's security awareness and response capabilities.
Дізнатися більше Тестування Продуктивності
Усі види тестування навантаження і продуктивності вашої системи від компанії CQR, що спеціалізується на онлайн-безпеці.
Дізнатися більше AI-Powered Vulnerability Assessment
Leverage artificial intelligence to discover, prioritize, and remediate vulnerabilities across your digital assets faster and more accurately than traditional scanners.
Дізнатися більше Cloud Security Audit (AWS / GCP / Azure)
Comprehensive security review of your cloud environments — IAM policies, network controls, data exposure, and misconfigurations across all major cloud platforms.
Дізнатися більше DevSecOps Integration
Embed security into every stage of your CI/CD pipeline. Automated SAST, DAST, SCA, and secret scanning so vulnerabilities are caught before they reach production.
Дізнатися більше API Security Testing
In-depth testing of REST, GraphQL, and SOAP APIs for authentication flaws, authorization bypasses, injection vulnerabilities, and data leakage risks.
Дізнатися більше Mobile Application Penetration Testing
Manual and automated security testing for iOS and Android applications — reverse engineering, runtime analysis, traffic interception, and backend API assessment.
Дізнатися більше IoT Security Assessment
Evaluate firmware, communication protocols, cloud backends, and physical interfaces of IoT devices to identify vulnerabilities before attackers do.
Дізнатися більше Blockchain & Smart Contract Audit
Formal verification and manual code review of smart contracts on Ethereum, Solana, and other chains. Detect reentrancy, overflow, and logic flaws before deployment.
Дізнатися більше Red Team Operations
Advanced adversary simulation using real attacker TTPs (MITRE ATT&CK) to test your detection, response, and overall security posture under realistic conditions.
Дізнатися більше Threat Intelligence & Monitoring
Continuous monitoring of threat feeds, dark web, and attacker infrastructure to provide actionable intelligence specific to your organization and industry.
Дізнатися більше Zero Trust Architecture Review
Assess and design your Zero Trust security model — identity verification, micro-segmentation, least-privilege access, and continuous validation controls.
Дізнатися більше Compliance Consulting (PCI DSS / SOC 2 / GDPR)
Expert guidance to achieve and maintain compliance with major security frameworks. Gap analysis, remediation roadmaps, and audit-readiness support.
Дізнатися більше Dark Web Monitoring
Continuous surveillance of dark web forums, marketplaces, and breach databases for leaked credentials, sensitive data, or mentions of your organization.
Дізнатися більше Phishing Simulation & Awareness Training
Controlled phishing campaigns combined with interactive security awareness training to build a human firewall across your entire organization.
Дізнатися більше Supply Chain Security Audit
Assess third-party vendor risks, open-source dependencies, and software supply chain integrity to prevent attacks like SolarWinds and Log4Shell.
Дізнатися більше Container & Kubernetes Security
Security review of Docker images, Kubernetes clusters, RBAC policies, network policies, and runtime configurations to harden your container infrastructure.
Дізнатися більше Web Application Firewall (WAF) Deployment
Professional WAF setup, rule tuning, and ongoing management to block SQL injection, XSS, CSRF, and other OWASP Top 10 threats in real time.
Дізнатися більше Bug Bounty Program Management
Full lifecycle management of your bug bounty program — scope definition, researcher coordination, triage, validation, and remediation tracking.
Дізнатися більше OSINT Investigation Services
Open-source intelligence gathering on individuals, organizations, and infrastructure. Ideal for pre-engagement recon, fraud investigation, and competitive analysis.
Дізнатися більше Digital Forensics & Incident Response
Rapid response to security breaches — evidence collection, malware analysis, attacker timeline reconstruction, and actionable remediation recommendations.
Дізнатися більше