Как взломать файловый сервер

Обновлено: 07.07.2024

Продолжаем рассматривать тематику взлома систем, и давайте поищем еще один способ, как взломать нашу цель. В предыдущих уроках мы с Вами рассматривали некоторые инструменты для сканирования, такие как «nmap» и «nessus».

Сейчас рассмотрим инструмент под названием «Nikto». Этот инструмент предназначен для сканирования уязвимостей веб-приложений. Этот инструмент сканирует сайты на предмет возможных уязвимостей. Мы можем использовать «Nikto», так как на атакуемой машине мы имеем несколько веб-сервисов.

Если запустить этот сканер с помощью команды «nikto» без параметров, то мы увидим ошибку:

Иными словами, для корректной работы инструмента нам нужно указывать некоторые опции, в частности, «-host <ip-адрес>». Имейте ввиду, что на атакуемой машине несколько веб-серверов. Один из них использует 80 порт (сервер Apache), а другой 8180 (Apache Tomcat).

Давайте поработаем с сервером Apache Tomcat.

В нашу команду добавляем опцию «-p», а также порт 8180, т.к. по-умолчанию используется 80 порт, который нам пока что не нужен. Команда будет иметь вид: «nikto -host 192.168.15.131 -p 8180»:

Nikto запустился, и нам нужно подождать результат работы инструмента:

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

К счастью, сканер «Nikto» обнаружил учетные данные, которые принадлежат ему:

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

Номер порта указывается для того, чтобы не использовались дефолтные порты, такие как 80 и 443.

Пробуем авторизироваться в Tomcat, и используем вкладку «Tomcat Manager»:

Отлично. Мы авторизировались в панели управления Tomcat:

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

Можно создать для Ваших целей определенное ПО, или воспользоваться инструментом «Metasploit», воспользовавшись готовым модулем, для загрузки на сервер. Запустим Metasploit, и воспользуемся поиском. Команда будет выглядеть как: «search tomcat»:

В этом выводе есть две подходящие опции – это «tomcat_mgr_deploy» и «tomcat_mgr_upload»:

Обе эти опции отлично подходят нам против Tomcat. Выбираем вторую, и выполняем команду «use»:

Просмотрим опции с помощью команды «show options»:

Вспомните взлом vsftpd, который был в прошлом занятии. Сейчас ничего не отличается, кроме большего списка параметров, которые нужно настраивать.

Для начала укажем имя пользователя и пароль:

Далее нужно указать удаленный хост или айпи-адрес цели и порт. У меня это 192.168.119.130:8180. По-умолчанию стоит порт 80, который мы изменили:

Давайте перепроверим, что все опции настроены правильно. Это делается с помощью команды «show options»:

И, наконец, выполняем команду «run»:

Отлично. Теперь у меня есть шелл Meterpreter-a. Данный шелл является частью Metasploit. Он позволяет выполнять команды на атакуемой машине. Данные команды будут отличаться от обычных команд моей цели. Например, если мы выполним команду «id», то появляется ошибка:

Все дело в том, что meterpreter не знает этой команды, так как он является отдельным шеллом со своими командами, к которым не относится команда «id».

Можем ввести команду «pwd», и она сработает:

Данная команда работает и на meterpreter, и на linux-системах.

Если выполнить команду «whoami», то она не сработает:

Для того, чтобы узнать, какие команды нам нужно использовать, нужно ввести знак вопроса «?»:

Это длинный список команд meterpreter.

Если meterpreter кажется Вам непонятным, то не волнуйтесь и рассматривайте его следующим образом; при взломе атакуемой машины Metasploit загружает на нее программу, которая позволяет взаимодействовать с этой машиной, и выполнять различные команды. Это программа называется «meterpreter».

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

Если мне нужен линукс-шелл, то для этого нужно ввести команду «shell»:

В нем работают все команды, которые присущи линукс-системам.

Если выполнить команду «guid», то она уже не сработает:

Все из-за того, что я нахожусь в линукс-шелле.

Однако, можно выполнить команду «whoami», и «id», то они будут работать:

Обратите внимание, что вышеописанные команды не работали в meterpreter. После ввода команды «shell», я получил доступ непосредственно к стандартному линукс шеллу. Теперь я могу выполнять стандартные линукс команды.

