Всем привет. Извините за задержку.
Меня зовут Кирилл Калегаев, со мной Роман Новых.
Сегодня мы расскажем о результатах хейтинг-команды.
Мы по соглашению с организаторами не называем,
к какой компании мы относимся.
Хейтинг-команда, которая занимается тестированием
внешнего периметра непрерывном,
проведем анализ результатов,
которые мы собрали,
немного посмотрим на статистику, интересные кейсы
и какие выводы
из этого всего можно сделать.
Тут небольшой план.
Расскажем, о чем вообще
доклад, какая была каталогия,
какие там ограничения,
типу изимести, типу КО,
как мы классифицировали.
Расскажем интересные кейсы,
от реализимости к инвестивному событию, ну и какие выводы из этого всего можно сделать.
Да, о чем вы вообще? У нас накопился довольно большой, на наш взгляд, опыт проведения тестирования на предотвращение внешнего периметра,
это более 50 проектов. У нас накопилось командной командой довольно большое количество опубликованных 0-0 реализимости,
более 150 опубликованных для раздельности на текущий момент.
И, соответственно, нам показалось, что этого объема данных может быть достаточно,
чтобы провести какой-то анализ, вывести какие-то интересные инспекционно-мерности.
Мы сфокусировались не на известной ЦВЕ, АПДУ и так далее,
нас интересовали именно новые уязвимости, которые не встречались ранее,
которые мы находим на проектах, либо которые мы находим в рамках 0D research.
Также нам хотелось рассмотреть не просто эти уязвимости, а составить какую-то модель.
В сумме у нас получилось 250 плюс записи, то есть суммировая 0D и проектные находки и так далее.
В каждой записи мы категорировали, то есть есть категория по WAST-POP10, есть vulnerability type, это CVE, по сути как CVE, тип, только человек читаемый, то есть не номер просто, а ну и скеллигентц, например.
Нам хотелось рассмотреть потенциальный импакт, то есть сразу посмотреть, ну например, что там вот CSS и потенциальный импакт это account recover.
Также нам хотелось, мы посмотрели какой у нас был подтвержденный импакт, то есть для чего у нас получилось закрутить данную изюимость,
какой тип ПО используется, где была найдена изюимость и по потенциальному либо подтвержденному импакту, какие есть рекомендуемые исправления.
Как можно предотвратить данную уязвимость?
Логика такая.
Важно сказать еще раз про методологию отличения.
Dataset — это наш набор уязвимостей, которые не встречались раньше.
Проектный плюс 0D.
Нет никаких CVE, BDU, местонфигураций, которые находятся с фонарами.
То есть у нас фокус здесь не на vulnerability management, а именно на новостях поезвимости, о которых встречаются в бизнес-логике и так далее.
По типам поезвимости, как сказал, мы классифицируем по WAST 2025 и CVE Like.
Типы PO – это тоже, собственно, классификация.
Испакт и контролл — это словарь, человекочитаемый, чтобы по тегам можно было понять вообще, какой здесь импакт и какие контролл закрывают эти уязвимости.
Тут же важно сказать про ограничения. Это не универсальная статистика всех уязвимостей.
То есть это только наш опыт, соответственно, мы не можем сказать, что его можно взять и опоксимировать, допустим, на весь внешний периметр Рунеты или еще где-то.
То есть это только наш командный опыт.
И это только внешний периметр.
Соответственно, тут стоит сразу сказать, что недопустимые события, мы их понимаем как что-то крайне критичное, что можно реализовать из позиции внешнего злоумышленника.
То есть здесь не будет взять замены и так далее.
То есть для нас недопустимое событие – это что-то очень критичное,
что можно реализовать из позиции внешнего нарушения.
Ну там, RCE и так далее.
То есть никаких дальнейших закруток здесь не будет.
Так, да, все любят слайды, которые едут по цветам.
Все любят слайды, которые с большими красивыми цифрами.
У нас такой тоже есть.
Мы же не зря классифицировали.
По нашим результатам у нас broken access control – это почти половина всех уединенных уязвимостей.
Если посмотреть на два остальных категории – это authentication, failures и injection,
то в сумме все эти три типа уязвимости будут составлять более 90% всего, что мы находим.
Это просто интересные цифры.
Далее чуть более подробная статистика по типам уязвимостей и по типам пола, на которых они были найдены.
Здесь, если по типам уязвимости посмотреть, то уже более равномерное распределение.
Всем известные XSS, KIDOR, DISPLOSUR, YouTube NAM и так далее.
С такой классификацией, во-первых, человекочитаемый, во-вторых, более равномерно получается,
потому что все в одну кучу broken access control, например, не сложено.
И по типам ПО у нас более 50% можно увидеть, что это либо какие-то бизнесовые вебчики, либо CMS.
На самом деле довольно логично, учитывая, что мы фокусируемся не на CVE и не на известных каких-то уязвимости,
а на новых уязвимости, они существуют где-нибудь в бизнес-логике.
Да, не будем сильно тянуть со статистикой всем остальным, мы потом к ней еще вернемся, перейдем к наиболее интересным кейсам, которые приводили к негативным событиям.
Это все, что там вполне.
Помоги?
Небольшой степеньер.
Мы были сосредоточены больше на
инфакте, а не на технической части самоизвимости.
То есть мы стараемся здесь рассмотреть не то, что существует
в QE-рекции какой-то интересный для нее bypass,
а то, что существует в QE-рекции и что, в принципе, с ней можно сделать.
Первая история — это один из сообщений,
Грубо говоря, user-in-up плюс сабый парольный политико, что в себе это вообще подразумевает.
То есть вообще user-in-up как таковой, некоторые компании даже и вендоры не считают за какую-либо уязвимость.
То есть не подумаешь, что можно получить ими пользователя, который существует в системе, как бы ни 4 реакции, ни 6-е-шка, ничего такого не утекает.
Но опять же, в совокупности с сабый парольный политико эта история вообще может стать критичной.
Мы вообще постоянно с этим сталкиваемся. В осложках, в качественных шлюзах, в всевозможных подкладных интеграциях, самописном таком поле и так далее.
То есть юзеринам может оказаться вообще везде.
Последствия наглядные. То есть приложение, где не используется интеграция с доменом, 99% в случае,
В итоге мы собираем набу по пользователям и просто начинаем брутить топ-100, 1000, 10 тысяч и как-то, насколько у нас хватает ресурсов.
Интересно здесь то, что этот баг часто не живет один, а в принципе, ну, идут облегчающие баги.
Это отсутствие RAID-лимитов, отсутствие блокировок учетных записей и отсутствие блокировки атакующего, например, по IP.
Ну, собственно, да, то есть в этом кейсе мы показываем, то есть мы перебрали, собрали мапу и в реальный пароль мы попали в супер критический актив, который не особо можно показывать.
в следующем кейсе он уже более интересным, более интересной истории
был выполнен DINAM в Exchange
собраны учетки, по ним был выполнен Spray и одна из учетов постоянного
после этого был получен доступ в Google Playpack
и там уже найдены интересные истории про доступ к машинам обновениям, доступ к работам.
Очень дешевая атака получилась, просто подождали, просто посмотрели на консольку, все, получили, пробив внешне.
Следующий кейс он не в Enterprise в каком-то приложении, но тоже очень интересен тем, что это интеграция с LDAQ.
LDAQ был достаточно разговорчивым и по остаткам мы могли достаточно точно финтровать вообще успешно была аутентификация или нет.
То есть передание фактически была только форма входа и все. Что из этого мы получили?
получили могла сетич существующих доменных учетных записей и примерно 100 удалось подобрать
пароль а так получил супер дешевый супер тривиальный но в этом всем здесь достаточно пятичных
Собственно, реализованные места этих кейсов — это правильный финишник инфиритера, доступ к политических сегментах контроля, управление администрированием и тому подобное.
То есть вообще не будем рассказывать, а с вопросом нет. Следующий факт — это сбор актиноменов ОЗ и материал по вотфишнекотеке.
Инам это еще старые добрые фиши, с которыми можно очень активно работать.
В том числе как раз на больших объемах данных.
Соло перенадки, ребята.
Спасибо. Следующая выявимость, типа неудивенность и история, про которую мы расскажем, это Айдоры, которые всем довольно знакомы.
На слайде представлен самая стандартная история, когда, во-первых, идентификатор какой-то объекта перебираемый, то есть это просто числовой номер.
И как меме это можно просто делать и смотреть на чужие идентификаторы.
Либо такой же еще один пример, всем уже давно знакомый.
Мы тут, естественно, не будем рассказывать про такие IDOR, и интерес этой истории не в этом.
В том, что когда мы обычно про такие IDOR рассказываем, даем рекомендации,
мы говорим, что нужно сделать две вещи.
Первая — это уйти от перебираемых редфикаторов, использовать WID,
чтобы их нельзя было просто с одним минус одним делать.
И второе, это естественно реализовать разрешение контроля доступа.
То есть, что объект, субъект, который не имеет права доступа на какой-то объект,
не должен, если у него этого права нет, он его должен получать даже по прямой ссылке.
Мы часто сталкиваемся с таким мнением, видимо, потому что реализовать просто уиды, чтобы они были неперебираемыми легко
А вот реализовать полноценную ролёвку, чтобы нельзя было проверку на уровне нового объекта, иметь субъект доступ и так далее
Чуть послоднее, видимо, поэтому нам часто говорят, а вот давайте мы просто уиды реализуем
когда мы общаемся, пытаемся, чтобы эти выживости закрыли, давайте мы просто уиды реализуем, соответственно, перебрать вы никак не сможете, на этом будет строиться все безопасно.
Вот, собственно, следующий кейс, как раз про то, что на одном только знании уидов, их секретности безопасно строить нельзя.
Тут приложение мы должны стали скринить, чтобы не рассказывать, что это за приложение.
В чем здесь история?
В самом приложении обрабатывались крайне критичные и чувствительные информации.
Аутентификация была через ESEA, то есть это просто OAUS, по сути.
То есть аутентификация была делегирована.
И там в целом все выглядело неплохо в самом приложении.
Немного фотографировавшись, посмотрев, обнаружили интересный JavaScript endpoint,
на котором увидели ряд интересных, во-первых, ключик, которые...
На слайде внизу видно, что говорят нам о какой-то регистрации,
видимо есть какая-то внутренняя регистрация.
И также увидели некие роли, которые тоже выглядят как GUID и так далее.
Вот тыкнулись в ручку, которая позволяла, кажется, регистрировать пользователя,
причем это явно была не та ручка, которая стандартная через eSea.
Видно, что GED не поддерживается, поддерживается пост.
Соответственно, в процессе изучения этого API было замечено, что…
Чтобы вообще… Это, видимо, было API какой-то встраиваемой системы, то есть чего-то стороннего.
Там было замечено, что чтобы амфицироваться и чтобы прилетел валидный токен, сессия,
нужно передать определенные идентификаторы, там ECR ID и WIC Profiles.
То есть тоже то, что на самом деле не перебираемо, особо не раскрывалось и так далее.
Но тем не менее здесь была найдена уязвимость, что на самом деле эта ручка возвращала валидный токен
даже без передачи этих идентификаторов.
То есть токен возвращался, не передавая эти идентификаторы.
Единственная разница у этого токена была в том, что он не был привязан за конкретную сущность.
Видимо, привязка за субъект была как раз по идентификаторам.
Но, тем не менее, этот токен был валидный, и с ним можно было отходить.
И далее мы еще поговорялись и раскрыли схему ролей.
То есть какой гуид, за какую роль отвечаем.
Ну, соответственно, тут можно увидеть, что уже в этом есть крайне критичная уязвимость.
Есть предыдущая уязвимость, где нет, по сути, никакой проверки.
То есть просто нам нужно только предоставить какую-то роль,
и нам дается, соответственно, валидный токен.
Дальше мы с этой ролью можем ходить.
И мы только что раскрыли все роли, которые есть в этой системе.
Соответственно, в дальнейшем эксплуатация была связана с логикой.
То есть мы смогли повыситься до роли работника этой системы.
И далее мы могли раскрывать крайне критичную информацию.
Соответственно, информацию обо всех пользователях, которые к этому работнику прикреплены.
крайне критичную информацию про их файлы и также информацию про…
В конечном итоге можно было раскрыть даже линк на видеоконференцию, в которой можно было подключиться.
Хотя здесь все было реализовано на уидах, и чтобы получить доступ к такому-то файлу,
не нужна была даже роль, тут вообще никакого токена нету.
То есть можно увидеть на слайде ниже, что получение файла,
вся защита строилась просто на знании, секрете, идентификатор, который сложно перебираем,
Но здесь случилась уязвимость по модификации и были получены крайне фитичные информации.
На одно реализованное событие – это массовое раскрытие персональной данной, чувствительной информации.
Тут раскрывалась как информация о работниках, так и о посетителе, пользователях платформы.
Возможно, включаться в видеоконференции.
И также, как я сказал, все дальше было связано с бизнес-логикой,
была возможность влиять на расписание работников этой системы.
Быстрый вывод, что на основе других уидов строить безопасность, конечно же, нельзя.
Слово о том, слово передам нельзя.
Небольшой спойлер, а почему будет плохо. Вообще очень часто 1С — это фактически нервная система бизнеса.
То есть это документы, бухгалтери, кадры, документы и все такое.
1С исторически вообще развивалось как что-то внутреннее, почему никто не должен иметь доступа.
доступа, но в силу того, что стали обрастать, что кто хочет иметь доступ к 1С, это бухгалтерия,
также администраторы, удаленные какие-то сотрудники и тому подобное. 1С стала обрастать не совсем
безопасными практиками, это, например, какие-то обработки, это обработки специфичные, это публикация
11 как вы приложение в большой интернет, доступный, в общем-то, извне.
Вот. И, в общем-то, сейчас расскажу, что из этого бывает.
Первый кейс, уже, наверное, народный метод, фаундификация реализована через СОШКУ, базируют на ID.
Вот. Вроде бы все хорошо, но архитектурная СОШКУ является либо отдельной базой данных,
либо общий баз данных, на который ты входишь.
Нам удалось с помощью небольшого лауза спуститься до классической аутентификации 1С,
то есть немножко архитектурная такая бага, которая позволяла нам уже получить список пользователей этой базы,
получается, сочный, и попробовать уже поддеваться внутрь.
Мы отцвотились вообще на RCA. Нам не повезло, не было ни слабых паролей, ни пустых паролей.
Но мы не сдавались, значит нам лутнулось, начали накрутить, начали пазить пути на том же домене.
Оказалось так, что была найдена дополнительная база.
Она имела также такую же дополненную авторизацию в Dynastity.
Там также был список пользователей. И тут нам уже как раз повезло.
Мы получили список пользователей и получили пользователя с пустим паролем и с административной валютой.
Тем самым далее мы выполнили EPU и RCE, и получили RCE шкур пластыри.
По классическим пунктам.
Второй кейс, он больше рассказывает не про чиповые какие-то истории,
что просто опубликовали базу, забыли прикрыться,
он рассказывает больше о как раз архитектурных сложностях в NESCM.
На встрече с порталом. Портал из себя представлял тоже подобие SSO, но там была небольшая такая особенность.
То есть в процессе аутентификации первичной пользователь автоматически инициировался подсистемным пользователем 1С.
А после этого уже внутри, на базе 1С выполнялась регистрация и та же аутентификация, но уже внутренние методы.
Это нас привлекло. Мы заметили в логах утечку от системного пользователя.
Провернули ту же историю с даунгрейдом до прямого пути к базе данных.
Мы пытались перебрать пароль к этому пользователю. Не увенчалось успехом.
И после 10 попыток мы столкнулись с тем, что учетная запись была заблокирована.
Собственно, почему это было?
Из-за того, что системные учетные записи используются в процессе аутентификации, в процессе редириктов до аутентификации.
Таким образом, заблокировав учетную запись, мы заблокировали полностью национал администрации и аутентификации для пользователей порталов.
После мы начали проверять дальше, начали смотреть, так как у нас был путь прямой до аутентификации, до базы.
Вот, национально мы были на именно пользователя 1С.
Вот, начали отходить легитимную регистрацию.
Внутри получается решение самого портала.
Вот, все делали легитимно, красиво.
Нам пришли входить на почек, все хорошо.
Проблема заключалась в том, что для того, чтобы попасть внутрь портала
и дотянуться до какого-то функционала,
нам нужно было получить аппроф от админара.
А аппроф этот, ну, как я понял, просто так ты не получаешь.
связываться немножко короче в бюрократии вот это все замечено что все таки мы какую-то хотя бы часть
часть на статиста что мы практически то акулы же им пользоваться через штатный механизм один
В Web1DNS по прямому пехватику, по прямому окно операции нам удалось сбросить пароль.
Через тот же штатный функционал забыли пароль. Мы восстановились.
Все, после этого мы попали уже в портал и начали изучать функциональный стан.
Попрыли кнопочки, всякие интересности.
И было замечено, что в штатном методе перепоходить открытие формы.
То есть в Web1DNS работает достаточно специфично.
То есть мы когда запрашиваем какую-то форму, когда хотим что-то открыть, мы сначала запрашиваем список доступных, можно их назвать патологами, если точнее, патолог HTF.
То есть, грубо говоря, ссылка, куда мы должны сходить, что нам должно открыться, что нам должно вернуть беп и что должно отрасывать на хром.
вот этот как раз возникли странности у нас раскрылась распространясь полпе
там начали перебирать смотреть почему вообще можно дотянуться с
смотри мы дотянуться по списка пользователей то есть инициировалась как вообще работала то есть
при попытке открыть любую легитимную форму помирался запрос кей мы с очень-очень
дополнительных метров. И как раз параметры OK мы сманипулировали, подставили из полкрефа,
грубо говоря, остаточное описание и получили форму, отрисовку нелегитимной формы в легитимном функционале.
Вообще, начали смотреть, что еще происходит, что мы еще можем сделать, так как мы можем
манипулировать, мы можем дотягиваться до списка файлов, можем дотягиваться до персональных данных,
сотрудников,
контрагентов и так далее.
Но что еще
в общем можем получить про мечтение?
Ну, это вот как раз сайт
о том, что контакт-поставщиков утекает,
правила утекают.
Что мы можем получить?
Здесь, конечно, на сайте не будет,
но через манипуляцию
как раз, вы помните, что у нас веб,
через манипуляцию от сервера
удалось немножко
JS попробовать, и удалось
позначировать кнопки.
И, на удивление,
кнопки формировали
легитимные события, и так как
с низкоперегированными пользователями
мы имеем ограничения, только, грубо говоря,
по кнопкам интерфейса,
но внутри, наоборот, мы не имеем никаких ограничений,
и формируем легитимное какое-то событие.
Нам удалось провести
нам удалось провести
а то
с низкоперегированными пользователями, и таким образом мы получили
администратора портала.
То есть фактически ничего не ломает,
просто немножко, посмотрев кур, посмотрев логи,
имеем, собственно,
доступ уже
к более обширной информации,
ну, также по персональным данным,
также коммерческой тайне,
вот, и ведет это
к тому, что, ну, массово
раскрыто персональных данных,
вид чувствительной информации,
ну, выполнение произведенных глоб
из первого кейса, и вот что немало важное,
демонстрации возможностей финансовых и репутационных рисков.
То есть, имея у себя на порту 1С, выставляя ее в интернет,
есть шанс того, что что-то пойдет не так,
а так также остается все еще дешевый,
есть риск того, что потери эти будут.
Мы показали на большом объеме данных,
но это касается также и малого и среднего бизнеса.
с 11, ну, да, кто выставляет интернет. Передаю слово.
Да, спасибо.
Следующая история, пару кейсов, связана с платформой мониторинга.
Эти платформы сами по себе очень склонны, по своей природе склонны по единственным типом SSR.
потому что платформа для мониторинга это обычно подключить какие-то data source и как-то их графически отобразить.
Этот кейс первый не про SSR.
Здесь мы столкнулись с платформой мониторинга, в которой был не авторизованный доступ ко всем dashboard-дам и data source.
Соответственно, неавторизованный доступ на мониторинге на платформе означает, что в эти data source можно ходить.
Что такое обычно data source? Это обычно какие-то базы данных и что-то похожее. Откуда данные тянуть, чтобы их потом графически отображать.
Соответственно, один из датасорсов оказался базой MySQL.
Причем помимо просто просмотра датам этого датасорса, а то, что уже настроено в самой системе мониторинга,
так как у нас получается не авторизованный доступ, мы, соответственно, можем как-то по-своему настраивать отображаемые данные.
Что такое настройка отображаемых данных, когда у вас датасорс это MySQL, это по сути запрос в эту базу данных.
То есть запрос в MySQL.
Соответственно, здесь именно так и было.
То есть просто не авторизовано можно было делать прям запросы в базу данных.
Например, вывести юзера, либо посмотреть пароли, имена и так далее.
Ну и здесь на слайде уже видно, что это, к тому же, была не просто какая-то там случайная база данных, это еще и была база данных Asterisk, то есть это система IP-телефонии.
Соответственно, можно было делать запросы в эту базу данных, в которой как бы хранится информация, связанная с IP-телефонией.
Ну и собственно здесь риск, который был реализован довольно быстро, да, так как это база MySQL, мы там и файлики подгрузили, и файлики читать смогли.
Но самое основное, что в итоге было реализовано, недопустимое событие, это то, что в этой базе данных, собственно, хранятся разговоры,
то есть записи разговоров, которые были по IP-телефонии,
по виду файлов можно видеть, что они есть внешние, есть внутренние.
И здесь весь риск был в том, что мы такие файлы смогли прочитать.
То есть получили доступ к крайне критичной внутренней информации про записи разговоров.
И следующий кейс, если честно, поместился весь на один слайд, мы сами довольно удивились.
Собственно, это была тоже мониторинговая платформа, в которой была форма, функциональность создания отчетов,
мы их замазали, что-то PHP, и можно было передавать линк, который предполагался, что это будут локальные файлы,
Это обходилось значком собачки, то есть можно было сделать SSRF.
У нас было крайне большое удивление, когда мы сделали такой запрос на наш интерактиссар сервер,
и запрос со стороны уязвимого сервера прилетел вместе с заголовком authorization,
в котором в бейсике были учетные данные.
Мы подумали, что это что-то очень странное.
Тем не менее, на внешнем периметре было много различных порталов,
куда можно было попробовать эти учетные данные, и они подошли.
Причем они подошли к SEL-VPN порталу, это оказались еще и доменные учетные данные.
То есть здесь за один запрос открыты оборота в внутренний клинику.
То есть за один запрос мы получили доступ к внутренней сети.
Соответственно, для нас, как мы говорили, мы считаем это недопустимым событием.
Ну, еще стоит сказать, что ЭПССР еще и так, ну, не закручивалось, точнее, тут уже риск серьезный.
Она еще и предоставляла аккаунт takeover. Если эту ссылку нажать пользователю в зарегистрированном системе, запрос прилетал вместе с юзером паролем в get-запросе.
В параметрах get-запроса. Тут еще аккаунт takeover. Причем юзер пароль открытом в битве прилетал.
В общем, тут мы нарвались на что-то очень древнее, что предоставило нам доступ во внутренние периметры.
Ну и, соответственно, здесь реализованы недопустимые события, как я сказал, это получение доступа во внутреннюю сеть и получение несанкционированного доступа к записям телефонных разговоров в системе и телефонные.
Рома, передам сейчас.
Следующий блок вообще о пасеке. Наверное, все знают об инъекциях. Уже везде много раз поговорил, много кто писал. Во всех станираторах уже давно встроено.
То есть здесь, опять же, не столь о каких-то технических историях, столь об импакте.
Первый кейс. В коде был обнаружен параметр, была обнаружена SQL-лекция.
И при изучении ОКДшки был обнаружен тоже, да, у нас есть логин, да, у нас есть пароль,
но он был в современном, в закрешированном современном алгоритме и не подвержен дошифрованию.
назад его не получу немного грустно казалось бы но нет соседи таблицы соседи таблички в колонке
виде пользователя полностью полностью скипает проверку и безопасное хранение пароля также
заходим получаем доступ к вы меняем пароли и в общем делаем что хотели
тройки у нас нужно смещать блок пера про что рассказывал просто вы пароли то
есть у нас есть выбор он закрыт достаточно спичат реализован
пином не просто пином перебрали
попали в обнаде этого приложения, начали изучать. Также в параметре была обнаружена SQL-реакция,
но тут немножко поинтереснее. Тут был пройден путь до эскалации.
То есть внутри был не строгий баг, и это позволило через URL-кодирование, ну, собственно, в IT.
Установили, что Суббд — микрософский сервер, имя пользователя — цензура.
И пользователь также обладает поезд данных правами суперадминистратора и включен доступ в модуль XP.md shell.
Ну, собственно, пару запросов и получили RCE.
Опять же, атака получилась дешевой. Это был 2026 год. Все еще это доступно. Все еще это существует.
Смс также массовое раскрытие персональных данных и чувствительных информации, компрометация всех пользователей порталов по кейс-1 и выполнение произвольных команд на хостях.
Спасибо. Следующий кейс довольно быстрый.
Ну тут тоже опять два кейса, на самом деле.
Это история про CMS и модули в них.
CMS по своей природе – это обычно просто движок, который расширяется
либо различными модулями, либо самописными чем-то, плагинами и так далее.
Ну и, соответственно, это часто приводит к серьезным последствиям,
потому что если в движке еще следят за безопасностью,
то в модулях, особенно в самописных, мы часто встречаемся с тем, что там все совсем плохо.
Ну и здесь на самом деле хрестоматийный пример файлоплода,
то есть у нас просто есть форма, в которой можно прикрепить файл.
Здесь просто прикреплялся файл, соответственно можно было прикрепить HP,
И потом его найти, он в папочке что-то типа TMP-отвод или что-то такое лежал.
Ну и соответственно все. Здесь RCE просто одно очень простое действие,
но если говорить про недопустимые события, исполнение хода, понятно, что мы уже считаем пробивом.
Но здесь все усугублялось тем, что на хосте была обнаружена табличка с персональными данными, которых было более чем 400 тысяч.
На таком легко пробиваемом портале довольно неожиданная была находка.
Еще оказалось, что это не просто хвостинг какой-то, здесь есть связь с внутренним переменком компании.
Здесь, собственно, довольно критичные последствия с довольно простой эксплуатацией.
И следующий кейс с неузнаваемой CMS, ее можно не замазывать, и так никто не узнает.
Да, это Gitrix и здесь модуль, который позволял делать импорт-экспорт-файл.
Тут вся уязвимость из интерфейса прямо на пике в области.
То есть здесь прямо подписано, можно было просто вставить пикфайл, в этом пути можно было написать etc.psvd,
и выпадала ссылка, в которой любезно предоставлялся этот файл.
То есть здесь localfile.read, соответственно, можно было читать произвольные файлы.
Такие два кейса. Здесь просто такой вывод, который мы специфически тоже подтвердим,
что на CMS много всего находится за счет природы,
того, что они очень модульные, модули пишутся разными людьми и так далее.
Про CMS здесь это удаленное выполнение коды и массовое распределение персональных данных.
Передам потом.
Спасибо.
Следующий блок вообще в принципе непроизимости. Он скорее про то, что есть и про то, что не стоит забывать вообще списывать за счетом.
Это богатая документация. Вообще этот блок происходит про недооцененные источники разведки.
Документацию как раз да и технические какие-то артефакты.
во время теста, ну часто так бывает, что не сразу лобби же вломать, вставлять и так далее, а если видимо какой-то возможно коробочный, то стараемся найти документацию, стараемся почитать вообще о чем там, что там, что мы можем сделать, сильно ли стоит нам вообще тратить на эти ресурсы свои силы, вот если это еще в контексте ограниченного какого-то времени, вот, но так привело, что вообще документацию у нас в группе достаточно хорошо описаны, и это классно, это здорово,
это облегчение для администраторов и для пользователей этих платформ но с другой стороны есть
атакующие для которых это документация также очень хорошо для составления какой-то пологи
для выяснения ручек опишек и все подобного на сайте мы можем обратить внимание что что
документацию можно обнаружить то что подминки нас ждет выполнение 3 4 под заметь и поля позволяющий
в чёрную собственную PHP форму.
Ну тут предлагаю, конечно, применить к текстовому шаблону какие-то запросы сделать.
Нас это не интересует, нас интересует, что из этого мы сделаем RCR.
И наша задача будет пробиться туда внутрь и, ну, уж вяжем их на спуск.
При этом всё, отдельные классы в этой документации — это дополненные учётные записи.
А иногда супер высокоприволевированные дополненные учётные записи.
Вот, человеческий фактор, раскачивающийся человеческим фактором,
Иногда это протекает консервная конфигурация, это бывает накатили, забыли убрать, может тестировали, забыли убрать, может вроде поставили, забыли, неважно.
В общем, приводит это к тому, что опять так же, просто погуглив, почитав документацию, посмотрев, что это ZPO, можно одним запросом, грубо говоря, получить достаточно высокий пакт, проникнуть в админку.
просто на основе того, что ты знаешь, что вообще документация есть, что существует на такой поиске.
Ну, роль там достаточно такая привязанная.
При этом всём там поиска документации.
У нас были такие кейсы, что иногда блок не получается найти.
Иногда бывает такое то, что ПО уже не он, и уже сайтики закрыты, как у кого ничего нет.
Веб-архив приходит нам на помощь, пожалуйста, подрядки очень классно хранить.
В этих самых подряд можно найти тоже очень достаточно интересную информацию, которая фактически оказывается правдой.
Ну, порой также. Достаточно реальный.
Достаточно частичный источник тоже вы отнесут глупу. Вообще, это пап-файлы, source maps.
Вот, тоже очень частая история. Часто позже объясню, почему именно документация отнес.
Сорс-мапы очень часто много в себе что раскрывают.
Вот много-много громких кейсов в последнее время, в 26-м году, все там сливают.
Все в этом пишут, паникуют. Все еще есть в 26-м году.
Вообще так используется для отладки, но опять же свои хайкеры пришли, все что-то посмотрели, все что-то поломали.
Вот, в данном случае в мапе от стан-сервера были креда.
Обращайте внимание на то, что тур будет отстана.
Удалось запроксироваться, проверить гипотезу.
Да, до IP мы ходим через проксу и все ок.
Опять же тоже просто посмотрев mapfile.
Pro.ns.
Опять же, уже классический получение доступа к критичным активам, персональным данным, документам.
И тут еще немаловажный момент — это развитие атаки после.
Это поиск 0D-илюзимости, эскалация до каких-то критических находок внутри интеркейсов, которые стали доступны вследствие применения информации из документации.
То есть часто случается так, что первичный самый сложный этап — это пробиться внутрь, а внутри уже всякие интересные находочки.
Передаю микрофон.
По кейсам у нас все, соответственно какие выводы из этого все мы можем сделать и какие ошибки чаще всего дают атакующим реализовать недопустимые события, то на примере кейсов мы, конечно, никого не уделим.
довольно стандартный, что обычно реализация недопустимого события — это комплексная проблема,
которая зачастую троится не в одной конкретной уязвимости, а в комплексе проблем.
Мы в основном выделили на наших примерах слабый контроль за внешним периметром и публикация,
критичный систем, проблемы с учетами данными, которые до сих пор встречаются,
избыточные привилегии,
проблемы с контролем доступа
и избыточное раскрытие информации.
Обычно
реализация недопустимых
событий — это
какой-то комплекс
из этих проблем.
Ну и да, стоит, наверное,
выделить, что проблем access control,
который у нас эстетически оказался
наиболее частым,
также идет
одна эта уязвимость может вести
к реализации
недопустимых событий.
Немного посмотрим
на соотношение
типов ПО
к уязвимостям, которые были на них
найдены, какие там
характерные уязвимости.
У нас там
выделилось два
типа ПО, это CMS,
на них
из-за их природы,
про которую я уже говорил,
Довольно большой набор различных уязвимостей. На нашем опыте наиболее часто это CSRF и iDoor.
И также выделяется тип по мониторинговой платформе. У них явно выделяется тип уязвимости
СССР, про который уже тоже говорил, связано с природой
самого программного обеспечения.
И еще один слайд с большой цифрой.
Да, мы заметили, что на нашем опыте, по крайней мере,
11-напрайз, который выстрелил во внешний периметр, приводит
к ненепустимому событию в 87% случаев.
Но стоит признать и сказать, что крайне редко встречается на внешнем периоде.
Теперь расскажем про какие контролы,
как можно ломать цепочки ненепустимых событий и предотвращать эти уязвимости.
Представим, передам слова.
Вообще, controls и контроль в группе это не какая-то там жестко захардоженная метрика, это вообще наше просто человек понимаемое условность, которую мы хотим принести.
Принести. То есть про кейс, про то, что мы рассказывали, есть в любом случае небольшая такая схожесть прослеживается, что первичный доступ получен каким-то таким достаточно реальным способом.
Где-то внутри паралек, что-то не сошлось, где-то мы еще доступ получили.
То есть основная суть контроля, это еще раз приобрести такое, я думаю, защитник прекрасный экран защищаться, разработчики прекрасный экран, выставить отличный защищенный экран.
Но тем не менее мы все еще находим, все еще у нас есть работа, поэтому хотел бы сказать, то есть первый контроль, и не основные, расскажу про четыре.
Первый это object level authorization, ну то есть он вообще про то, чтобы тестировать систему.
Тестировать систему на то, что низкопривилегированный пользователь не может получать данные, допустим, высокопривилегированного или там соседнего какого-то, ну, горизонтальные, имею в виду, перемещения, тайгуры, паки.
вся вот эта вот классика.
То, что не аутентифицированных
злоумышленных, ну, атакующих
пользователей может получать какие-то
данные там, где он не должен
их получать. То есть я иду к тому,
даже, ну, если
считаете, что ваше положение защищено,
допустим, хорошо защищено
авторизацию,
ну, там, допустим, в вашем случае есть что-то такое,
второй фактор. При этом все,
ну, не стоит списывать счетов, еще тот момент,
что национальные злоумышленные также
Если говорить о короче, то накатите у себя, допустим, демочку или где-то там интернет найти бывает.
Также это все посмотреть, проверить.
Если не сделали вы, я говорю к тому, что это сделает кто-то за вас.
И будет хорошо, если в каком-то хорошем подробке себя окажется.
Второй контроль — это централизованная авторизация.
Вот как раз про то, что происходит, про все такое.
то что в идеале как бы что-то критичное хранить либо засошкой, либо точно заставим фактором,
и не пропускать потенциального злоумышленного к ней.
Ну например, допустим, даже одиннадцать.
Если бы два файла висела, то маловероятно, что получился бы блок,
получилось бы что-то искать про это интересное.
Следующий блок — это лист привилегий. То есть вообще про что? Ну, то есть в принципе понимаемых привилегий — не давать привилегий больше кому пользователю, сколько нужно.
То есть низко привилегированный, опять же, не должен иметь доступ к каким-то системным функциям, не должен иметь возможность выполнять какой-то административный функционал, зергнуть какие-то ручки и так далее.
Опять же как с K7, с цепей инъекции. Особого смысла там суперадминов давать не было, но это было.
Ввиду к тому, что не стоит так делать, если возможно избегать.
И четвертый — это у нас RAID-лимитер. Это как раз по истории с грудным OTP, с паролем, с DOS и со всей такой историей.
Вот никто не запрещает как бы все вместе применять, комбинировать и тем самым, опять же, мы говорили про дешевую атаку, это будет являться, ну можно сказать, дешевой защитой от силуэтта и это будет рвать и на исход. Ну в случае ред-лимитов, например, ну на инаме, там столько количества пользователей, но при этом все, там ты не можешь потом спрейтить пароль, ты не можешь их грузить, ты там, условно, падаешь, падаешь.
вот то есть главный вывод опять же да про то что все четыре контроля и небольшая там
не только не остануешься и не так интересно снова в том что применять и тестировать все еще
нужно применять тестировать нужно для простых бага для простых бага тем более не отталкиваться
только на метрике CvSS, потому что все веги, которые мы рассматривали,
там можно смело вешать PR-high и все на этом отдыхать.
Но это не так.
То есть фактически критичность в какой-то до критикал взлетает,
а так на руках имеем внутривиальные способы байпаса и вот это как раз переведение.
Передаю так.
Да, мы тут немножко, кажется, вышли за время.
быстро про выводы в целом
всего нашего исследования.
Так как уже сказали,
недопустимые события происходят
из-за комплекса проблем
и, соответственно, решать их нужно комплекс
различным командам,
обсекам следить за
реализацией ролевой модели,
в целом следить за внешним периметром
и так далее.
Приоритизировать можно как атакующие,
так и защитные действия.
То есть, соответственно,
как на слайде предыдущем мы показали,
что какие контролы больше покрывают уязвимостей.
Соответственно, если реализовать набор небольшой из четырех,
то можно закрыть довольно большой пласт уязвимостей.
Соответственно, так и атакующие могут приоритизировать свои проверки
на основе, допустим, тех-тетекта,
либо еще каких-то сигналов с внешнего периода.
и проблемы с учетными данными и контролем доступа.
Это наиболее массовые паттерны, которые мы до сих пор встречаем.
Да, как уже сказали, доклад командный.
Соответственно, на слайде представлена команда.
Всем большое здесь спасибо, кто на этом слайде.
Собственно, кто находил баги, делал ресерчи и так далее.
У нас на этом все.
Если есть временные вопросы, готовы выслушать вопросы. Спасибо.
Использовали яички своих, в принципе, все, да, постоянно
используем, если это какие-то анимизированные данные,
которые никак не касаются заказчиков, то мы используем
облачные, если это что-то критичное, то у нас, естественно,
салфост от решения развернутые, которые мы тоже активно
используем на каждом этапе, наверное, от спинтеста,
до анализа информации и так далее.
Там на самом деле все довольно просто обходится.
То есть если, ну, наверное, есть сейчас уже облачные, которые как-то с этим всем построже,
но в целом если говорить, что вот у меня есть моя система, и я хочу понять, как меня, например, могут взломать,
расскажи мне там 5 наиболее каких-нибудь векторов, то и Ромка все, по крайней мере.
Мы пока не сталкивались с такими, чтобы она не отвечала, а каким-то политикам запрещала.
По крайней мере, салфосты точно.
Чуть-чуть легче ее надо успокоить, что это не так.
Он же так же, что это даже справка, с конколонкой.
Делай свой рот.
И теперь, в этой лепестке.
Они сейчас за это деньги берутся?
Нет, нет, даже за деньги.
А у вас это не стоит.
Уже прошедший перейти за ручку.
Да.
А вот это за ручку.
Ну, а ручка нет.
Вот если перейти за ручку.
Я задавал?
Они, конечно, внизу стоят в следующем записи.
Вопросы?
А, да, вопросы.
Репорт сумма не мало.
Это не по-моему, вообще.
Это 0DA, который мы репортим регулятором, который, соответственно, потом...
Пусть они не собственно платили.
То есть, рекортируем регулятором, который, соответственно, вместе с виндарами это устраняем.
Здесь такая история.
Могли бы нам подманчить дать?
Не усекли бы.
Наверное, могли бы.
Почему регулятором, а не виндарам?
Почему?
Регулятором, а не виндарам.
потому что сложности от всех лендеров.
Мы не хотим усложнять процесс репорта уязвимости.
То есть наша задача, чтобы уязвимость закрыли,
искать различных лендеров, есть ли у них какая-то security policy или нет,
есть ли у них отдельный выделенный почтовый ящик, по которому они принимают репорты или нет.
Есть такая, наверное, отлаженная схема, по которой все приятные.
Да, я просто скажу насчет взаимодействия. На самом деле используют эскоржу в России очень странный.
Ту команду, которую не называют, здесь три раза обещали засудить за последний год, причем через рекорд, через стэк.
После этого мы уже просто...
Если что, когда говорите, что все еще битеры, ну и слипся битеры, а потом слип.
Потому что векторы странные, у них уровень зрелости небольшой,
Особенно тех, у кого это первая BDU, это прилетает.
И вот то, что коллеги говорят про Bounty, мы какой-то хоут выдерживаем.
Если мы нашли на проекте Zero Day, мы отправляем, BDU отреагировал,
вендор отреагировал, раз, два, три, четыре, пять, а сейчас можно Bounty.
Потому что иначе это нечестно.
Спасибо еще раз.