Систематизация знаний по пентесту: от теории уязвимостей до профессионального репортинга

Фундаментальное понимание природы уязвимостей — это то, что отличает профессионального исследователя безопасности от оператора автоматизированных сканеров (так называемого script kiddie). Практический опыт эксплуатации дает понимание «как» взломать систему, но для качественного аудита, разработки надежных методов защиты и составления профессиональных отчетов необходимо точно знать «почему» эта уязвимость вообще существует.

Любая программная система — это конечный автомат, который принимает данные, обрабатывает их по заложенным правилам и выдает результат. Уязвимость возникает в тот момент, когда злоумышленник находит способ перевести этот автомат в непредусмотренное состояние. На фундаментальном уровне подавляющее большинство брешей в безопасности можно разделить на три крупные категории: нарушения работы с памятью, смешение плоскостей данных и управления, а также изъяны в бизнес-логике.

Нарушения работы с памятью: Переполнение буфера

Переполнение буфера (Buffer Overflow) — это классическая уязвимость, возникающая из-за отсутствия контроля за границами выделенной памяти при записи данных. Несмотря на развитие современных механизмов защиты (ASLR, DEP/NX, Stack Canaries), понимание этой уязвимости критически важно, так как она иллюстрирует базовые принципы взаимодействия программного обеспечения с архитектурой процессора.

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

* Текст (Text): Исполняемый машинный код программы (обычно доступен только для чтения). * Данные (Data/BSS): Глобальные и статические переменные. * Куча (Heap): Динамически выделяемая память (например, через функцию malloc в C). * Стек (Stack): Структура данных, работающая по принципу LIFO (последним пришел — первым ушел). Используется для хранения локальных переменных, аргументов функций и информации о потоке выполнения.

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

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

Функция strcpy копирует символы из user_input в buffer до тех пор, пока не встретит нулевой байт (\0). Если длина пользовательского ввода превышает размер выделенного буфера (в данном случае ), функция продолжит запись за пределами массива buffer.

Поскольку стек растет в сторону младших адресов, а запись в массив идет в сторону старших, избыточные данные перезапишут соседние участки памяти. Главная цель атакующего — добраться до сохраненного адреса возврата (EIP в 32-битной архитектуре x86 или RIP в 64-битной) и заменить его на адрес своего вредоносного кода (шеллкода).

!Интерактивная визуализация переполнения буфера стека

В профессиональном репортинге при описании таких уязвимостей важно указывать не только факт падения программы (Denial of Service), но и потенциал для удаленного выполнения кода (RCE — Remote Code Execution), что делает уязвимость критической.

Смешение плоскостей данных и управления: Инъекции

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

Фундаментальная причина любой инъекции заключается в нарушении принципа разделения плоскости управления (control plane) и плоскости данных (data plane). В безопасной системе команды (код) и данные (пользовательский ввод) должны передаваться по независимым каналам. Однако во многих технологиях они передаются в виде единого текстового потока, который затем разбирается интерпретатором.

> Инъекция происходит тогда, когда интерпретатор ошибочно принимает неструктурированные пользовательские данные за исполняемые инструкции.

Самый известный пример — SQL-инъекция (SQLi). Веб-приложения часто формируют запросы к базе данных путем простой конкатенации (склеивания) строк:

