Уязвимостей – Лучшие сайты для поиска уязвимостей. Списки уязвимостей

Лучшие сайты для поиска уязвимостей. Списки уязвимостей

Каждый день появляются новые уязвимости затрагивающие всевозможные программы, сервисы и операционные системы, такие как: Windows, macOS, Linux и Android.  Многие уязвимости ускользают от внимания обладателей этих устройств и пентестеров, но все эти уязвимости агрегируются и добавляются в базы уязвимостей. О таких сайтах собирающих уязвимости мы и расскажем в сегодняшней статье.

Еще по теме: Самые популярные эксплойт-паки

Что такое CVE?

Раньше в различных сервисах для указания одних и тех же уязвимостей использовались разные названия. Для устранения путаницы с названием уязвимостей компания MITRE предложила решение, независимое от различных производителей средств поиска уязвимостей. Это решение было реализовано в виде базы данных уязвимостей CVE Common Vulnerabilities and Exposures (Общие уязвимости и воздействия). Это решение позволило всем специалистам и производителям разговаривать на одном языке.

В данной базе для каждой уязвимости используется следующий атрибут записи CVE- YYYY-NNNN, где YYYY — это год обнаружения уязвимости, а NNNN — ее порядковый номер. В нашем примере уязвимость SSH V.7.7 под названием CVE-2018-15473.

Уязвимости пользуются большим спросом у хакеров и пентестеров. Они могут использоваться для взлома устаревших версий Windows, повышения привилегий и доступа к маршрутизаторам.

Зарубежные сайты для поиска уязвимостей

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

CIRCL

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

На сайте CIRCL представлены публикации исследований безопасности и база данных уязвимостей для поиска.

VulDB

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

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

SecurityFocus

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

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

40day.today

0day.today (доступный через Tor) — это база данных уязвимостей, которая также продает личные эксплойты, цена которых не превышает 5000$.

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

Rapid7

У Rapid7, создателей знаменитого фреймворка Metasploit, тоже есть свой архив уязвимостей. Однако, в отличие от других баз данных, Rapid7 очень редко использует фактический код уязвимости CVE. Вместо этого сервис предлагает советы, содержащие полезные ссылки на соответствующую документацию для исправления, а также ссылки на модули msfconsole.

К примеру, вышеупомянутую уязвимость SSH CVE-2018-15473 можно найти в msfconsole и применить с большой легкостью.

Еще по теме: Где скачать вирусы

NIST

Национальный институт стандартов и технологий NIST — это одна из старейших физико-технических лабораторий в США. В настоящее время он участвует в проекте «Национальная инициатива по образованию в области кибербезопасности».

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

Packet Storm Security

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

Exploit Database

База данных Exploit Database в настоящее время поддерживается организацией Offensive Security, которая специализируется на взломе Windows и безопасности веб-приложений.

В своей базе данных, доступной для поиска, на данный момент более 40000 уязвимостей. Есть также сервис Google hacking database, о котором мы рассказывали в статье Google Dorks.

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

Vulners

Vulners, основанная Киром Ермаковым, представляет собой базу данных CVE, в настоящее время содержащую более 176500 уязвимостей. Сайт включает статистику CVE, аудитор управления уязвимостями Linux.

Еще по теме: Образцы вирусов с исходным кодом

MITRE

MITRE — спонсируемая правительством США организация. Сайт ведет одну из самых больших баз данных уязвимостей.

Российские сайты для поиска уязвимостей

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

База данных уязвимостей ФСТЭК

ФСТЭК — на мой субъективный взгляд далеко не самый лучший сайт для поиска уязвимостей.

База данных уязвимостей SecurityLab

Архив уязвимостей SecurityLab обновляется чаще чем ФСТЭК. Данных об уязвимости мало, но есть категории. Сайт черпает информацию об уязвимостях из зарубежных источников. Ничего своего, как впрочем и публикующиеся там статьи, как впрочем и весь сегодняшний рунет переводящий и перепечатывающий зарубежных коллег.

www.spy-soft.net

Уязвимость (компьютерная безопасность) — это… Что такое Уязвимость (компьютерная безопасность)?

У этого термина существуют и другие значения, см. уязвимость.

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

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

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

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

Для обеспечения защищённости и целостности системы необходимо постоянно следить за ней: устанавливать обновления, и использовать инструменты, которые помогают противодействовать возможным атакам. Уязвимости обнаруживались во всех основных операционных системах, включая Microsoft Windows, Mac OS, различные варианты UNIX (в том числе GNU/Linux) и OpenVMS. Так как новые уязвимости находят непрерывно, единственный путь уменьшить вероятность их использования против системы — постоянная бдительность.

Примеры уязвимостей

Распространённые типы уязвимостей включают в себя:

