Вступ

Якщо ми розглянемо програми баг баунті, кажучи просто, поверхні атак на аплікації приблизно можна розділити на безкоштовний/легкий доступ і платний/важкодоступний. Баг баунті хантери та пентестери (якщо доступ не надано) часто покривають лиш перший, оскільки тестування там не потребує додаткових фінансових інвестицій чи необґрунтованої кількості часу/зусиль. І ці сумніви цілком зрозумілі, тому що складно прорахувати ризики через їх негарантовану рентабельність. Але як фулл-тайм баг баунті хантер, я вважаю, що доступ до нерозвіданої поверхні атаки часто є перевагою в конкурентному середовищі. Купівлю доступу варто розглянути, якщо потенційна рентабельність (👀таблиця баунті👀) значно перевищує фінансові інвестиції. У цій статті ми розглянемо один із таких типів доступу – подарункові картки. Я придбав понад 30 подарункових карток для цього дослідження та, розблокувавши нові функції, виявив 9 вразливостей, що в сумі принесли мені $6,500.

Баг #1: Race condition під час активації коду подарункової картки та переказ грошей автору призводить до фінансових втрат компанії

Додаток представлений в скопі баг баунті програми — це, по суті, ринок із шанувальниками та творцями як двома основними типами користувачів. Шанувальники можуть купувати товари від творців і оплачувати класичним способом за допомогою кредитної картки. Також є можливість оплачувати товари альтернативно за допомогою поповнення балансу рахунку акаунта. Оскільки одним із способів поповнення балансу є подарункова картка, ми можемо зареєструвати обліковий запис творця та платити собі з рахунку шанувальника, використовуючи баланс. Таким чином, будь-яка вразливість, пов’язана з TOCTOU (time to check time to use), під час використання подарункових карток потенційно дозволить маніпулювати балансом автора та призведе до фінансових збитків для компанії.

Інтерфейс за адресою /giftcard дозволяє нам встановити мінімальну суму подарункової картки в $5, що мене цілком влаштувало. Під час процедури оплати я отримав повідомлення про помилку, яке говорило про те, що країна моєї кредитки не підходить і що приймаються лише американські картки. Однак, відмовляючись здаватися (і відчуваючи легку дискримінацію щодо платіжних привілеїв), я звернувся до своїх колег на Bug Bounty Forum Slack, один з яких люб’язно надав мені доступ до віртуальної кредитки банку США. Я застосував ії разом із додатковими даними та отримав дійсну подарункову картку на $5, якою отримав можливість погратися.

Перейшовши до /redeem з двох облікових записів шанувальників, надіславши запити на активацію, перехопивши їх і застосувавши в Turbo Intruder, я поповнив баланс сайту на суму $10 за допомогою подарункової картки вартістю $5!

Скрипт Turbo Intruder, про який йде мова, виглядав так:

### Add a request to the turbo intruder, erase the request, enter %s.
### Don't forget to change a path in a and b vars

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=2,
                           requestsPerConnection=2,
                           pipeline=False
                           )
    a = open("/Users/max/intruder1.txt", "r")
    b = open("/Users/max/intruder2.txt", "r")
    # the 'gate' argument blocks the final byte of each request until openGate is invoked
    for i in range(1):
        engine.queue(target.req, a.read(), gate='race1')

    for i in range(1):
        engine.queue(target.req, b.read(), gate='race1')

    # wait until every 'race1' tagged request is ready
    # then send the final byte of each request
    # (this method is non-blocking, just like queue)
    engine.openGate('race1')

    engine.complete(timeout=60)

def handleResponse(req, interesting):
    table.add(req)

Модель атаки:

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

Баг було прийнято з критичним рівнем ризику та виправлено протягом одного дня.

Баг #2: HTML injection в email листі подарункової картки через /giftcard

Заголовок не потребує пояснень — ми можемо відобразити HTML-теги в електронному листі зі сповіщенням про покупку подарункової картки через ім’я одержувача та саме повідомлення. Хоча спочатку я мав намір перевірити, чи є template injection, HTML-теги, які я надіслав, також були відрендерені. Хоча потенційний рівень ризику такого багу від нульового до низького,- залежно від оцінки ризиків компанії, я скинув швидкий репорт, і помилку було прийнято з низьким рівнем ризику (з бонусом за відношення до подарункової картки), та усунено за 6 місяців.

Ризик тут незначний: він полягає у використанні значного рівня автентичності електронної пошти та редагування емейл листа для надсилання фішингових повідомлень з електронної пошти компанії для досягнення таких результатів як викрадення пари логіна і пароля, поширення шкідливого ПЗ тощо. Варто пам’ятати, що складність атаки може бути високою через необхідність купувати окрему подарункову картку для відправки кожного нового електронного листа, тому атака має бути високотаргетованою.

Баг #3: Race condition під час активації промокоду дозволяє отримувати товари безкоштовно на необмежену кількість замовлень