```php _POST['user'] . "' AND password = '" . \geq\geq\geq$ 100 (Да) | 100 долл. | | Вычитание: 100 - 100 | | 0 долл. | | | Вычитание: 0 - 100 | -100 долл. | | Зачисление получателю | Зачисление получателю | Атакующий перевел 200 долл., имея 100 долл. |

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

Систематизация для профессионального репортинга

При составлении отчета о тестировании на проникновение (пентест-репорта) критически важно классифицировать найденные уязвимости по их фундаментальной природе. Это помогает заказчику не просто «заткнуть дыру», а исправить архитектурный изъян.

Если вы нашли XSS, не пишите просто «найдена XSS, фильтруйте ввод». Объясните, что приложение смешивает данные и код в браузере клиента, и порекомендуйте использовать контекстно-зависимое экранирование или Content Security Policy (CSP). Если найден IDOR, укажите на необходимость внедрения матриц контроля доступа (RBAC/ABAC) на уровне бизнес-логики, а не просто скрытия идентификаторов.

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

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

Для профессионального пентестера веб-приложение — это не просто набор страниц, а сложный конвейер обработки данных. Браузер клиента формирует HTTP-запрос, балансировщик нагрузки передает его на веб-сервер, backend-приложение обрабатывает бизнес-логику, обращаясь к базе данных, и возвращает результат. На каждом этапе этого конвейера данные могут быть интерпретированы неверно.

SQL-инъекции: манипуляция синтаксическим деревом

SQL-инъекция (SQL Injection, SQLi) остается одной из самых критических угроз безопасности. Как мы обсуждали ранее, ее фундаментальная причина — конкатенация (склеивание) строк при формировании запроса к базе данных.

Когда интерпретатор СУБД (например, PostgreSQL или MySQL) получает текстовую строку запроса, он проходит этап лексического и синтаксического анализа, строя абстрактное синтаксическое дерево (AST). Если пользовательский ввод не экранирован, атакующий может внедрить управляющие символы (кавычки, точку с запятой), которые заставят парсер перестроить это дерево.

Рассмотрим классический пример обхода аутентификации. Допустим, backend выполняет следующий запрос:

Если атакующий введет в поле username строку admin' --, итоговый запрос, отправленный в базу данных, примет вид:

json { "alg": "none", "typ": "JWT" } ``

Если библиотека проверки JWT на сервере не настроена на жесткое требование конкретного алгоритма, она примет токен с alg: none как валидный, предоставив взломщику права администратора.

Логические ошибки: IDOR в контексте авторизации

Как упоминалось в предыдущей статье, Insecure Direct Object Reference (IDOR) — это логическая ошибка. В контексте аутентификации она часто проявляется при сбросе пароля.

Представьте функцию восстановления пароля, которая отправляет на почту ссылку вида: https://site.com/reset-password?user_id=8452&token=abc123

Если при переходе по ссылке сервер проверяет только валидность токена abc123, но не проверяет, принадлежит ли этот токен пользователю 8452, возникает критическая брешь. Атакующий может запросить сброс пароля для своего аккаунта (получив валидный токен), а затем использовать этот токен, подставив в URL user_id=1` (администратор).

Систематизация для профессионального репортинга

При составлении отчета о веб-пентесте необходимо транслировать технические находки в бизнес-риски. Заказчику (часто это менеджмент, а не только разработчики) важно понимать последствия.

Если вы обнаружили Stored XSS, опишите цепочку атаки: «Уязвимость позволяет злоумышленнику внедрить код на главную страницу портала. При посещении страницы администратором, скрипт автоматически создаст нового пользователя с максимальными правами, что приведет к полной компрометации системы».

В рекомендациях по устранению всегда предлагайте эшелонированную защиту (Defense in Depth). Для XSS это не только экранирование вывода (контекстно-зависимый Output Encoding), но и внедрение строгой политики защиты контента (Content Security Policy, CSP), которая запретит выполнение inline-скриптов и загрузку ресурсов со сторонних доменов.

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

В предыдущих материалах мы разобрали уязвимости веб-приложений, возникающие из-за смешения плоскостей данных и управления, а также из-за отсутствия состояния (stateless) в протоколе HTTP. Однако веб-приложения не существуют в вакууме. Они опираются на сетевую инфраструктуру и службы каталогов, которые имеют собственные фундаментальные архитектурные изъяны.

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

Уязвимости канального уровня: иллюзия локальной безопасности

Локальная сеть (LAN) исторически считалась безопасной зоной. Архитектура Ethernet подразумевает, что все устройства в одном широковещательном домене доверяют друг другу. Масштаб проблемы можно описать математически. В полносвязной топологии или едином широковещательном домене количество возможных связей между узлами вычисляется по формуле:

Где — количество связей, а — количество узлов в сети.

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

ARP-spoofing: отравление кэша и перехват трафика

Address Resolution Protocol (ARP) — это протокол, связывающий IP-адреса сетевого уровня с MAC-адресами канального уровня. Когда компьютеру «А» нужно отправить пакет компьютеру «Б», он знает его IP-адрес, но для формирования Ethernet-кадра ему нужен физический MAC-адрес.

Компьютер «А» отправляет широковещательный запрос: «Кто имеет IP 192.168.1.1? Сообщите свой MAC». Легитимный владелец отвечает: «Это я, мой MAC — 00:11:22:33:44:55». Узел «А» сохраняет эту связку в свой ARP-кэш для будущих обращений.

Фундаментальная уязвимость ARP заключается в отсутствии аутентификации и проверке состояния. Узел примет ARP-ответ, даже если он не отправлял запрос. Это позволяет реализовать атаку ARP-spoofing (или ARP Poisoning).

