Глава 14. Безопасность веб служб и служб электронной почты

В этом разделе мы обсудим различные веб протоколы, такие как HTTP и HTTP2, в чём разница между HTTP и HTTP2, их архитектуру, а также их разнообразные функциональные возможности и проблемы безопасности в обоих протоколах.

HTTP, или HyperText Transfer Protocol (протокол пересылки гипертекста), применяется для обмена данными между клиентом и сервером в виде документов HTML (HyperText Markup language, языка разметки гипертекста). Такие документы содержат изображения, тексты, видео- файлы и флеш- файлы. HTTP работает поверх всех имеющихся сетевых уровней и известен в качестве Уровня приложения, а также применяется для передачи всех данных между взаимодействующими сетевыми устройствами.

HTTP был предложен давно в конце 1980-х и в начале 1990-х годов, однако, после видоизменений, его окончательная версия HTTP/1.1 была представлена в 1997 году, которая до сих поря является стандартом версии протокола HTTP. Чтобы больше узнать об истории и разработках HTTP, существует интересный блог, написанный командой Mozilla, пожалуйста, перейдите по этой ссылке.

Типичная архитектура протокола клиент- сервер HTTP отображена на следующей схеме:

На Рисунке 14.1 изображена такая архитектура клиент- сервер совместно с различными компонентами:

Мы ввели термин сервера посредника (прокси); давайте изучим его.

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

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

Всякий передаваемый через Интернет запрос HTTP содержащий огромный блок кодированных сведений, которые обычно включают следующее:

Давайте разберёмся со всем этим запросом HTTP в реальном масштабе времени:

Давайте проанализируем отображаемые Рисунком 14.3 перехваченные запрос и отклик HTTP в приводимой далее таблице:

Таблица 14-1. Анализ запроса и отклика HTTP

Параметры HTTP	Запрос	Отклик
Метод HTTP	GET	200 OK
Версия HTTP	HTTP/1.1	HTTP/1.1
Заголовок HTTP	Со строки №1 по строку №11 представлен весь заголовок запроса	Со строки №1 по строку №13 представлен весь заголовок отклика
Версия HTTP		Со строки №16 до самого конца представлено всё тело отклика

Сейчас, наша предыдущая таблица имеет представленным новое значение, 200 OK. Это некий код отклика HTTP. Итак, давайте взглянем на некоторые прочие коды отклика HTTP и разберёмся с ними:

Несколько десятилетий назад можно было обнаружить, что HTTP/1.1 является одной из наиболее известных технологий взаимодействия с веб- страницами. Однако со временем технологии развивались, а веб- страницы превращались в очень сложные, посредством добавления сценариев автоматизации, флэш- файлов, изображений, видео, GIF- файлов и тому подобного. Это подразумевало передачу гигантского объёма данных по каналу HTTP, что увеличивало сложность и накладные расходы HTTP/1.1 .

Таким образом, в начале 2010-х, Google появилась с неким решением вводя новый протокол, SPDY (произносится как Speedy). Основная цель этого протокола состояла в решении главной проблемы дублирования передаваемых данных, сокращение значения времени отклика сервера за счёт обработки интенсивных нагрузок обмена и RTT (Round-Trip Time, времени прохода в обе стороны). Тем самым, развитие данного протокола установило точку отсчёта эволюции HTTP/2.

Итак, давайте поймём чем HTTP/2 отличается от HTTP/1.1:

Это основные представленные в протоколе HTTP/2 реализации решения проблемы интенсивной нагрузки обмена серверов и медленной передачи через не быстрые подключения TCP. Чтобы узнать больше об HTTP/2, пожалуйстаЮ перейдите по этой ссылке.

Теперь мы изучили HTTP, а также разобрались с тем как вовлекается HTTP/2 и чем он отличается от HTTP/1.1 и давайте двинемся далее к иному классу HTTP - HTTPS.