• Нарушения безопасности доступа к памяти, такие как:
• Ошибки проверки вводимых данных, такие как:
• Состояния гонки, такие как:
  • Ошибки времени-проверки-ко-времени-использования
  • Гонки символьных ссылок
• Ошибки путаницы привилегий, такие как:
• Эскалация привилегий, такие как:

См. также

Недекларированные возможности

Ссылки

dic.academic.ru

Типы уязвимостей сайтов | Losst

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

В этой статье мы рассмотрим самые опасные типы уязвимостей сайтов и веб-приложений по версии проекта ТОП 10 OWASP в 2017 году. Все уязвимости отсортированы по важности. Самые частые и самые опасные — вверху, менее опасные — ниже. Но если они уже попали в этот список, значит на них стоит обратить внимание.

Содержание статьи:

Типы уязвимостей сайтов

А теперь давайте перейдем к нашему списку.

1. Инъекции/Injection

Под инъекциями подразумеваются уязвимости, которые возникают в результате передачи не проверенных, введенных пользователем данных интерпретатору для выполнения. Таким образом, любой пользователь может выполнить произвольный код в интерпретаторе. Самые распространенные типы инъекций — SQL, OS, XXE и LDAP.

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

2. Проблемы аутентификации и проверки сессий

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

3. XSS

Первые две уязвимости представляли больше опасности для сайта и его сервера. XSS не так опасна для сервера, но опасна для пользователя. Она работает в браузере пользователя, и поэтому позволяет только украсть его данные. XSS или Cross-Site Scripting работает в JavaScript. Принцип тот же, что и в инъекциях. Злоумышленник передает специальную строку в каком-либо поле, в строке содержится JS код, далее браузер думает, что этот код отправлен сайтом и выполняет его, а код может быть любым. Для противодействия таким атакам нужно экранировать все специальные символы с помощью функции htmlspecialchars или аналогов.

4. Проблемы контроля доступа

Нередко по недосмотру администраторов обычным пользователям становятся доступны данные, которые должны быть закрыты. Этой проблеме подвержены даже популярные движки. Ярким тому примером можно привести файлы в корне сайта. Например, файл wp-config.php с паролями доступа к базе данных недоступен, потому что имеет расширение php. Но если вы редактируете его в Vim и сохраняете неверно, то создается резервная копия с расширением .swp и ее то уже можно открыть в браузере без препятствий.

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

5. Неверная конфигурация

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

6. Незащищенные конфиденциальные данные

Многие веб-приложения, сайты и API не защищают конфиденциальные данные пользователя и передают их в открытом виде. К таким данным могут относиться не только пароли, токены и ключи, но и медицинская, финансовая информация. Злоумышленники могут похитить или даже модифицировать важные данные с помощью атаки «Человек посередине». Конфиденциальные данные должны быть защищены, например, с помощью шифрования https или других методов.

7. Недостаточная защита от атак

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

8. Уязвимости CSRF

Атака CSRF или Cross-Site Request Forgery позволяет злоумышленнику заставить браузер жертвы отправить определенный HTTP запрос, включая куки, файлы сеанса и любую другую, автоматически включаемую информацию в уязвимое веб-приложение.

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

9. Использование компонентов с уязвимостями

Компоненты, такие как библиотеки, фреймворки и другие программные модули работают с теми же полномочиями, что и приложение. Если в одном из компонентов есть уязвимость, то в результате атаки на нее злоумышленник может украсть важные данные или даже получить управление над сервером. Приложения и API, использующие компоненты с известными уязвимостями могут подорвать защиту приложений и сделать возможными различные атаки. Там могут быть разные типы уязвимостей сайтов, и они могут открыть доступ к разным данным.

10. Незащищенные API

Большинство современных приложений часто включают в себя клиентские приложение и богатые API интерфейсы, доступные через JavaScript в браузере или из мобильных приложений. Они могут работать по протоколам SOAP/XML, REST/JSON, RPC, GWT и так далее. Эти API очень часто не защищены и тоже содержат множество ошибок, которые приводят к уязвимостям.

Выводы

В этой статье мы рассмотрели виды уязвимостей сайта, которые встречаются чаще всего по версии ресурса owasp. Как видите, среди чисто программных проблем, таких, как SQL инъекции, XSS или СSRF есть и проблемы в настройке серверов, которые тоже часто причиняют проблемы. Во всяком случае, теперь вы знаете какие уязвимости веб-сайтов бывают, и можете сделать ваш ресурс более безопасным.

Оцените статью:

Загрузка…

losst.ru

Меряем уязвимости: классификаторы и метрики компьютерных брешей

Содержание статьи

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

«Общепринятых систем по классификации брешей в нашей стране не существует» –
эту фразу я поставлю во главу угла. Продвинутым государством в этом плане стали
США. Там ведут несколько классификаций и активно используют их как в
образовательном процессе, так и в технологиях. Одной из самых известных систем