Злоумышленник (например, с IP 192.168.1.30 и MAC CC:CC:CC:CC:CC:CC) непрерывно отправляет поддельные ARP-ответы жертве (192.168.1.5) и шлюзу по умолчанию (192.168.1.1). Он сообщает жертве, что MAC-адрес шлюза — это CC:CC:CC:CC:CC:CC, а шлюзу сообщает, что MAC-адрес жертвы — тоже CC:CC:CC:CC:CC:CC.

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

VLAN hopping: обход сетевой сегментации

Для разделения больших сетей на изолированные сегменты используются Virtual Local Area Networks (VLAN). Стандарт 802.1Q добавляет в Ethernet-кадр специальный тег (4 байта), указывающий принадлежность к конкретному VLAN.

Атака VLAN hopping позволяет злоумышленнику из одного сегмента (например, гостевого) отправить трафик в другой (например, в сеть бухгалтерии), минуя маршрутизатор и списки контроля доступа (ACL). Существует два основных метода:

| Метод атаки | Механизм эксплуатации | Условия для успеха | | :--- | :--- | :--- | | Switch Spoofing | Атакующий отправляет пакеты протокола Dynamic Trunking Protocol (DTP), притворяясь коммутатором. Порт переходит в режим trunk, давая доступ ко всем VLAN. | Порт коммутатора настроен в режим dynamic desirable или dynamic auto. | | Double Tagging | Атакующий добавляет в кадр сразу два тега 802.1Q. Первый коммутатор снимает внешний тег и пересылает кадр дальше, где второй коммутатор читает внутренний тег и отправляет пакет в целевой VLAN. | Атакующий должен находиться в Native VLAN (обычно VLAN 1), который передается без тегирования между коммутаторами. |

!Схема атаки VLAN Hopping методом двойного тегирования

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

Атаки на Active Directory: компрометация службы каталогов

Поднявшись с канального уровня на уровень приложений, пентестер в корпоративной среде неизбежно сталкивается с Active Directory (AD) — службой каталогов от Microsoft. AD является центральной нервной системой большинства корпораций, управляя аутентификацией, правами доступа и политиками безопасности.

В основе аутентификации AD лежит протокол Kerberos. В отличие от простых проверок логина и пароля, Kerberos использует систему билетов (tickets), чтобы пользователи не передавали свои пароли по сети.

Процесс легитимной аутентификации выглядит так:

Kerberoasting: извлечение хешей сервисных аккаунтов

Уязвимость архитектуры Kerberos кроется на четвертом шаге. Любой аутентифицированный пользователь в домене (даже с минимальными правами) имеет законное право запросить TGS для любого зарегистрированного в AD сервиса (Service Principal Name, SPN).

Атака Kerberoasting эксплуатирует эту легитимную функцию:

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

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

Систематизация для профессионального репортинга

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

Пример описания риска для ARP-spoofing: «В сегменте сети бухгалтерии отсутствует защита от подмены ARP-ответов. Это позволяет любому сотруднику или вредоносному ПО, попавшему на ПК в этом сегменте, незаметно перехватывать трафик коллег. В ходе тестирования был продемонстрирован перехват сессионных файлов, что дает возможность злоумышленнику получить доступ к финансовой системе 1С без ввода логина и пароля».

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

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

Успешная эксплуатация уязвимостей на внешнем периметре или в корпоративной сети (например, через ARP-spoofing или атаки на Active Directory, которые мы разбирали ранее) обычно дает пентестеру первичный доступ к целевой системе. Однако этот доступ почти всегда ограничен правами рядового пользователя или сервисного аккаунта. Чтобы получить полный контроль над сервером, извлечь хеши паролей из памяти или отключить средства защиты (EDR/Антивирус), необходимо повысить привилегии до уровня root (в Linux) или SYSTEM (в Windows).

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

Архитектура изоляции: кольца защиты и системные вызовы

Современные процессоры архитектуры x86 реализуют аппаратную концепцию иерархических колец защиты (Protection Rings). Операционные системы традиционно используют только два из них:

!Схема архитектуры колец защиты операционной системы

Единственный легитимный способ для программы из Ring 3 запросить действие у Ring 0 (например, прочитать файл или отправить сетевой пакет) — это системный вызов (syscall). Системные вызовы работают как строго контролируемые шлюзы. Ядро принимает запрос, проверяет права пользователя и, если всё корректно, выполняет операцию от своего имени, возвращая результат.