Теперь, основная проблема с самим протоколом HTTP состоит в том, что передача его данных совершенно не шифруется, что подразумевает, что злоумышленник может красть, изменять или просматривать проходящий между клиентом и его сервером обмен. Для перехвата доступно большое число средств, например, Wireshark, Fiddler, HTTPView и Network Analyzer. Тем не менее, для наилучшего представления, Wireshark наиболее подходящий и дружественный для применения, а потому мы также воспользуемся им для собственных тестов. Давайте продемонстрируем слабости HTTP при помощи Wireshark:

Как показано на Рисунке 14.4, Wireshark перехватил не зашифрованный запрос на регистрацию переданный через канал HTTP без безопасности.

Для предотвращения этого был добавлен другой уровень безопасности путём введения TLS (Transport Layer Security), ранее носившего название SSL (Secure Socket Layer). Теперь давайте поймём это на практической демонстрации:

На данный момент, как это отражено на Рисунке 14.5, включена TLS и немедленно значение URL изменилось с HTTP на HTTPS. Далее давайте проанализируем собственно шаблон запроса и отклика, что видно на рисунке ниже:

Как мы наблюдаем на Рисунке 14.6, все отображаемые запросы и отклики передаются через зашифрованный канал HTTPS, реализованный поверх TLSv1.2. Однако что именно происходит на серверной стороне? Как эти данные становятся зашифрованными? Как осуществляется необходимое рукопожатие? Давайте разберёмся с этим шаг за шагом.

HTTPS это зашифрованный вид протокола HTTP, который запрещает веб- сайтам передавать данные в не зашифрованном формате. Таким образом, он шифрует данные от их просмотра, кражи или изменения через подслушивание, в особенности в общедоступных сетевых средах, таких как открытые и бесплатные Wi-Fi в Старбаксах и аэропортах. Это работает примерно так:

HTTPS содержит сертификат безопасности, имеющий название сертификата SSL или TLS, который указывает, что вебсайт настоящий и безопасный для посещения. Этот сертификат предоставляет дополнительный уровень безопасности через шифрование чувствительных и конфиденциальных данных, таких как номера кредитных/ дебетовых карт, паролей, PIN кодов и OTP. Сертификаты TLS шифруют взаимодействие при помощи инфраструктуры с общедоступным- частным ключами, которые применяют два следующих различных типа ключей для шифрования и дешифрации соответствующего взаимодействия между клиентом и сервером:

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

Как мы видим из Рисунка 14.8, далее имеется последовательность запросов и откликов договаривающихся между клиентом и сервером о безопасном взаимодействии, однако мы сосредоточимся лишь на обмене безопасными пакетами сообщений сертификатов:

Вот, теперь мы разобрались с рукопожатием HTTPS и давайте продемонстрируем на практическом примере применение Wireshark для обмена взаимодействием от браузера клиента и сервера Google, как это показано на следующем снимке экрана:

Итак, как мы наблюдаем на Рисунке 14.9, после обмена всеми такими сообщениями и достижения согласия по применяемой версии протокола и ChangeCipherSpec, обмен по каналу HTTPS производится зашифрованными данными. На данном этапе мы ожидаем что вы открываете все сообщения в Wireshark и глубоко просматриваете эти пакеты для анализа.

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

TTP это сокращение для (Tactics, Techniques, and Procedures, тактик, методы и процедур), которые анализируют поведение цели, готовят план выявления уязвимостей и лазеек в неком приложении и выработки безопасности от таких атак.

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

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

Итак, давайте возьмём в качестве примера для изучения важных функциональных возможностей и демонстрации сканирования уязвимостей Burp Suite, в то время как мы приступим к сканированию на проникновение на платформе Mutillidae. Однако будьте свободны также воспользоваться и прочими доступными в Интернете сценариями и сканерами:

Как показано на Рисунке 14.10, давайте разберёмся со всеми разделами экрана вмешательства Burp Suite, а именно:

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

Как мы наблюдаем на Рисунке 14.13, было выявлено большое число уязвимостей и все они подпадают в категорию топ 10 уязвимостей OWASP (Open Web Application Security Project). Несколько этих уязвимостей мы обсудим в своём следующем разделе, однако мы ожидаем, что при помощи Mutillidae вы изучите и попрактикуетесь со всеми этими уязвимостями. Чтобы изучить полный список категорий OWASP, пожалуйста, проследуйте по следующей ссылке.

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

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

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

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

