Информационные технологии развиваются семимильными шагами, но одно остается стабильным — наличие «дыр в безопасности». Мы проанализировали результаты более 100 прошлогодних проектов и пришли к выводу, что многие компании все еще допускают критичные ошибки и оставляют большое количество «дыр», открывающих для хакеров путь к внутренней инфраструктуре, персональным данным пользователей и возможностям реализации различных угроз информационной безопасности.

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

В минувшем году мы провели более 100 проектов по разным типам работ: внешний и внутренний пентест, анализ защищенности веб‑ и мобильных приложений — для компаний из таких областей, как телекоммуникации, информационные технологии, маркетинг, энергетика, торговля и многие другие.

Накопившаяся база отчетов по проектам стала хорошей репрезентативной выборкой для проведения аналитического исследования. Надеемся, оно поможет компаниям (и просто рядовым пользователям) посмотреть на проблемы ИБ с другой стороны и защитить свои информационные активы от хакеров.

Как говорится, «повторенье — мать заиканья ученья», поэтому в этой статье мы в 100 500 очередной раз хотим напомнить об актуальных угрозах ИБ и важности соблюдения компаниями и пользователями правил информационной гигиены безопасности. В своих «назиданиях» мы основываемся на ключевых показателях нашего годового аналитического отчета.

Для удобства и наглядности мы разделили полученные результаты по блокам в зависимости от типа работ. Рассмотрим каждый из них по порядку.

Внешний пентест

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

Основные результаты работ

Преодолеть внешний периметр нам удалось в 88% выполненных в 2023 году проектов. Такие цифры не могут не настораживать, ведь получается, что в среднем практически в 9 компаниях из 10 злоумышленник может попасть во внутреннюю сеть, скомпрометировать узлы внешнего периметра, а также получить доступ к критичным данным, внешним системам и приложениям.

Внешний пентест традиционно считается «успешным», если преодолен внешний периметр. Однако это не всегда так. Важно понимать, что даже компрометация узлов внешнего периметра, не имеющих прямой связанности с внутренней сетью организации (например, узлов в DMZ) может привести к существенному ущербу для компании, так как открывает злоумышленнику возможности проведения дальнейших атак и получения различных чувствительных данных.

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

А в случае если учетные данные принадлежат еще и доменным пользователям, их можно использовать для получения доступа по VPN к внутренней сети. Хотим отметить, что тенденция использования VPN‑сервисов, образовавшаяся во времена ковида, сохраняется и по сей день, что упрощает проведение атак на внешний периметр. Напомним, что решение этой проблемы возможно с помощью внедрения двухфакторной аутентификации, дополнительного мониторинга сетевой активности пользователей и разграничения сетевого доступа.

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

В последние годы мы часто слышим новости об утечках персональных данных, при этом мало кто задумывается о том, что для получения таких данных зачастую даже не нужно попадать во внутреннюю сеть компании. Например, в одном из проектов для выгрузки персональных данных пользователей нам было достаточно проэксплуатировать обнаруженные на внешнем периметре недостатки контроля доступа. И даже несмотря на то, что доступ во «внутрянку» получен не был, возможный ущерб информационным активам (и репутации) компании в случае с реальным хакером очевиден.

Распространенные критические уязвимости внешних периметров

Именно критические уязвимости чаще всего становятся отправной точкой векторов преодоления внешнего периметра. Мы составили ТОП «критов», встретившихся нам в ходе проектов в российских компаниях в 2023 году:

Удивительно, но уже несколько лет «первенство» остается за использованием слабых паролей. Эта проблема встретилась в 78% компаний в 2021 году и в 59% — в 2022, а в 2023 году именно использование слабых паролей стало начальной точкой вектора атаки в 50% проектов.

Таким образом, самым уязвимым «звеном» остается человеческий фактор — пользователи по‑прежнему используют простые и легко подбираемые пароли. Поэтому в очередной раз хотим обратить внимание на важность проведения обучения сотрудников основам ИБ, а также внедрения строгой парольной политики.

Еще одна проблема, с которой связана значительная часть успешных атак, — это использование ПО c известными уязвимостями. В прошедшем году «любимым» ПО для нас стала система Bitrix, ведь эксплуатация уязвимостей устаревших версий этой системы послужила начальной точкой проникновения в 30% проектов.

Дополнительные наблюдения

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

Во‑первых, компании все чаще стали обращаться за услугами анализа защищенности на долгосрочной основе (годовые контракты, периодические работы, регулярные автоматизированные сканирования и прочие услуги). Это, конечно, хорошо и здорово, если бы не одно «но» — исправлять обнаруженные уязвимости и недостатки они нередко забывают.

В результате получается следующая история: мы проводим внешний пентест, выявляем критические баги, компрометируем учетки, успешно преодолеваем внешний периметр, предоставляем отчет с исчерпывающей информацией об обнаруженных багах и рекомендациях по их устранению. Спустя N‑ое количество времени проводим для этого же заказчика в этой же инфраструктуре повторные работы и … всё пофикшено картина маслом — видим те же баги, те же скомпрометированные учетные данные и т. д. Получаем бесконечный цикл как на картинке :)

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

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

Внутренний пентест