Уязвимости локального повышения привилегий (Local Privilege Escalation, LPE) возникают, когда злоумышленник находит способ передать через этот шлюз специально сформированные данные, которые заставляют ядро выполнить вредоносный код в контексте Ring 0.

Нарушение работы с памятью в ядре: Use-After-Free

Один из самых распространенных и опасных классов уязвимостей в ядре — это Use-After-Free (UAF, использование после освобождения). В отличие от переполнения буфера, где данные выходят за границы выделенного участка, UAF эксплуатирует нарушение жизненного цикла объектов в памяти.

Механика уязвимости строится на трех этапах:

> Аналогия из жизни: Вы сняли номер в отеле (выделение памяти) и получили ключ (указатель). Выписавшись из отеля (освобождение), вы случайно оставили ключ себе. В номер заселяется другой человек и оставляет там свои вещи (вредоносная нагрузка). Вы возвращаетесь, открываете дверь старым ключом и получаете доступ к чужим вещам (использование после освобождения).

!Интерактивная симуляция уязвимости Use-After-Free

Логические ошибки: драйверы и пространства имен

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

Уязвимости минифильтров Windows

В Windows существует архитектура драйверов-минифильтров (Mini Filters), которые перехватывают запросы ввода-вывода (IRP-пакеты) к файловой системе. Они используются антивирусами для сканирования файлов на лету или облачными хранилищами для синхронизации.

Яркий пример — уязвимость CVE-2024-30085 в драйвере cldflt.sys (Windows Cloud Files Mini Filter, часть Microsoft OneDrive). Драйвер некорректно обрабатывал точки повторной обработки (Reparse Points — механизм, похожий на символические ссылки). Злоумышленник мог создать специально сформированную точку повторной обработки, заставив драйвер, работающий в Ring 0, выполнить манипуляции с объектами в памяти (через механизм Windows Notification Facility), что приводило к созданию примитива произвольной записи в память ядра и, как следствие, к получению прав SYSTEM.

Иллюзия изоляции: User Namespaces в Linux

В Linux контейнеризация (Docker, Kubernetes) строится на механизмах namespaces (пространства имен) и cgroups. Пространства имен изолируют процессы друг от друга.

Функция User Namespaces позволяет непривилегированному пользователю создать изолированное пространство, внутри которого он будет иметь права root. Это задумывалось для безопасности (чтобы контейнеры работали без реальных прав root на хосте). Однако это открыло огромную поверхность атаки: непривилегированный пользователь внезапно получил доступ к системным вызовам и функциям ядра, которые раньше были ему недоступны.

Примером служит уязвимость CVE-2023-32629 в подсистеме OverlayFS (файловая система, объединяющая несколько директорий в одну, часто используемая в Docker). Из-за расхождений в реализации OverlayFS, пользователь внутри своего пространства имен мог скопировать исполняемый файл и назначить ему атрибут cap_setuid (разрешение на смену идентификатора пользователя). При выполнении этого файла вне пространства имен ядро некорректно интерпретировало права, позволяя локальному пользователю выполнить код с привилегиями реального root.

Систематизация для профессионального репортинга

При написании отчета о пентесте обнаружение уязвимости локального повышения привилегий требует правильного позиционирования. Технический специалист понимает ценность эксплойта для CVE-2024-50264 (уязвимость в подсистеме AF_VSOCK ядра Linux, приводящая к разыменованию нулевого указателя и состоянию гонки), но бизнесу нужно объяснить последствия.

Пример описания риска в отчете: «На сервере баз данных выявлена уязвимость ядра ОС (CVE-2023-32629). Несмотря на то, что сервер не имеет уязвимостей на внешнем периметре, компрометация любой непривилегированной учетной записи (например, через фишинг сотрудника техподдержки) позволит злоумышленнику мгновенно получить полный контроль над сервером. Это приведет к возможности отключения систем мониторинга (EDR), скрытной установке руткитов и беспрепятственному копированию клиентских баз данных в обход всех настроенных политик доступа».

Архитектурные рекомендации по устранению:

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

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

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

Сетевая разведка: механика работы Nmap

Любой аудит внешнего периметра или внутренней корпоративной сети начинается с инвентаризации активов. Инструмент Nmap (Network Mapper) де-факто является индустриальным стандартом для решения этой задачи. Это не просто сканер портов, а сложный анализатор сетевых протоколов, работающий на сетевом и транспортном уровнях модели OSI (Layer 3 и Layer 4).