Следовательно, давайте продемонстрируем как мы можем скомпрометировать страницу регистрации через инъекций SQL:

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

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

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

SELECT username, password from USERS where username = '<username>' and password = '<password>';
 	   

Давайте теперь вставим своё внедрение в наш предыдущий запрос:

SELECT username, password from USERS where username = '1'or'1'='1' and password = '1'or'1'='1';
 	   

Теперь давайте повнимательнее взглянем на свой предыдущий запрос, его поле имени пользователя, 1, сбалансировано со второй цитатой, а этот второй запрос представляет '1'='1, что означает, что если выражение username = 1 не верно, тогда необходимо проверять что '1'='1 это TRUE, что истинно всегда. Тем самым, это подразумевает, что данная проверка на стороне сервера не выполняет подтверждение должным образом, а, следовательно, злоумышленник получил возможность входа в систему и выборки данных из этой базы данных.

Более того, существуют различные типы внедрений SQL, например, основанные на ошибке (error-based), двойного запроса (double query), слепого SQL на основе времени (blind SQL time-based), а также основанного на Булевом равенстве (Boolean=based). Не посчитайте за труд пройтись по каждому из внедрений SQL по данной ссылке и попрактиковаться на доступной бесплатно платформе, скажем, на Mutillidae.

На данный момент мы ознакомились с инъекцией SQL и давайте взглянем на прочие типы важных атак инъекцией.

RCE (сокращение от Remote Code Execution, удалённое выполнение кода), это одна из наиболее опасных уязвимостей во все времена, потому как она позволяет злоумышленнику исполнять команды удалённой системы. Воздействие данной атаки настолько драматично, что злоумышленник может получать полный контроль над машинами через исполнение вредоносного ПО для эксфильтрации конфиденциальных сведений и, посредством выполнения горизонтального смещения, компрометации прочих машин и всего домена. Давайте разберёмся с этим на простой демонстрации:

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

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

Атака XSS обычно происходит когда имеется некое отображаемое на экране сообщение. Например, когда имеется блок сообщения поиска, а пользователь набирает Test, получаемый результат для данного ключевого слова будет отображён обратно на экране, однако если вы присмотритесь повнимательнее, вы обнаружите, что это ключевое слово Test продолжит храниться в самом исходном коде данного приложение, что отображает следующий снимок экрана:

Теперь, как мы наблюдаем на Рисунке 14.19, что если злоумышленник заменит значение этого ключевого слова неким вредоносным сценарием? Давайте разберёмся с этим при помощи классификации XSS:

Имеются три типа атак XSS:

Как показано на Рисунке 14.25, имеются различные типы сценариев XSS, которые внедряются в вебстраницы помимо тегов <script>. В Интернете существует доступными великое множество сценариев XSS для обхода разнообразных фильтров кода или WAF (Web Application Firewalls, межсетевых экранов веб приложений). Не примените воспользоваться также и этими сценариями.

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

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

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

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

Давайте разберёмся с этим при помощи некого примера:

Как мы наблюдаем на Рисунке 14.27, данный сервер не способен обработать столь большое число запросов, тем самым испытывая крушение.

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

Угон сеанса это хорошо известная атака при которой злоумышленник компрометирует учётную запись пользователя через компрометацию его сеанса. Этого можно достичь множеством способов, но наиболее известные методы это простой перебор, инъекции в куки, прослушивание сети и обратное проектирование. Итак, давайте сначала разберёмся что собой представляют сеансы?

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

Такие записи сеанса носят название файлов куки (cookies) и они сохраняются на машине клиента. Такой тип куки носит название куки на основе сохранения (persistent-based).

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

Итак, давайте разберёмся как выглядят куки. Это отображено на снимке экрана ниже:

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

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

 

Угон сеансов посредством XSS

На данный момент мы знакомы с XSS по разделу о них, а потому давайте напрямую перескочим к краже куки:

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

 

Угон сеансов через вмешательство в куки

