Информационные технологии развиваются семимильными шагами, но одно остается стабильным – наличие «дыр в безопасности». Мы проанализировали результаты более 100 прошлогодних проектов и пришли к выводу, что многие компании все еще допускают критичные ошибки и оставляют большое количество «дыр», открывающих для хакеров путь к внутренней инфраструктуре, персональным данным пользователей и возможностям реализации различных угроз информационной безопасности.
В посте ниже делимся своей болью результатами проведенных аналитических исследований: собранной статистикой, рекомендациями и интересными случаями из практики.
В минувшем году мы провели более 100 проектов по разным типам работ: внешний и внутренний пентест, анализ защищенности веб- и мобильных приложений – для компаний из таких областей, как телекоммуникации, информационные технологии, маркетинг, энергетика, торговля и многие другие.
Накопившаяся база отчетов по проектам стала хорошей репрезентативной выборкой для проведения аналитического исследования. Надеемся, оно поможет компаниям (и просто рядовым пользователям) посмотреть на проблемы ИБ с другой стороны и защитить свои информационные активы от хакеров.
Как говорится, «повторенье – мать заиканья ученья», поэтому в этой статье мы в 100500 очередной раз хотим напомнить об актуальных угрозах ИБ и важности соблюдения компаниями и пользователями правил информационной гигиены безопасности. В своих «назиданиях» мы основываемся на ключевых показателях нашего годового аналитического отчета.
Для удобства и наглядности мы разделили полученные результаты по блокам в зависимости от типа работ. Рассмотрим каждый из них по порядку.
Внешний пентест
Внешнее тестирование на проникновение направлено на поиск уязвимостей и недостатков с высоким уровнем критичности, эксплуатация которых может привести к получению доступа во внутреннюю сеть организации или к критичным внешним системам.
Основные результаты работ
Преодолеть внешний периметр нам удалось в 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. Помимо уязвимостей в самих системах, немалую роль играет человеческий фактор. Зачастую именно использование слабых и повторяющихся паролей
становится главной проблемой, поэтому очень важно проводить обучение
сотрудников основам ИБ и вводить стогую парольную политику.
Автор: Анна Коваленко, аналитик отдела анализа защищенности, "Солар"