классификации является CVE, которая курируется компанией NCSD (National Cyber
Security Division) при одном из Министерств США. Рассмотрим эту систему
подробнее.

 

СVE (Common Vulnerabilities and Exposures)

По сути, CVE — это «словарь» известных уязвимостей, имеющий строгую
характеристику по описательным критериям, что отличает его, скажем, от
Bugtrack-ленты. Полностью CVE можно отыскать в Национальной Базе Уязвимостей США
(NVD — nvd.nist.gov) или на
официальном сайте (cve.mitre.org/data/downloads).
Причем, распространяется база в нескольких форматах: xml, html, csf, xsd schema.
Из-за такой доступности, открытости и удобства к базе CVE часто обращаются сами
разработчики различного ПО (в первую очередь, нацеленного на рынок
информационной безопасности).

Общий вид записи CVE выглядит примерно так:

CVE ID, Reference и Description.

ID записывается с указанием кода и порядкового номера, например
«CVE-1999-03». В поле Reference записываются различного рода ссылки на патчи,
рекомендательного рода документы или комментарии разработчика. Description
отвечает за описание самой уязвимости. Короче, CVE — система широкого профиля и
никоим образом не сосредотачивается только на клиентских уязвимостях или,
скажем, исключительно на WEB-протоколе. Изначально она задумывалась как единый
стандарт идентификации уязвимостей, который должен охватывать несколько звеньев
информационной системы: систему поиска и обнаружения брешей (например, сканер
безопасности), антивирусное ПО, а также исследуемое ПО.

Как появилась идея ее создания? Многие компании занимаются поиском брешей в
различных продуктах на основе политики (не)разглашения информации и
взаимодействия с производителями. Как-то, при исследовании одного из продуктов
десятью различными компаниями, одной и той же уязвимости были присвоены
абсолютно разные названия. После выявления сей вопиющей несправедливости было
принято соглашение о едином стандарте. Тогда же компания MITRE Corporation (mitre.org)
предложила решение, независимое от различных производителей средств поиска
уязвимостей, и взяла на себя ответственность за его воплощение. Нельзя сказать,
что после этого все баги стали упорядоченными. Разработчики продолжают активно
развивать самостоятельные начинания. Часть из них имеют платную подписку, и
антивирусные компании частенько обращаются к ним и добавляют соответствующие
сигнатуры в свои продукты. Стоимость такой годовой подписки составляет около
$5000 и выше.

 

BID

Эта классификация присутствует исключительно на портале Securityfocus
(используется в ленте

securityfocus.com/vulnerabilities). Одна из отличительных особенностей BID –
совместимость с CVE. Условно говоря, найденная уязвимость в BID имеет ссылку на
номер CVE и, соответственно, равнозначна по информации. У системы есть ряд
описательных свойств – например, класс, возможность локального или удаленного
исполнения и т.п. В будущем ты убедишься, что этих параметров недостаточно для
полной характеристики, но, тем не менее, BID дает разработчику вполне наглядную
информацию о выявленной бреши.

 

OSVDB

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

 

Secunia

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

 

ISS X-Force

ISS затрагивает все перечисленные выше критерии, но вдобавок описывает
бизнес-импакт, а именно – материальный ущерб, который может повлечь за собой
угроза эксплуатации. Например, баг «Microsoft Excel Remote Code Execution»,
нацеленный на компьютер сотрудника банка или предприятия, способен привести к
краже важных документов, ущерб от разглашения которых может исчисляться
миллионами. Оценить урон от различных видов атак можно, ознакомившись с одним из
ведущих блогов в русскоязычном сегменте о security-бричах и утечках — Perimetrix.

Также в системе присутствует качественно новая черта — переход к метрикам
безопасности для описания свойств уязвимости. Для этого используется общая
система подсчета рисков уязвимостей CVSS версии 2. Она представляет собой шкалы,
на основе которых выставляются баллы. Система метрик была придумана для
разделения приоритетов над исправлением уязвимостей. Каждая шкала относится к
определенному смысловому разделу, который называется метрикой. В CVSS v.2 их
три: базовая метрика, временная метрика и контекстная метрика. Хакеров
заинтересует только первая.

 

Базовая метрика

Нередко на солидных порталах по безопасности можно увидеть фразу – «CVSS Base
Score = 9.2″. Как это понимать? Параметр вычисляется по специальной формуле:

BaseScore = round_to_1_decimal(((0.6*Impact)+(0.4*Exploitability)-1.5)*f(Impact))

– плюс еще несколько. Все эти формулы можно найти по адресу
first.org/cvss.

Чтобы все стало понятнее, рассмотрим пример. Задан вектор уязвимости базовой
метрики вида: «AV:N/AC:L/Au:N/C:N/I:N/A:C». Все красуется на странице описания,
но ты абсолютно не можешь расшифровать эти иероглифы! Я тебе помогу. Итак,
расшифровываем по порядку.

Access Vector: Network — возможность доступа к объекту исключительно
через сеть. Для эксплуатации уязвимости злоумышленник должен обладать доступом к
уязвимому ПО, причем этот доступ ограничен только величиной сетевого стека.
Локального доступа или доступа из соседней сети не требуется. Такие уязвимости
часто называют эксплуатируемыми удаленно. Примером такой сетевой атаки служит
переполнение буфера RPC.

Access Complexity: Low — сложность доступа к ресурсу: низкая. Для
эксплуатации специальных условий и особых обстоятельств не требуется — все
стандартно, шаблонно, общедоступно.

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

Confidentiality Impact: None — влияние на разглашение критичной
информации.

Integrity Impact: None — нарушение целостности. Понятие «целостность»
связано с достоверностью и точностью информации. Если бы у злоумышленника была
возможность модификации файлов, изменения области исполнения файлов, то мы бы
поставили здесь C (полное) или P (частичное, от «partial»).

Availability Impact: Complete — атаки, потребляющие пропускную
способность сети, циклы процессора или дисковое пространство, которые влияют на
доступность системы. Если эксплуатация уязвимости вызывает отказ в обслуживании,
то Availability Impact имеет значение «Complete».

 

Временная метрика

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

На все эти вопросы отвечают временные метрики. Рассмотрим некоторые их
векторы.

Exploitability (E) — возможность эксплуатации. Пожалуй, один из
важнейших критериев. Речь идет конкретно о доступности средства (кода, эксплойта,
технологии), которое успешно работает. Важно учитывать и то, что доступный
эксплойт можно использовать далеко не всегда. Используемые описательные флаги: U
(недоступен или непроверен), Proof-of-Concept (POC — опубликована наглядная
демонстрация уязвимости), F (функциональный, и рабочий эксплойт у тебя в руках),
H («high risk» всей темы, чаще всего характерен для червей или для уязвимостей с
широко популярным описанием), ND (без разницы, вектор метрики не влияет ни на
что существенное, поэтому учитывать его не надо).

Remediation Level (RL) — уровень исправления. Голос уязвимости услышал
весь свет, вот только как поступят разработчики? Порой они просто молчат, потому
что их уже не осталось в живых (простите, за цинизм и черный юмор), а иногда
абсолютно сторонние организации и неофициальные источники начинают заботиться о
безопасности на первый взгляд чужих продуктов и оперативно писать заплатки.

Report Confidence (RC) — степень достоверности отчета. Сколько слухов
и разговоров крутится вокруг! Банальный пример: человек написал информацию якобы
о рабочей критической уязвимости. А на деле оказалось, что это программный
дефект и ничего существенного собой не представляет. Подтверждена ли уязвимость
экспертами или же это просто проделки хакерских слухов? Ответ на этот вопрос
даст вектор Report Confidence.

Параметры всех указанных векторов градируются вариантами «да/нет/возможно».

 

Контекстная метрика

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

Collateral Damage Potential (CDP) — вероятность нанесения косвенного
ущерба. Описывает экономические или технические потери. Скажем, нам встретится
уязвимость, приводящая к DoS-атаке. После ее эксплуатации часть сетевого
оборудования перегревается, не справляясь с работой, и выходит из строя. Но при
этом ущерб оказывается незначительным из-за низкой стоимости устройства и его
расположения (вне защищаемых и важных объектов).

Target Distribution (TD) — плотность целей. Влияет ли уязвимость
только на одну цель, либо с ее помощью можно поработить огромное число машин?
Если это стендовое показательное выступление, лабораторный практикум или
эксплуатация на машине, изолированной от других, то значение этого вектора равно
нулю.

 

Использование классификаторов в сканерах

Современные автоматизированные аудиторы принято затачивать под какую-либо
конкретную базу знаний. Во-первых, это престижно, во-вторых — полезно. К
примеру, при подготовке к аттестации по одному из современных стандартов (NERC-CIP,
PCI, FISMA, GLBA или HIPAA) администратору предоставляется возможность получить
шаблонный отчет, соответствующий документу, издаваемому аудитором. Я встречал
такое в современных сканерах беспроводной безопасности, типа AirMagnet, а также
дорогих коммерческих сканерах вроде ISS Security Scanner. Порой сканеры
безопасности прибегают к использованию собственного разделения брешей по ID.
Подобная практика применяется в Nessus, который таки сменил лицензию на
полукоммерческую.

 

Отдельные классификации

Подчас в Сети можно заметить абсолютно самопальные классификации, вроде
Common Criteria Web Application Security Scoring (CCWAPSS) 1.1. Естественно,
большого веса такая система не имеет, потому что составляться она должна
реальными экспертами, которые понимают суть проблемы.

 

Так ли оно все важно?

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

 

INFO