Есть один момент, который заключается в том, что я не рут пользователь, а обычный пользователь «tomcat55».

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

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

Существуют инструменты, которые заточены на работу с определенными веб-технологиями. К примеру, для работы с сайтом на вордпресс существует инструмент для поиска уязвимостей, который называется wpscan.

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

Мы нашли несколько способов, как можно взломать нашу цель, используя разные уязвимости. Сначала мы взломали ftp-сервис, при этом мы использовали версию ftp, которую мы узнали с помощью «nmap». После этого мы использовали результат сканирования «nessus», где мы узнали, что есть эксплойт для попадания в систему. Как в случае с ftp и ssh сервисами, мы получали рут-права на системе жертвы. Далее мы использовали эксплойт веб-приложений, и смогли попасть в систему через веб-сайт. В последнем случае мы смогли попасть в систему только как обычный пользователь, а не как рут-пользователь. Нам осталось лишь повысить права. Однако, перед этим давайте взломаем систему еще одним способом.

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

В зависимости от мировоззрения и настроения написанное можно воспринимать как буквально, так и творчески.

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

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

Брутфорс при включенном аудите неудачных попыток входа

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

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

Если на сервере терминала работает аналог fail2ban, например, Ts_block, EvlWatcher или RdpGuard, то удалите его немедленно. Такой сервис обеспечит вам блокировку на фаерволе IP–адреса после неудачных попыток подключения. Вы же не хотите мешать взлому, верно?

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

Это означает, что в системе включена политика ограниченного использования программ (SRP – Software Restriction Policies). Эта технология появилась во времена Windows XP и ее принцип работы очень прост: при настроенной политике ни один из исполняемых файлов, кроме разрешенных, не будет запущен. И действительно опасными для системы останутся только эксплойты.

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

Но руководство может обратить внимание на отключение политики. В таком случае для вируса можно открыть другую лазейку. Обычно при настройке SRP разрешается запуск исполняемых файлов из системных папок, но остается без внимания один нюанс: в системных папках есть подпапки, в которых у пользователя есть права на создание файлов. Например, путь C:\Windows\Temp:

В параметрах безопасности разрешите создание файлов и их выполнение

Полный список занятных подпапок в системных каталогах можно получить с помощью Powershell или через утилиты вроде DumpSec.

Шифровальщикам, попавшим в систему через почту, это, конечно, не поможет. Но если автор вируса получил непривилегированный доступ к серверу, то он сможет закинуть в эти папки исполняемые файлы и зашифровать все, что угодно. Опытный «хозяин» шифровальщика сможет получить также и хэши паролей (особенно, если система использует NTLM), а через них вскрыть хэш перебором и открыть для себя уже привилегированный доступ. Чтобы вместо безопасного Kerberos работал NTLM, достаточно заходить на сетевые ресурсы не по имени, а по IP-адресу.

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

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

Теперь вирус гарантированно сможет проникнуть в инфраструктуру и зашифровать полезные данные. Однако для окончательного триумфа этого недостаточно: ведь у вас останутся резервные копии, которые быстро восстановят работоспособность. Поэтому что? Правильно, корректируем настройки резервного копирования – чтобы не мешали.

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

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

Бэкапы должны быть на одном сервере: шифровальщик их зашифрует, а имеющиеся теневые копии – удалит;

Файлы нужно архивировать с расширением .zip или .bak. Упаси биллгейтс, будут файлы .exe или вовсе без расширения – наш «зверек» может их пропустить!

Нежелательно делать резервное копирование в облако или на сетевой ресурс, подключаемый по отдельному имени пользователя – так вирусу будет сложно до них добраться;
Другой хороший вариант – настроить резервное копирование в расшаренную папку с правами «Все — полный доступ».

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

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

Spora ransomware удаляет теневые копии с помощью команды vssadmin.exe и отключает восстановление в загрузчике. UAC мог бы остановить это действие.

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

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

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

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

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

Это будет подробная история о том, как я взломал сервер, на котором размещалось 40 (это точное число) веб-сайтов, и о моих находках.

