Сказ о том, как я разочаровался в этичном хакинге⁠⁠

Привет, Пикабу! Зовут меня Выйтиизайти, можно просто Валентин. Это мой первый пост, и я пришел рассказывать вам невыдуманные истории о которых невозможно молчать. А посему - дисклеймер: все персонажи и события вымышлены, любое совпадение не более чем случайность.

Экспозиция

Некая крупная компания Гроктер&Пэмбл, в лице одного из отделов, задумала автоматизировать какой-то свой бизнес-процесс (само собой чтобы сократить издержки и уволить парочку-другую зевак). Поскольку компания большая и динамично развивающаяся, свободных рук исполнить такое кощунство у них нет, поэтому они приходят на галеру.

Галера, дорогой читатель, это когда компания занимается перепродажей кадров (гребцов) из одних рук в другие, чаще всего на проектной основе. В мире крупной рыбы это EPAM, Luxoft и им подобные.

Итак, новости уже на борту: впереди ждет работа. Но сколько времени она займет? Какую сумму потребовать? А выполним ли вообще этот проект? По команде выдвигается вся пищевая цепочка менеджеров, в самом хвосте которых болтаются разработчики самого разного калибра.

Завязка

Ладно, шутки в сторону, к ним мы еще вернемся. Ко мне обратился менеджер с просьбой оценить трудозатраты и реализуемость. В проекте автоматизации задействован сторонний сервис Ledge от другой крупной компании - Essential, откуда требуется выкачать .csv файлик, содержащий **данные удалены** для дальнейшей обработки и загрузки в БД. Клиент не выдал никаких доступов или инструкций для авторизации - просто прислал ссылку на скачивание из сервиса Ledge, примерно вот такую:

dataapi .ledge. com/clients/4aari/catalogs/download?escape_leading_zeroes=1&add_bom=1&X-API-KEY=eb96tvou4

Я думаю что некоторые уже догадались к чему все идет. Да-да, в ссылке был зашит API ключ.

dataapi .ledge. com/clients/4aari/catalogs/download?escape_leading_zeroes=1&add_bom=1&X-API-KEY=eb96tvou4

Дальше идет машинный перевод куска моего отчета о том, почему пихать API ключ в ссылку не есть хорошо:

Раскрытие URL: URL, включая параметры запроса, могут регистрироваться в различных местах, таких как история браузера, журналы сервера и заголовки реферера. Если ключ API включен в URL, он может быть раскрыт неавторизованным лицам, имеющим доступ к этим журналам или перехватывающим URL во время передачи.

Кэширование и ссылки: Ключ API может быть непреднамеренно сохранен или передан не по назначению, если URL-адрес кэшируется или ссылается в различных местах (например, в закладках браузера или результатах поисковых систем).

Видимость: Поскольку URL-адреса видны в адресной строке веб-браузеров, ключ API более подвержен перехвату через скриншоты или записи.

Злоупотребление: Если ключ API включен в URL, пользователи или сторонние скрипты на странице могут непреднамеренно утечь или раскрыть URL, сделав ключ API доступным для сторонних лиц.

Более того, это была не ссылка на скачивание файла, а вполне себе рабочий эндопоинт API, потому во мне взыграло любопытство и после рабочего дня я решил чуть-чуть поковыряться. Автор, кстати, ни разу не хакер, и не пентестер - просьба попридержать фейспалмы.

Развитие действия

Итак, что же я сделал: сначала я исключил ключ из ссылки, на что получил закономерный {"error": "Missing Key Permission."}, и то же самое когда попробовал вписать вместо ключа рандомную тарабарщину. Подменил эндпоинт "download" в ссылке на условный "test" - получил вполне логичное 404 и {"error": "Not found."} от сервера.

С этими знаниями можно заключить, что существующий эндпоинт в API сервиса Ledge всегда вернет "Missing Key Permission". Ах да, защиты от дудоса в процессе я никакой не увидел -- ищем остальные эндпоинты!

Смотрим структуру ссылки:

/clients/4aari/catalogs/download

Есть /clients/ + <client ID> + /...

И вот тут надо было бы рассказать, как я набросал скрипт через ChatGPT, который забрутфорсил остальные эндпоинты перебором самых популярных вариантов... Но нет. Мне было лень, поэтому я просто повбивал рандомные словечки из своего опыта (users, files, info и тд). И оно сработало!

dataapi .ledge .com/clients/4aari/users?X-API-KEY=eb96tvou4

Понятненько, подумал я: API ключик работает на все публичные методы данного клиента Ledge в лице компании Гроктер&Пэмбл. Это конечно не очень хорошо, но кто знает, может быть это какой-то особый случай.

И вот тут мне в голову пришла одна мысль: а что если, ну, чисто теоретически, компания Ledge по всем правилам инклюзивности наняла человека, который ошибся и теперь сервер не проверяет принадлежность API ключа должным образом?

API ключ ведь не будет работать на все публичные методы сервиса Ledge? Не будет же?

Далее опять примитивный брутфорс:

dataapi .ledge .com/clients?X-API-KEY=eb96tvou4

dataapi .ledge .com/info?X-API-KEY=eb96tvou4

И вот у меня на руках уже полный список всех клиентов сервиса Ledge, с их системными UUID, информацией о подписке и **данные удалены**. В списке этих же клиентов нашелся наш Гроктер&Пэмбл.

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

Итого: у нас есть ссылка, которая берется непонятно откуда. Может быть ее генерирует сотрудник Ledge по запросу Гроктер&Пэмбл, а может быть она генерируется самой системой по запросу на скачивание. Так или иначе, это ссылка ОЧЕНЬ ЯВНО И ЖИРНО говорит о наличии в ней API ключа, который, как оказалось, дает публичный доступ вообще ко всем методам API.

Компании в этой истории (включая клиентов Ledge которых я нашел в том списке) настолько большие, что уже вышли на мировые рынки со своими акциями. Как понимаете, эта ссылка явно проделала до меня большой путь из рук в руки. И вот она у меня, информация - тоже. В воздухе висит вопрос:

Кульминация

Первым делом я решил обратиться напрямую к сервису Ledge. Этичный хакинг же, responsible disclosure, да? Они пофиксят, все будут счастливы и здоровы. Нашел их сайт, написал им письмо где обрисовал всю ситуацию, дал свои контакты для связи, и чтобы не сойти за пустослова - прикрепил файлик со всеми их клиентами.

Прошел день, два. Молчание.

Ладно думаю, хрен с вами. Кто там ваш папочка, компания Essential? Окей, сайт, почтовые адреса, повторяем письмо.

День, два. Молчание.

Сделал последний заход на сайт через google, пробил залитые pdf документики и нашел какую-то презентацию для внутреннего пользования с почтой cybersecurity team компании Essential. Продублировал туда.

Нет ответа! От компании, у которой десятки офисов, куча продуктов, нет ответа! Даже отбойник не пришел за все отправленные письма, твою же налево!

Вот тут у меня уже знатно припекло, поэтому о найденной уязвимости я оповестил менеджера, взял типовой бланк отчета своей галеры и во всех подробностсях изложил все детали произошедшего, прикрепив ответы сервера. На тот момент прошло уже две недели, я уже дописывал свой отчет когда команда cybersecurity ответила с просьбой уточнить данные. Я сразу же отправил им стандартное предложение назначить звонок, чтобы все обсудить.

Ответа на это предложение не последовало.

Поскольку шестеренки уже закрутились, я передал отчет о найденной уязвимости менеджеру, чтобы он сообщил напрямую компании Гроктер&Пэмбл. Дело сделано, отчет отправлен. Я смотрю на копию письма которую отправил менеджер, открываю файл своего отчета и вижу:

Галера придерживается принципа ответственного раскрытия информации и готова помочь команде Essential обеспечить безопасность вашего программного обеспечения. Поэтому я прошу подтвердить получение данного отчета.

Спасибо за внимание к этому вопросу, ждем ответа.

А знаете что там было?

Я придерживаюсь принципа ответственного раскрытия информации и готов помочь команде Essential обеспечить безопасность вашего программного обеспечения. Поэтому я прошу подтвердить получение данного отчета.

Спасибо за внимание к этому вопросу, и я с нетерпением жду вашего ответа.

Искренне,

Валентин Выйтиизайти (корпоративный адрес почты)

Ладно, думаю, хрен с тобой. Галера в курсе, Гроктер&Пэмбл в курсе, глядишь работодатель хотя бы похвалит за бдительность попозже.

Развязка

Спустя 3 дня я заметил подозрительную активность в своем ящике: ого, да это же команда cybersecurity компании Essential очень хочет со мной звонок! Похоже их клиент Гроктер&Пэмбл не обрадовался найденной дыре. Штош, звонок так звонок, назначили.

На звонок пожаловал сам chief technology officer сервиса Ledge в компании двух сотрудников сиберсесюрити и рассказал, что "чувак, да мы видели твои письма, просто эээ не могли ответить две недели потому что есть процедура, мы пробивали тебя понял да?? Никак не связано вообще с тем что позвонили когда нам клиент пиздюлей дал"

По итогу звонка договорились что в адрес нашей компании в лице меня и менеджера от них прилетит письмо: дыру подтверждаем, дыру починили, даем зеленый свет. Прошел день. Два. Ну вы поняли, пришлось им снова написать и напомнить. Спустя неделю все-таки ответили.

Ладно, иду к менеджеру. Вот письмо, отчет ты мой видел, подтверждение есть что не туфта, уязвимость закрыли. Можно благодарочку от клиента или компании для резюме?

Конечно можно, дорогой друг, сейчас напишем письмо нашему Security шефу, он все сделает в лучшем виде. И... Проходит неделя. Проходит две. Прошел месяц. В течении всего времени я пинал менеджера, а он пинал кого-то повыше. В итоге прислали письмо с благодарностью, где перепутали все: и проект, и что конкретно было сделано и кем.

Ни на одном этапе крупные компании (в лице моей галеры, клиента Гроктер&Пэмбл и сервиса Ledge в лице Essential) даже и не заикались сами про какую-то благодарность или про bug bounty. Я думаю что секрет прост: никто и никогда не захочет признать свой проеб. Мне в каком-то смысле стоит радоваться что я репортил это от лица галеры, потому что в некоторых случаях подобные истории заканчиваются судебными преследованиями.

Вывод? Делайте его сами :)