Фундаментальный принцип работы Nmap строится на анализе ответов стека TCP/IP целевой системы на специфически сформированные пакеты. Наиболее популярный метод сканирования — TCP SYN scan (флаг -sS), также известный как «полуоткрытое» сканирование.

Вместо того чтобы устанавливать полноценное соединение с сервером (которое обязательно будет зафиксировано в логах приложения), Nmap инициирует только первый этап стандартного тройного рукопожатия (Three-way handshake):

Помимо базового сканирования, профессионалы используют комбинацию флагов для глубокой энумерации. Например, команда nmap -sC -sV -T4 10.10.116.89 выполняет сразу несколько критически важных действий. Флаг -sV активирует механизм Banner Grabbing — Nmap отправляет серии запросов к открытым портам и сравнивает ответы со своей базой сигнатур, чтобы точно определить название и версию запущенного сервиса (например, Apache 2.4.41 вместо абстрактного «HTTP»). Флаг -sC запускает безопасные скрипты из Nmap Scripting Engine (NSE), которые могут автоматически обнаружить анонимный доступ к FTP или уязвимости в конфигурации SSL.

Анализ прикладного уровня: Burp Suite как MitM-прокси

Если Nmap исследует инфраструктуру снаружи, то для тестирования безопасности веб-приложений (Layer 7) требуется инструмент, способный разбирать сложную логику HTTP/HTTPS-трафика. Здесь на сцену выходит Burp Suite.

Архитектурно Burp Suite работает по принципу Man-in-the-Middle (MitM, «человек посередине»). Он запускается как локальный прокси-сервер на машине пентестера. Чтобы перехватывать зашифрованный HTTPS-трафик, пентестер устанавливает корневой сертификат (CA) Burp Suite в доверенное хранилище своего браузера.

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

!Схема работы Burp Suite в режиме прокси: инструмент встраивается между клиентом и сервером, перехватывая и расшифровывая трафик

Именно этот механизм позволяет эксплуатировать уязвимости, которые мы разбирали ранее:

| Инструмент | Уровень модели OSI | Основная задача | Типичные выявляемые уязвимости | | :--- | :--- | :--- | :--- | | Nmap | Сетевой и транспортный (L3/L4) | Обнаружение хостов, сканирование портов, идентификация версий ОС и сервисов | Открытые порты управления (RDP, SSH), устаревшие версии ПО, анонимный доступ | | Burp Suite | Прикладной (L7) | Перехват, модификация и фаззинг HTTP/HTTPS-трафика | XSS, SQLi, IDOR, CSRF, ошибки бизнес-логики |

Квантификация рисков: стандарт CVSS

Когда уязвимость найдена, ее необходимо объективно оценить. Сказать заказчику «это очень опасный баг» — непрофессионально. В индустрии кибербезопасности для стандартизации оценки используется CVSS (Common Vulnerability Scoring System).

CVSS представляет собой фреймворк, который оценивает уязвимость по набору метрик и выдает итоговый балл по шкале, где . Текущая актуальная версия стандарта — CVSS v4.0.

Базовая оценка (Base Score) формируется из метрик, которые отражают неотъемлемые характеристики уязвимости:

> Пример из практики: SQL-инъекция в форме авторизации веб-сайта, позволяющая выгрузить базу данных пользователей, получит оценку около 9.8 (Критическая), так как вектор атаки — сетевой, привилегии не требуются, а влияние на конфиденциальность — высокое.

!Интерактивный калькулятор базовой оценки CVSS v4.0 — позволяет понять, как вектор атаки и требуемые привилегии влияют на итоговый рейтинг критичности уязвимости

Профессиональный репортинг: структура и бизнес-ценность

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

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

1. Краткое резюме (Executive Summary)

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

Плохо: «На сервере 10.0.5.15 найдена CVE-2023-32629 в OverlayFS, позволяющая сделать LPE до root через user namespaces».

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

2. Методология и ограничения

Раздел для IT-директоров и руководителей службы безопасности. Здесь описывается, какие стандарты применялись (например, OWASP Top 10 для веба или PTES для общего процесса), какие инструменты использовались (Nmap, Burp Suite) и какие ограничения были наложены заказчиком (например, запрет на проведение DDoS-атак или тестирование только в нерабочие часы).

3. Техническое описание уязвимостей

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

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