Хроники пентестера

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

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

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

    В одном из пентестов на сайте заказчика было найдено несколько критических уязвимостей, которые в перспективе могли позволить выполнять команды на сервере. Однако воспользоваться ими продолжительное время не получалось. Секунды превращались в минуты, минуты складывались в часы, цель была так близка, но все старания были безуспешны. Оглядевшись вокруг было замечено, что перед нами лишь один из сайтов большого хостинга. Учитывая, что на страницах исследуемого сайта и его соседей был замечен один и тот же зловред, вполне логично предположить, что злоумышленник до нас вряд ли стал бы заморачиваться с уязвимостями именно нашего анализируемого сайта. Наверняка он шел по пути наименьшего сопротивления и залился через соседей. Но ограничения при пентесте не позволяют повторить подобные подвиги. Между тем, старания все-таки не были напрасны и используя каскад уязвимостей сайт заказчика сдал свою оборону. Далее, вместо классического сбора информации, предстояло выяснить, каким образом зловред попал на страницы этого ресурса.

    image

    Следующая история раскрывает тему использования уязвимостей нулевого дня при пентестах. Перед нами очередной оф. сайт другого заказчика на вполне себе безопасной системе управления сайтом Joomla. При поверхностном серфинге на глаза попадает уязвимый модуль, информация об уязвимости в котором еще не успела просочиться в паблик. Также известна информация, что на днях через указанный модуль проходила массовая заливка. И как это не странно, сплоитс у нас уже был на руках:)) Далее, как в голливудских фильмах. Вводим target, запускаем, заливаемся, радуемся)) После этого предстояло ответить на вопрос, «кто здесь»? И ответ не заставил себя долго ждать. Как бы шеллы с eval и base64 очень палевны.

    Последняя история, о которой я хочу сегодня рассказать, не менее показательна, чем остальные. Шутка ли, когда на одном из внешних сайтов всеми известного и любимого российского банка установлен бэкдор на языке наших поднебесных друзей. Более того, даты показали, что бэкдор был залит более года назад и на протяжении всего этого времени оставался незамеченным! Остроты всей истории придает также тот факт, что операционная система, на котором расположен веб-сервер, входит в состав корпоративного домена Active Directory банка. Как было выяснено позже службой управления ИБ самого банка, за все время был зафиксирован лишь один запрос, который собственно и установил бэкдор, т.е. в этот раз просто повезло. Кстати, бэкдор (аля веб-шелл) под Tomcat действительно оказался довольно наворочен (добавили себе в копилку), а установлен он был к слову через дефолты в интерфейсе администрирования Tomcat.

    image

    Так как же защитится от подобных угроз?

    Во-первых, если вы планируете развернуть свой сайт на внешнем хостинге, поинтересуйтесь у хостера, какие действия он предпринимает для защиты сайтов своих клиентов. На эту тему вспоминается еще одна история. Анализировали мы как-то сайт, расположенный в одном из регионов нашей необъятной родины. Зафиксировали SQL-иньекцию и принялись ее раскручивать, и, буквально через полчаса, видим послание от хостера в свой адрес:) Но самое примечательное в этой истории это то, что хостер оперативно обеспечил виртуальный патчинг найденной нами уязвимости. С другой стороны, выбирая хостера, возможно не следует слишком много от него ожидать, но фундаментальные механизмы безопасности он должен обеспечивать при оказании своих услуг.

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

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

    Так, что же требуется, чтобы защитить сайт от атаки нулевого дня при этом не прибегая к анализу его безопасности методом фаззинга или исходного кода? По моему видению должно быть реализовано как минимум следующее:
    — стойкие пароли к используемым идентификаторам во всех интерфейсах (ftp, раздел администрирования и т.п.).
    — все интерфейсы администрирования должны быть доступны только для доверенных IP-адресов; опционально, использование двухфакторной аутентификации везде, где это возможно.
    — минимизация привилегий во всех компонентах.
    — правильно настроенные таблицы разграничения доступа (начиная с файловой системы и заканчивая разграничением доступа средствами системы управления сайтом, если она предоставляет подобный функционал).
    — безопасные конфигурации веб-сервера и его среды (например, безопасные конфигурации PHP).
    — использование превентивных механизмов контроля (Web Application Firewall).
    — ограничение сетевого доступа со стороны веб-приложения к любым другим компонентам сети; размещение веб-сервера в изолированной сетевой среде (aka персональная ДМЗ).

    Придерживаясь перечисленных подходов вы существенно повысите безопасность своего веб-приложения. Желаю успехов в постоянной битве добра с добром по другую сторону :)

    Комментарии 18

      0
      >> используйте стойкие, уникальные пароли везде, особенно на внешних веб-приложениях.
      >> Доступ к интерфейсам администрирования сайтом предоставляйте только доверенному списку IP-адресов.
      Советы 5летней давности
      Авторизация по сертификатам, лучше IPSec.
        0
        ipsec к авторизации не имеет никакого отношения, если что -)
          0
          Имеет)
            0
            Ох, неужели? И какое же?
              0
              Определимся с терминологией:
              Идентификация — присвоение чему-либо (пользователям например) идентификаторов, а также получение от чего-либо (пользователя) идентификатора для сопоставления с данными в системе
              Самый простой пример — логин
              Аутентификация — подтверждение аутентичности идентификатора (права пользоваться этим идентификатором)
              Например используя:
              — Пароль
              — Токен
              — Сертификат IPSec

              Авторизация — на основании подтвержденного идентификатора предоставление доступа к разрешенным ресурсам системы

              Многие реализации IPSec могут авторизовывать пользователей и компьютеры (разрешено-запрещено подключение) на основе данных аутетнификации
                0
                Я рад, что ты все-таки разобрался с терминологией и сделал это меньше чем за сутки. Отличный результат.
                Теперь ты знаешь, что ipsec не имеет к авторизации никакого отношения, лишь к аутентификации в некоторых реализациях.
                  0
                  к аутентификации IPSec имеет отношение всегда
                  к авторизации — в зависимости от задачи, он МОЖЕТ авторизовать, если этого требует задача
                    0
                    ок, покажи мне реализацию ipsec, которая производит авторизацию.
                      0
                      Реализации этого rfc
                      tools.ietf.org/html/rfc4301
                        0
                        ок, зачтем PAD как имеющую отношение к ipsec.
                          0
                          любая политика доступа — это уже авторизация
                          SPD туда же :)
        0
        смысл в том, что некоторые вещи остаются неизменными ;)
          +1
          Я уже немного пожалел о резкости первого комментария, виноват, не посмотрел сразу в профиль
          С уважением отношусь к вашему продукту xspider
          Чего, правда, не могу сказать о секлабе..)

          Но правда, стойкие пароли к ftp, это же… вызывает улыбку… стойкий пароль который передается открытым текстом…
          0
          да, секлаб действительно порой неожиданно (!) удивляет, например — http://www.securitylab.ru/analytics/407323.php

          >> Но правда, стойкие пароли к ftp, это же… вызывает улыбку… стойкий пароль который передается открытым текстом…

          не соглашусь! пароль действительно передается открытым текстом, но для того, чтобы его перехватить злоумышленнику требуется прослушивать этот трафик, т.е. преодолеть некоторые защитные механизмы. Тут речь больше идет о том, что использовать пароль вида «123» на ftp не является безопасным) И разумеется стоит использовать защищенные протоколы везде, где это возможно.
            +2
            Плохая статья, нет ни одного упоминания и скриншота MaxPatrol ((
              0
              ^_^ :D
              0
              Не хватает пункта — повышение уровня осведомленности пользователей.
                0
                Кому нужно повышать осведомленность в плане веб-безопасности в первую очередь, так это администраторам. Многие из них просто не в курсе как обеспечить выполнение пунктов, перечисленных в статье.

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

              Самое читаемое