There is no 100% guarantee. Колонка Юрия Гольцева

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

Intro

Когда кто-нибудь пытается убедить меня в том, что он, компания или продукт способны выявить абсолютно все уязвимости в тестируемой системе, я могу лишь предположить, что передо мной либо кто-то из отдела продаж, либо некомпетентный технический специалист. С увеличением скоупа количество векторов атак растет в геометрической прогрессии (FUD! Deal with it!).

В идеальном мире это должен понимать как исполнитель, так и заказчик. Как ты знаешь, мы в таком мире не живем. Каждый уважающий себя и своего заказчика консалтер перед заключением договора тщательно обговаривает нюансы и возможные спорные моменты. Заказчик должен знать, почему подобные работы не дают стопроцентного раскрытия всех уязвимостей ИС. Это аксиома. Количество найденных уязвимостей напрямую зависит от их наличия и от компетенции исполнителя. В общем случае консалтер обязуется применить предложенную методологию поиска определенных типов уязвимостей в отношении обозначенного перечня ресурсов. То, что в результате работ по оценке анализа защищенности рождаются новые техники эксплуатации и векторы атак, — явление побочное и абсолютно не обязательное.

Прецедент

В январе 2016 года произошел интересный и первый в своем роде прецедент: на компанию, которая занимается консалтингом в сфере ИБ, был подан иск в суд. Причина — заказчик, изучив отчет о проделанной работе, заподозрил исполнителя в отсутствии технических компетенций.

История началась в октябре 2013 года. Некая организация Affinity Gaming, которая занималась игорным бизнесом, обнаружила утечку данных кредитных карт своих клиентов. В рамках реагирования владельцы казино заключили контракт с фирмой Trustwave, которая обязалась провести расследование инцидента и, вероятно, дать рекомендации по устранению уязвимостей.

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

Далее произошло вот что. Для соответствия очередному стандарту, который форсировал игорный комитет штата Миссури (где располагается казино Affinity), необходимо было провести тестирование на проникновение. В апреле 2014 года руководство Affinity Gaming обратилось за этой услугой в небезызвестную компанию Ernst & Young. Аудиторы E&Y обнаружили в сети подозрительную активность, источником которой, как выяснилось, была программа Framepkg.exe. Важный момент: этот самый бинарник был исследован Trustwave, но его сомнительные функции не были упомянуты в отчете.

Казалось бы, такое случается: между аудитами прошло некоторое время, состояние ИС могло измениться. В параграфе PRELIMINARY STATEMENT иска, не сказано, каким образом было выявлено, что отчет Trustwave — полная туфта. Этот момент поставил под вопрос все результаты работы Trustwave.

Владелец казино обратился в IT-security компанию — Mandiant. Ребята из этой конторы провели собственное расследование и в итоге пришли к выводу, что отчет Trustwave был очень неточным, и складывалось впечатление, что работы были проведены неадекватно. По факту Trustwave солгал заказчику о том, что источник утечки данных был диагностирован и устранен. В реальности исполнитель изучил лишь малую долю ресурсов и так и не смог точно выявить, как именно было осуществлено проникновение.

Заказчик в результате посчитал, что договор грубо нарушен и Affinity понесла колоссальные убытки, в связи с чем неплохо было бы, если бы исполнитель вернул все потери. В Trustwave делать это отказались, и в результате в конце 2015 года компания Affinity Gaming подала иск в суд.

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

Piece from my reality

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

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

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

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

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

Из любопытства и желания помочь безопасникам я принялся изучать логи pwnage. В этот момент я осознал, что, скорее всего, мои волнения были напрасными. После анализа доказательств взлома, выложенных на публике, стало понятно, что весь инцидент — проделки скрипт-кидди с sqlmap в консоли.

Ставка была сделана на то, что уязвимый ресурс доступен на одном из доменов серьезной трансконтинентальной корпорации. Соответственно, публикация подобного pwnage будет сконвертирована людьми, далекими от ИТ и ИБ, в популярность героя, который так и остался неизвестен. «Хакер», вероятно, даже не понял, куда он попал и какие это перед ним открывает возможности в плане развития атаки. Он решил ограничиться лишь бесполезным дампом БД, даже не удосужившись немного изучить код приложения и добиться RCE.

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

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

Выводы

Делать какие-то конкретные выводы относительно истории с Trustwave пока рано, посмотрим, как события будут развиваться дальше. Побывав в роли заказчика услуг тестирования на проникновение хотя бы пару раз (и работая с разными компаниями), понимаешь что «пропустить» одну уязвимость, но найти другую — совершенно обычная ситуация для любого исполнителя. Глупо это отрицать.

Я считаю, что это объяснимо — все сильно зависит от обговоренного скоупа, сроков выполнения работ и состава команды исполнителя. Ситуация становится печальной, когда разница в результатах работ при относительно одинаковых исходных данных колоссальна. На мой взгляд, обеим сторонам стоит форсировать добавление в договор дополнительного пункта: об ответственности сторон.

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

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

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

Outro

История с Trustwave очень интересна с точки зрения взаимоотношений заказчик — исполнитель в индустрии ИБ. Из-за отсутствия технических данных и полных обоснований в публичном доступе нет смысла кого-то обвинять или защищать. Остается только следить за развитием событий — возможно, этот прецедент станет причиной появления чего-то нового в индустрии ИБ-консалтинга. К чему бы это нас это ни привело, делай свое дело так, чтобы тебе никогда не было стыдно за результат. Stay tuned!