Тут ми розглянемо атаку з використанням промокоду, що доволі схоже до аналогічних дій з подарунковими картками- вони теж засновані на коді, часто унікальні та переважно одноразові. Аплікацією в скопі баг баунті програми є додаток для продажу пристосувань для гоління на основі передплати, де також був любʼязно наданий промокод на $9, який ми можемо використати для замовлення. Було б марно не скористатися ним, чи не так? Я додав в кошик товар на суму 9$, в кожен кошик додав наш одноразовий промокод на $9 в одному обліковому записі, потім створив дві завершальні сторінки оплати для цього кошика, перехопив два останні запити на покупку, додав їх у Turbo Intruder за допомогою свого класичного скрипта, розпочав атаку та виявив, що два замовлення були прийняті з використанням одного й того ж промокоду! Це означає, що одному з них було призначено недійсний промо-код, який був абсолютно безкоштовним. Тобто ми можемо створити декілька замовлень за допомогою одного коду залежно від реалізації та якості мережі.

Коли я надіслав звіт, команда зазначила, що процес оформлення замовлення залежить від стороннього постачальника послуг підписки та оплати, якому вони передали мій звіт. Постачальник має тисячі клієнтів, що означає, що проблема існувала в багатьох програмах, а можливість виявлення є масштабованою. Помилка була прийнята з високим рівнем ризику та виправлена ​​протягом 8 днів.

Баг #4: Те ж саме, але інше

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

Баги #5 і #6: IDOR в API ендпоінтах перегляду та редагування подарункових карток

Додаток являє собою платформу торгівлі одягом, яка підтримує подарункові картки. Я не міг підтвердити race condition вразливість, але після придбання подарункової картки ми можемо переглядати та редагувати її за допомогою додаткових API ендпоінтів. Ендпоінти перегляду та редагування виглядали як GET /gifts/in_progress?g_id=680297 і POST /gifts/buy/email/edit\nHost:www.example.com\n\ngift_purchase_form_id=680297 і після тривіального зменшення ідентифікатора було підтверджено IDOR. Щоб уникнути дублювання, я використав надійний підхід «дочекатися виправлення та повідомити пізніше», і команда надала підтвердження, що обидва ендпоінта належали до унікальних окремих репортів. Репорти були пропрацьовані протягом місяця після звіту.

Результатом стало розкриття 680 000 електронних адрес, повідомлень, імен і цін на подарункові картки. Номери подарункових карток не були представлені у відповіді до API ендоінтів й надсилалися електронною поштою окремо; отже, ризик для обох проблем був оцінений як високий з урахуванням зливу PII.

Баг #7: Race condition під час використання коду подарункової картки та переказу грошей розробнику призводить до фінансових втрат для компанії

Представлена аплікуха— це ігрова платформа для дорослих, яка підтримує подарункові картки, що продаються лише сторонніми посередниками. Я придбав подарункову картку на суму 500 золотих одиниць ігрової валюти, зареєстрував два облікові записи, перехопив запит на активацію подарункової картки в /redeem-gold для обох облікових записів, розпочав атаку Turbo Intruder і… це не спрацювало. Як я виявив пізніше, ендпоінт для активації подарункової картки, який я використовував, не є фінальним і він фактично не активує код. Тому я пропустив запит на завершення погашення коду, оскільки Burp Suite не перехопив його, бо запит потрапив під радар out of scope конфігурації.

Я зробив ще один запуск із щойно придбаною подарунковою карткою, яку було успішно поповнено лише для одного облікового запису. Коли я перевірив затримку, вона була досить значною, і, враховуючи характер race condition багів, варто було спробувати ще раз. Підозрюючи, що на затримку впливає якість інтернет-з’єднання в моїй орендованій квартирі, я орендував добу в коворкінгу з кращим зʼєднанням. Після ще одного запуску я зміг відтворити вразливість і успішно поповнив два різні рахунки на суму 1000 золотих за ціною 500 золотих.

Модель атаки така:

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

Багу було оцінено як критичну та незабаром виправлено.

Баги #8 і #9: HTML injection в емейл листі подарункової картки

Я придбав подарункові картки для двох різних онлайн-магазинів. Під час стандартної перевірки race condition не підтвердилась, але HTML injection в листах на електронку все ж були. Хоча це не було тим, на що я очікував, це все ще баги, тому я повідомив про них, щоб вийти з ситуації хоч і не переможцем, але без збитків.

Думки та висновки

• Переконайтеся, що ви ввімкнули out-of-scope логування та всі MIME типи у своєму проксі-інструменті, щоб перехопити запит на завершення покупки або погашення карток. Я витратив чимало подарункових карток, щоб вивчити цей урок! Не так вже й боляче, коли втрачаєш подарункову картку на $5, але це все ще доволі неприємний досвід, коли вона коштує $50.

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

• Race condition баги значною мірою залежать від якості мережі, і для відтворення може знадобитися кілька спроб. Рівень успіху з VPN нижчий через затримку та ретрансляцію запитів — це причина, чому я намагаюся уникати відтворення race condition багів в staging середовищах, захищених VPN.

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