Истинные корни создания единой классификации багов и их контроля – это
Unix Known Problem List, Internal Sun Microsystems Bug List, каталоги
служб реагирования на компьютерные инциденты CERT ранних версий.

Список «междоусобной» совместимости систем классификаций:

CVE: ISS, BID, Secunia, SecurityTracker, OSVDB
BID: CVE, Bugtraq, ISS, Secunia, SecurityTracker, OSVDB
ISS: CVE, BID, Secunia, SecurityTracker, OSVDB
Secunia: CVE, OSVDB
SecurityTracker: CVE, OSVDB, Nessus
Nessus: CVE, BID, OSVDB
OSVDB: CVE, BID, Secunia, SecurityTracker, ISS, Nessus, Snort

 

Политика разглашения информации об уязвимости

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

 

Недокументированные уязвимости

В настоящее время эксперты мозгуют над включением вектора
«недокументированные уязвимости» в одну из метрик. Этот параметр имеет высокое
значение. В недалеком будущем мы сможем лицезреть строку «undercover
vulnerabilities» – вероятно, возможные к исполнению. На сайте, посвященном
развитию метрик информационной безопасности (securitymetrics.org/content/Wiki.jsp)
вывешено публичное обращение по поводу того, как и каким образом исчислять этот
параметр. Все желающие могут отправить туда свои предложения.

xakep.ru

под ударом пользователи / Positive Technologies corporate blog / Habr

В 70% веб-сайтов есть критически опасные уязвимости, позволяющие злоумышленникам получать доступ к сайту и причинять серьёзные неприятности не только его владельцу, но и многочисленным пользователям. По средствам разработки самыми дырявыми оказались в 2015 году приложения на Java, значительно возросла доля ресурсов с уязвимостями высокой степени риска на базе серверов Microsoft IIS. При этом использование автоматизированного анализатора исходного кода позволяет выявить в 3 раза больше опасных уязвимостей, чем ручные методы анализа.

Такие выводы содержатся в исследовании компании Positive Technologies на основе статистики, собранной в ходе работ по анализу защищенности веб-приложений в 2015 году. Сравнение с данными аналогичных исследований 2014 и 2013 годов дает возможность оценить динамику развития современных веб-приложений с точки зрения ИБ. В данной статье представлены основные результаты исследования.

Источники и методика

Ежегодно специалисты Positive Technologies изучают около 250—300 веб-приложений в рамках различных работ, начиная от инструментального сканирования и заканчивая анализом исходного кода. По итогам выполненных проектов в 2015 году было выделено 30 веб-приложений, для которых проводился углубленный анализ с наиболее полным покрытием проверок. При этом учитывались только те уязвимости, которые были подтверждены путем проведения проверок на тестовом стенде.

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

В настоящей статистике приведены только уязвимости, связанные с ошибками в коде и конфигурации веб-приложений. Уязвимости классифицировались согласно угрозам по WASC TC v. 2, за исключением категорий Improper Input Handling и Improper Output Handling, поскольку они реализуются в рамках множества других атак. Степень риска уязвимостей оценивалась согласно CVSS v. 2.

Исследованные приложения принадлежали компаниям, представляющим телекомы (23%), промышленность (20%), СМИ (17%), IT-компании (17%), финансы (13%) и государственные организации (10%).

Большинство веб-приложений, вошедших в выборку, разработаны на Java (43%) и PHP (30%), также встречались приложения, созданные с использованием технологий ASP.NET, Perl, ABAP, 1С и других. Приложения работали под управлением серверов Nginx (34%), Microsoft IIS (19%), Apache Tomcat (14%) и WebLogic (14%), а также под Apache и SAP NetWeaver Application Server. Примерно половина исследованных ресурсов (53%) представляли собой продуктивные системы, уже доступные пользователям через интернет, вторую половину составляли тестовые площадки, находящиеся в процессе разработки или приемки в эксплуатацию.

Самые популярные уязвимости

Недостатки как минимум среднего уровня риска были обнаружены во всех исследованных приложениях. При этом в 70% рассмотренных систем были обнаружены критически опасные уязвимости. В течение последних трех лет доля таких систем растет: в 2014 году их было 68%, в 2013 – только 61%.

Большинство исследованных приложений позволяют атаковать пользователей. В коде 80% ресурсов обнаружена уязвимость среднего уровня риска «Межсайтовое выполнение сценариев» (Cross-Site Scripting, XSS). В результате эксплуатации данной уязвимости злоумышленник может внедрить в браузер пользователя произвольные HTML-теги, включая сценарии на языке JavaScript и других языках, и таким образом получить значение идентификатора сессии атакуемого и совершить иные неправомерные действия, например фишинговые атаки.