Подделка куки (Cookie tampering) это атака, при которой злоумышленник в заголовке отклика выполняет манипуляции с параметром cookie выполнившего аутентификацию пользователя для компрометации учётных записей с более высоким уровнем приоритета:

На текущий момент, хотя мы и изучили основные главные на основе сеансов, все возможные атаки нам было бы продемонстрировать крайне затруднительно. Мы ожидаем что вы попрактикуетесь в прочих атаках сеанса, например в простом переборе (brute force) или фиксации сеанса (fixing session). А сейчас давайте перейдём к следующему разделу и ознакомимся с лазейками в почтовой службе.

Email это сокращение для electronic mail (электронной почты), применяется для отправки и получения сообщений в электронном виде. Для отправки или получения электронной почты имеется три основных протокола:

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

Теперь, давайте скомбинируем эти три протокола электронной почты и разберёмся как они работают в реальном масштабе времени:

Как показано на Рисунке 14.36, все три протокола работают совместно для отправки и получения электронных сообщений. Таким образом, на данный момент мы разобрались с основами протоколов электронной почты и давайте посмотрим на слабые места протоколов электронной почты.

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

При помощи утилиты NMAP давайте осуществим сканирование уязвимостей удалённо установленного сервера SMTP с портом 25. Это показано на следующем снимке экрана:

Как мы видим из Рисунка 14.37, а именно, из строк характерных признаков, для удалённого применения доступно много сведений о сервере SMTP, например, Oracle-TNS и JAVA-RMI. Данная глава сосредоточится только на SMTP, однако потратьте время и на их исследование.

Строки и характерным признаками также раскрывают и некоторые имеющиеся команды, такие как HELLO и HELP, однако этот сервер SMTP не уязвим для применений Exim.

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

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

Как можно наблюдать на Рисунке 14.38, злоумышленник вручную подделывает электронное письмо для отправки другому пользователь. Затем, что если злоумышленник отправит созданную вручную полезную нагрузку реверсивного соединения TCP или из соответствующего outlook жертвы создаст C2C (Command and Control Center, Центр команд и контроля) к их внешнему серверу для считывания электронной почты или также и для компрометации машины своей жертвы? Мы оставим вам для упражнений в дальнейшем.

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

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

Фишинг это хорошо известная и распространённая в наши дни атака. Фишинг включает в себя отправку поддельного электронного письма злоумышленника, которое содержит вредоносные ссылки, переправляющие на внешние страницы, такие как фальшивые страницы Amazon или Facebook, либо вредоносных офисных файлов, например, файлов Word, PDF и Excel.

В наши дни такие полезные нагрузки очень распространены и знакомы профессионалам безопасности, однако имеется и иной тип вредоносной полезной нагрузки, которая вручную собирается в виде HTML и применяется для компрометации хэшей NTLM ( New Technology LAN Manager) пользователей домена.

Подобная фишинговая атака очень полезна, ибо жертве даже не приходится открывать такое электронное письмо; достаточно всего лишь одного клика по ней. Когда такая жертва закрывает Outlook и повторно его открывает, злоумышленник имел бы возможность компрометации его хэшей NTLM. Этого можно достигать созданием вручную полезной нагрузки внутри файла Excel, Word или PDF, что мы и продемонстрируем:

На Рисунке 14.42 показано, что WPAD разрешён, а следовательно автоматически сохраняемые учётные данные жертвы немедленно были перехвачены на стороне злоумышленника. Такая атака весьма плодотворна в процессе операций красной команды, в особенности для компрометации хэшей или учётных записей администраторов домена.

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

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

В данной главе мы изучили протоколы взаимодействия веб приложений, такие как HTTP и HTTP2. Также мы взглянули на вызываемые HTTP проблемы и разрешаемые им через введение встраиваемых в HTTP сертификатов SSL/ TLS и мы пришли к новому безопасному протоколу, HTTPS. Также мы изучили разнообразные атаки на веб приложения, например, инъекции SQl, XSS, угон сеансов и переполнение буфера, причём на практических примерах. Другой рассмотренной нами службой была электронная почта и её соответствующие протоколы, уязвимости и атаки на шлюзы.

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