Примечание. Некоторые предварительные знания CS необходимы для понимания технической составляющей статьи.

Друг сообщил мне, что его веб-сайт XSS уязвим, и попросил меня взглянуть. Я попросил у него официальное разрешение на полное тестирование его веб-приложения на его сервере. Ответ был положительным.

Первый шаг – найти как можно больше информации о своем враге, пытаясь как можно меньше его тревожить.

На этом этапе мы запускаем наш таймер и начинаем сканирование.

Множество открытых портов! Судя по тому, что порты FTP (порт 21) и SMB (порты 139/445) открыты, можно предположить, что сервер используется для размещения и совместного использования файлов, а также является веб-сервером (порты 80/443 и прокси на 8080/8081).

При сканировании UDP-порта будет рассмотрено более 1000 портов, если вышеизложенной информации недостаточно. Единственным портом, с которым разрешено взаимодействовать (без учетных данных), является порт 80/443.

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

Оказывается, путь /admin был «административным инструментом», который позволял аутентифицированным пользователям изменять материал на веб-сервере. Он требует параметры доступа, которых у нас нет (спойлер: gobuster не нашел ничего ценного).

Веб-сайт просит нас войти. Нет проблем. Создаем учетную запись с фиктивной электронной почтой, щелкаем по электронной почте подтверждения и входим в систему через несколько секунд.

Веб-сайт приветствует нас, предлагает перейти к профилю и обновить фотографию. Как мило.

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

Я пытаюсь загрузить «картинку» и – бинго! Загрузчик позволяет загрузить файл exploit.php. Конечно, у него нет эскизов, но это значит, что мой файл где-то загружен.

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

В конце концов, люди заботятся о безопасности.

Похоже, что webshell готов и работает:

Видим, что веб-сервер запускает perl-скрипты (реально? perl?). Мы берём обратную оболочку perl из нашего любимого cheatsheet, устанавливаем IP/Port и получаем в качестве награды low-privileged оболочку – извините, нет скришота.

5 минут в оценке, и у нас уже есть оболочка с низким уровнем привилегий.

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

Примечательно, что внутри каталога cgi-admin/pages все скрипты perl соединялись с базой данных mysql как root. Учетные данные для базы данных были в открытом виде. Пусть они будут root:pwned42.

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

И мы находимся в базе данных с привилегиями root.

Через 7 минут у нас есть полный доступ для чтения / записи к содержимому 35 (!) баз данных.

Морально я обязан здесь остановиться и поделиться выводами. Потенциальный ущерб уже огромен.

Что может сделать злоумышленник