На втором месте — утечка информации (Information Leakage): уязвимость обнаружена в каждом втором веб-приложении. 47% веб-сайтов также содержат уязвимости, связанные с отсутствием защиты от подбора учетных данных (Brute Force). Наиболее распространенным недостатком высокого уровня риска в 2015 году стала уязвимость «Внедрение внешних сущностей XML» (XML External Entities). Уязвимость позволяет злоумышленнику получить содержимое файлов, расположенных на атакуемом сервере, либо совершать запросы в локальную сеть от имени атакуемого сервера.

Средства разработки: Java не лучше PHP

В исследованиях прошлых лет PHP-приложения как правило были более уязвимы, чем системы, разработанные с помощью ASP.NET и Java. Однако на сегодняшний день картина изменилась: 69% Java-приложений подвержены критически опасным уязвимостям, а для PHP-систем данный показатель составил 56%, что ниже уровня 2013 года на 20%.

Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.

Уязвимость «Межсайтовое выполнение сценариев» оказалась наиболее распространенной для всех языков программирования. Доля приложений, подверженных уязвимости «Внедрение операторов SQL», сократилась по сравнению с 2014 годом: тогда уязвимость была выявлена в 67% веб-ресурсов, разработанных на PHP, а сейчас встречается только в 22%.

Дырявые сервера на Microsoft IIS

Доля ресурсов с уязвимостями высокой степени риска на базе Microsoft IIS значительно возросла по сравнению с предыдущими годами и достигла максимального значения. Зато доля уязвимых сайтов под управлением Nginx снизилась (с 86% до 57%), тоже самое с Apache Tomcat (с 60 до 33%).

Веб-приложения с уязвимостями высокой степени риска (по типу веб-сервера)

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

Сайты банков и IT-компаний под угрозой

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

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

Рабочие системы защищены ненамного лучше тестовых

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

Максимальный уровень риска обнаруженных уязвимостей для тестовых и продуктивных систем (доли уязвимых систем)

Анализ исходного кода лучше выявляет опасные уязвимости

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

Доли систем с уязвимостями разной степени риска по методу тестирования

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

Среднее количество обнаруженных уязвимостей на одну систему

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

Среднее количество выявленных уязвимостей определенного уровня риска на одну систему разными методами

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

В целом полученные данные свидетельствуют о необходимости регулярно проводить работы по анализу защищенности веб-приложений. Важно осуществлять такой анализ на всех стадиях разработки, а также регулярно (например, дважды в год) в процессе эксплуатации систем. Кроме того, приложения, уже находящихся в эксплуатации, нуждаются в эффективной защите от атак: более половины таких ресурсов (63%) оказались подвержены критически опасным уязвимостям. Эти недостатки могут привести не только к разглашению важных данных, но и к полной компрометации системы, либо выводу ее из строя. Для защиты от таких атак рекомендуется применять межсетевые экраны уровня приложений.

Полный текст исследования читайте на www.ptsecurity.ru/research/analytics/

habr.com

Автоматический поиск уязвимостей — «Хакер»

Ты наверное до сих пор думаешь, что хакеры ищут уязвимости в программных
продуктах в ручную, постоянно смотря в исходный код или ручками вставляя
спецсимволы в переменные скриптов? Ты глубоко ошибаешься, мой дорогой друг.
Существует масса пауков сканеров и вспомогательных программ, которые позволяют
по максимуму сократить время исследования. Конечно, многие из них стоят кучу
денег. поэтому достать их проблематично (хотя вполне реально, те же Xspider,
Nessus), другие же не обладают нужной функциональностью. Но всегда есть золотая
середина. Сейчас я поведаю о очень полезных бесплатных программках которые
окажут отличную помощь взломщику, а также затронем тему локального поиска
уязвимостей в исходниках вебскриптов.

RPVS — во Франции также есть хакеры

Платформа: Windows
Ссылка:
http://81.57.125.106/~slythers/rpvsinstall.exe

Скромную заметку о этой программе я на днях отыскал на одном элитном
международном хакерском форуме. Программа однозначно из класса Must Have. Тем
более, что софтина имеет как консольный, так и графический интерфейс. Полное ее
название — Remote PHP Vulnerability Scanner. Этот сканер затачивался под
удаленное исследование сайтов написанных на PHP. Программа способна находить
такие уязвимости: XSS, SQL-Injection, уязвимости подключения файлов функциями
include() и fopen() и раскрытия инсталляционного пути. Программа работает как с
GET, так и POST запросами. Имеет несколько режимов работы и отличную скорость
сканирования. Принцип ее работы состоит в полном собрании линков с сайта, после
чего подставляют спецсимволы в переменные и проводится анализ на показанных PHP
ошибках и сигнатурах. Протестировав ее на одном из небольших сайтов, я получил
подробный отчет о найденных уязвимостях.

Rapport on http://test3.ru/

Number of made request: 24
vuln include: 0
vuln xss: 12
err fopen: 0
err inc: 0
err sql: 0
—————————————————-
Vuln XSS :
/?year=2006&month=02&day=6941337<a>%22%27
/?year=6941337<a>%22%27&month=01
/?year=6941337<a>%22%27&month=02&day=05
/?year=2006&month=6941337<a>%22%27&day=05
/?year=6941337<a>%22%27&month=03
/?year=6941337<a>%22%27&month=02
/?year=6941337<a>%22%27&month=12

Vuln SQL :
/?id=6941337<a>%22%27
/?id=15&c=6941337<a>%22%27
—
Видишь, неплохой отчет. Автоматизация — отличный процесс, который неплохо
экономит время и нервы. Да, кстати, в сети есть вполне компилируемые исходники
этой чудо программы —
http://81.57.125.106/~slythers/rpvsv1.3-src.rar.

В некоторых случаях, когда масштабное сканирование не удается произвести, работу
можно полуавтомазировать с помощью такого софта как Mini-Browser (http://www.aignes.com)
и Advanced HTTP Header Constructor 1.2 (http://www.ru24-team.net).
Программы умеют многое и в любом случае тебе понадобятся, Mini-Browser позволяет
подделывать POST/GET запросы и кукисы, а также вытаскивать все ссылки на
странице. В программу встроен браузер (на движке ИЕ), что делает работу еще
удобнее. Ну а эстеты могут посмотреть на других вкладках исходник или лог
Клиент-Сервер. Advanced HTTP Header Constructor работает с HTTP-заголовками,
позволяет составлять/подделывать/отсылать POST и GET заголовки, а также многое
другое. Для установки нужен свежий Framework.

Acunetix Web Vulnerability Scanner 3 — Достойная замена XSpider

Платформа: Windows
Ссылка:

http://www.acunetix.com/vulnerability-scanner/vulnerabilityscanner3.exe

Когда-то просматривая каталог линков с astalavista.box.sk я и наткнулся на
эту программу. Ее описание мне пришлось по вкусу. По своим возможностям она даже
превосходит XSpider. Acunetix Web Vulnerability Scanner — cканер уязвимостей
вэб-сайтов, сканирует как комплексно так и профильно, то есть Cross site
scripting, SQL injection, cgi-test, CRLF Injection, Directory traversal,
Authentication hacking. Также в сканере присутствует очень интересный тип атаки
— Google hacking на определенный сайт. Этот тип атаки использует поисковые
системы для поиска уязвимостей, что очень полезно и оригинально. Сканер также
отлично определяет версии веб-сервера и его модули. Плюс в него встроены
различные перекодировщики и шифровальщик, HTTP снифер и средства подмены
заголовков. Этот софт обязательно должен поселится в джентльменском наборе
хакера. Так что не поленись, скачай и зацени! Плохо лишь одно, как и все
программные продукты подобного рода, этот софт стоит больших денег (1500$). Но
все лечится, защита там слабенькая. Тем более обновление доступно и в
trial-версии. Кто ищет, тот всегда найдет. Я нашел 🙂

Google – Величайший сканер уязвимостей

С помощью поисковых систем, на самом деле, очень удобно искать нужные
уязвимые скрипты. Нужно только вспомнить о эпидемии червячка Santy, который
искал в Google все бажные phpBB форумы. Подробнее о червячке можно почитать
здесь —
http://www.f-securлe.com/v-descs/santy_a.shtml. Также примеры реализации
подобных сканеров ты найдешь на сайте команды AntiSecurity (http://antisec.2×4.ru).
Так что при грамотном написании программы и хорошей уязвимости, хакер получает
контроль над огромным количеством сайтов.

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

RATS — Грубый Инструмент Ревизии для Защиты

Платформа: Windows
Ссылка:
http://www.securesoftware.com/rats/

RATS, Rough Auditing Tool for Security (Грубый Инструмент Ревизии для Защиты)
является утилитой ревизии защиты для C и C ++ кода. RATS просматривает исходный
текст, находя потенциально опасные обращения к функциям. Цель этого инструмента
— не окончательный поиск ошибки, а скорее обеспечение разумной отправной точки
для выполнения ручной ревизий защиты. Мой хороший знакомый уже давно пользуется
данной программой и очень доволен ее результатами. И еще конечно же радует
открытость ее исходного кода.

Также следует обратить внимание на аналогичный софт под названием ITS4 (http://www.securitylab.ru/_tools/its4-1.1.1.tgz).
Этот инструмент командной строки ищет уязвимости C и C ++ кода и работает на
платформах Windows и Unix. Есть еще одна полезная программа из данного класса —
Flawfinder (http://www.dwheeler.com/flawfinder/).
В отличие от ITS4, flawfinder имеет полностью открытое программное обеспечение
(распространяется согласно лицензии GPL).

BofCheck — Buffer Overflow, Environment Variables Overflow/Format String
Vulnerabilities Binary Tester

Платформа: FreeBSD
Ссылка: http://oc192.1afm.com/

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

Qaudit — Perl приходит на помощь

Оказывается классные вещи можно написать на интерпретируемом языке Perl.
Qaudit.pl — сценарий для быстрой ревизии C и C ++ исходных файлов на наличие
переполнения буфера, ошибок форматной строки, запросов исполняемых вызовов,
переменных среды, и разных функций, которые часто имеют проблемы защиты. Лично я
не ожидал от скрипта таких возможностей 🙂 Кстати, на Perl написано множество
полезных программ, таких как cgi-сканеры, эксплоиты, и даже IDS системы!
Скачивай скриптик от сюда —

http://www.SecurityLab.ru/_exploits/other/qaudit.txt.

Между прочим

Что касается глобальной автоматизации, то автоматизировать можно все. Но
нужно ли это? Не всегда автоматизация помогает, так что ты сам должен решать
каждый раз как действовать. В статье я специально не рассмотрел популярный софт,
такой как XSpider, Hydra и им подобные, о них многие знают, да и писать бы
пришлось целую книгу. Более подробно о способах внутреннего обследования системы
можешь почитать в моей статье «Демократичный
хостинг».

xakep.ru

Поиск уязвимостей на сайте 2017

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

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

Содержание статьи:

Поиск уязвимостей на сайте

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

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

Теперь рассмотрим что нужно делать на каждом из этапов и какие инструменты для этого нужно использовать. Лучше не устанавливать все эти программы отдельно, а использовать уже готовую среду для тестирования на проникновение — Kali Linux. Это специально подготовленный дистрибутив Linux, который уже содержит все необходимые программы. Так вам не придется ничего устанавливать. Вы можете запускать систему из флешки или же установить Kali Linux на жесткий диск.

Разведка

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

nmap — это один из самых популярных инструментов для сканирования сетей. С помощью него вы можете посмотреть какие сервисы запущены на сервере веб-сайта, какие порты они используют их версии, и даже версию операционной системы. Чтобы посмотреть открытые порты на своей машине выполните такую команду в терминале Kali Linux:

nmap -sS 192.168.91.249

Здесь 192.168.91.249 — это ip адрес вашего сайта. Это команда только выведет открытые порты и названия сервисов. Вы можете получить более подробную информацию, например, уже на этом этапе можно собрать много информации о системе. Например, здесь вы можете видеть, что на машине запущен SSH сервер, веб-сервер, службы обмена файлами Samba и прокси сервер на порту 3128. Все они могут быть потенциально уязвимы.

Сканер Nmap позволяет копнуть глубже, с помощью более интенсивного сканирования. Для этого используйте опцию -A:

nmap -A 192.168.91.62

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

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

• whois — с помощью этого сервиса вы можете узнать общедоступную информацию о домене, регистратора, владельца и другую контактную информацию;
• recon-ng — полезный инструмент для анализа, который поставляется вместе с Kali Linux;
• Maltego Chlorine — это очень популярный инструмент с открытым исходным кодом, предназначенный для сбора информации с открытых источников;
• Netcraft — полезный инструмент, позволяющий найти поддомены сайта;
• hackertarget.com/reverse-ip-lookup — позволяет узнать какие еще сайты работают на вашем ip адресе.

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

Сканирование

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

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

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

WPScan — это проект с открытым исходным кодом, написанный на Ruby специально для сканирования WordPress. Он очень прост в использовании и может быть полезным для сайтов, которые используют большое количество плагинов или не обновляются. Утилите не нужен исходный код, она выполняет сканирование удаленно.

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

Burp Suite — это очень мощная программа для поиска уязвимостей на сайте или в веб приложениях. Этот инструмент работает только через веб-браузер. Утилита позволяет проверить все формы, которые есть на сайте, проверить отправку разных заголовков, посмотреть ответы и запросы браузера, выполнить активное сканирование URL, выполнить статический анализ кода JavaScript, а также выполнить поиск XSS уязвимостей на сайте. Это отличный инструмент, но он может показаться сложным.

https://youtu.be/M_h_absC5yE

SQLMap — программа для поиска sql уязвимостей сайта. Вы можете  найти все возможные места, где могут быть выполнены SQL инъекции. Например, если вы предполагаете, что в параметре id может быть sql инъекция, используйте такую команду:

sqlmap -u http://example.com/?id=1 -p id

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

sqlmap --dbms=MySQL -u http://example.com/?id=1 -p id

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

Эксплуатация

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

• SQLMap — очень эффективный инструмент для поиска sql уязвимостей и их эксплуатации;
• Burp Suite — инструмент для поиска XSS уязвимостей и эксплуатации;
• Metasploit — эксплуатация уязвимостей в системе.

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

Исправление

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

Выводы

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

losst.ru