Внутреннее тестирование на проникновение направлено на проверку возможности повышения привилегий во внутренней инфраструктуре, получения доступа к критичной информации или системам.

Основные результаты работ

В большинстве случаев в таких работах цель заключается в получении контроля над доменом. И тем не менее, все чаще ставятся дополнительные цели, например получение доступа к различным базам данных, к сегментам АСУ ТП и системам 1С. Это говорит о том, что компании уделяют все больше внимания защите своих информационных активов во внутренней сети.

Естественно, такая тенденция не может не радовать. Но, к сожалению, внутренний периметр по‑прежнему остается уязвимым для хакеров. Наглядное доказательство — наши статистические данные: достигнуть поставленных целей нам удалось в 70% проектов.

В 90% проектов основная цель заключалась в захвате контроллера домена, который открывает возможность дальнейшего продвижения во внутренней сети. Результатом развития атаки может стать получение доступа к различным критичным данным и системам:

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

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

Распространенные критические уязвимости внутренних сетей

Начальной точкой любого вектора повышения привилегий и получения доступа к различным системам и данным во внутренней сети выступают критические уязвимости и недостатки. В минувшем году во внутренних сетях нам наиболее часто встречались следующие «криты»:

Как видим, использование слабых и повторяющихся паролей является главной проблемой не только внешнего периметра, но и внутренних сетей. Пользователи по‑прежнему используют «безопасные» пароли, вроде «Qwerty123», и пароли, совпадающие с именем учетной записи или с названием компании.

Именно использование слабых паролей послужило начальной точкой в 21% векторов атаки. Пример типичного вектора показан на рисунке:

Еще одной злободневной проблемой стала уязвимая конфигурация центров сертификации и шаблонов сертификатов. Например, количество успешных векторов, начатых с эксплуатации уязвимой конфигурации шаблонов сертификатов, совпадает со статистикой по векторам, основанным на использовании слабых паролей. Типичный вектор атаки, основанный на эксплуатации уязвимой конфигурации шаблонов сертификатов выглядит так:

Анализ защищенности веб- и мобильных приложений

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

Основные результаты работ

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

Статистика по мобилкам порадовала нас больше, чем по вебкам — высокий уровень защищенности мы отметили в 53% исследованных мобильных приложений. Для наглядности провели сравнительное исследование уровней защищенности веб‑ и мобильных приложений, результаты которого ниже:

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

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

Распространенные уязвимости веб‑приложений

Для веб‑приложений мы анализировали статистику как по уязвимостям и недостаткам всех степеней критичности, так и отдельно только по «критам». Картина получилась в целом схожая, поэтому приводим ТОП по всем уязвимостям и недостаткам:

На первом месте, как и в последние несколько лет, недостатки контроля доступа. Об этой проблеме из года в год мы писали в аналитических отчетах, которые можно найти на нашем сайте (2022 и 2021).

Отметим, что недостатки контроля доступа несут в себе следующие угрозы:

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

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

Оказалось, что обнаруженные переменные окружения содержат учетные данные для доступа к s3-хранилищу, которое использовалось исследуемым приложением для хранения контента (изображений, видео, документов и т. п.).

Так, успешно получив доступ к s3-хранилищу, мы подменили контент на сайте — заменили логотип компании партнера на котика:

И было бы, конечно, весело, если б не так грустно. Ведь настоящий злоумышленник может легко использовать эту багу для размещения на сайте нелегитимного контента, например, экстремистских материалов, политических лозунгов, ЛГБТ‑пропаганды … да чего угодно, что в дальнейшем может обернуться серьезными проблемами для владельца ресурса.

Если мы еще недостаточно нагнали ужаса обратили внимание на важность устранения «дыр» в безопасности, вот еще пример: в одном из проектов мы нашли в конфигурационном файле валидный JWT‑секрет, который позволил сгенерировать JWT‑токен и получить доступ к различным чувствительным данным от имени привилегированного пользователя admin, а дальше — «заходите, люди добрые, берите, что хотите» ©.

Кроме того, как и в 2022 году, остаются актуальными уязвимости и недостатки, связанные с некорректной обработкой ошибок, а также приводящие к возможности проведения атак типа XSS (межсайтовое внедрение сценариев).

Внимание в минувшем году также привлекли недостатки бизнес‑логики, оказавшиеся на 5-м месте ТОПа. Про эту проблему мы ранее подробно писали в статье «Когда 2+2=5: чем страшны ошибки бизнес‑логики приложений и почему их легко не заметить при разработке».

Распространенные уязвимости мобильных приложений

При подсчете статистики по мобилкам мы рассматривали отдельно уязвимости и недостатки для серверной и клиентской частей.

Для серверной части получилась следующая гистограмма:

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

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

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

Для клиентской части мы получили следующие данные:

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

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

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

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

Заключение

Подводя итог, хотим обратить особое внимание на следующие прописные истины моменты:

1. Основа обеспечения информационной безопасности — профилактика. Важно постоянно следить за уровнем защищенности внешнего периметра и внутренних сетей компании, а также веб‑ и мобильных приложений.

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

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

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

Автор: Анна Коваленко, аналитик отдела анализа защищенности, «Солар»