Дамп содержимого всех баз данных, как описано здесь, в результате чего произойдёт утечка данных всех 35 компаний.
Удалить все базы данных 35 компаний.
Оставить бэкдор для постоянного доступа как apache с cronjob, как описано здесь ( если злоумышленник хочет вернуться.

Процесс mysql запускался под root, поэтому я решил, что попробовал выполнить \! whoami в надежде получить root. К сожалению, я все еще был apache.

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

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

Я вспомнил об открытых портах SMB. Это означало, что где-то в папке должна быть другая папка, которая используется в системе среди пользователей. После небольшого поиска в каталоге /home/samba/secure появляется следующее:

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

.psd / .ai (дизайнеры знают, как важно сохранять эти данные);
файлы cookie sqlite;
счета-фактуры;
пиратские электронные книги (усмехнулся, когда я увидел);
учетные данные для SSID-сетей WiFi.

Что может сделать злоумышленник

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

Потребовалось некоторое время, чтобы пройти через папки и понять, насколько серьезна эта проблема.
Еще один перерыв.

Осмотревшись еще немного как apache, я решил, что пришло время пойти на большую рыбу – получить доступ root. Используя шпаргалки, начинаю перебирать систему.

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

В задачах Capture the Flag, которые я использую для игры, операционная система обычно пропатчена. Это некоторая намеренно неверно настроенная служба, которая в конечном итоге дает вам привилегии root. Однако в реальном мире люди не латают дыры.

Я имею в виду вот что: посмотрите на Equifax (не мог удержаться).

Какой Linux работает на сервере?

Какая версия ядра?

Это похоже на старую версию ядра.

Это напоминает вам что-то? Если нет, прочитайте здесь (подсказка: это ОЧЕНЬ серьезно).

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

Временные метки и восстановленные сайты Firefox отредактированы

Игра закончена

Я мгновенно написал электронное письмо, полностью раскрывающее детали и потенциальное влияние каждого шага, как описано выше. Уф.

Что может сделать злоумышленник

Чтение/изменение ВСЕХ файлов на сервере.
Оставить постоянный бэкдор (как сделали с apache).
Устанавливать и потенциально распространять вредоносное ПО в интрасети сервера.
Установить ransomware.
Использовать сервер как криптовалютный майнер.
Использовать сервер как прокси-сервер.
Использовать сервер как сервер C2C.
Использовать сервер как часть ботнета.
*… (использовать ваше воображение).
rm -rf / (без шуток).

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

Подводя итоги, мы обнаружили следующее:

Веб-приложение с уязвимостью для неограниченной загрузки файлов, которая привела к использованию оболочки с ограниченными правами.
Учетные данные для базы данных mysql, которые привели к доступу на чтение/запись к 35 базам данных.
Множество читаемых конфиденциальных файлов.

Наконец, мы злоупотребили непропатченным ядром для получения доступа root.

Начнем с аплоудера, который дал основной плацдарм. Поскольку бэкенд всего веб-приложения был написан в perl, я не могу предложить решения.

Решение, которое я бы предложил, было бы таким: не использовать perl в 2017 году, но это только мое мнение.

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

Запуск всех веб-сайтов на одном сервере – плохая идея, я не уверен, позволит ли докеризированный подход решить проблему.

Наличие одинаковых учетных данных для всех баз данных – безусловно, плохая идея.

Наконец, пропачьте все. Это всего лишь одна команда: su -c 'yum update' (специфичная для CentOS).

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

Опыт первый: маленькие симптомы большой проблемы

Было решено начать с инвентаря. Всё размещено у крупного публичного оператора: по нескольку виртуальных машин на арендованный сервер с предустановленным гипервизором Xen:

Эксперты могут со мной не согласится, но я нахожу KVM гораздо удобнее Xen для элементарной виртуализации инфраструктуры маленьких предприятий. Xen может привлечь тех, кто предпочитает графический интерфейс управления. Но, к сожалению, возможности данного графического интерфейса довольно ограниченны, а интерфейс управления командной строки Xen сильно уступает по своей простоте KVM/QEMU в случае, если надо зайти за рамки стандартных манипуляций виртуальных машин. Но похоже, что данный вопрос не особо волновал моего предшественника, управлявшего системами с наименьшим приложением усилий. Как оказалось, всё было установлено по умолчанию, а именно: сервера работали на устаревшей Ubuntu 12.4 LTS, вместо привычных для таких целей Debian.

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

Тут следует сказать, что любой сисадмин, в душе, должен быть немного детектив. Нужно уметь замечать малейшие аномалии, за которыми могут скрываться большие проблемы. В данном случае мое внимание привлекли странные файлы с привилегией root. “Наверное нас хакнули”, пожал плечами коллега, не приняв мое беспокойство всерьез. Простых подозрений было недостаточно, и мы решили пока ничего особенного не делать. Архивируем подозрительные файлы, меняем пароль пользователя и продолжаем инвентарь.

Опыт второй: не злите злых хакеров

А если разозлили, то готовьтесь к последствиям.

Придя на работу, натыкаемся на комитет из взволнованных сотрудников. Ситуация критическая. Сервер недоступен, но доступен его гипервизор через Xen. Становится ясно, что сервер работает, но полностью утеряна связь с Интернет:

Значит, проблема в маршрутизации. Лезем к оператору:

Заодно находим саму проблему:

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

Первым делом — файрвол:

Далее, меняем всем пароли:

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

И, кстати, больше никакого доступа с паролем: только ключи ssh!

Теперь нас никто не застанет врасплох. Устанавливаем слежку за теми, кто входит в систему. Для этого добавляем в /etc/pam.d/sshd исполнение простого скрипта нотификации (loginlog):

А также подглядываем за ключами:

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

Читайте также: