CTFzone write-ups — Grand Finale
Друзья, настало время раскрыть последнюю тайну CTFzone. Мы готовы опубликовать райтап на одно из самых сложных заданий соревнований – OSINT на 1000 очков. Как и в случае с Reverse 1000, мы решили вынести последнее задание ветки в отдельный пост ввиду большого размера и сложности.
Решения на таски попроще мы публиковали ранее, и теперь пришло время финального аккорда. Мы постарались сделать наш заключительный райтап максимально подробным, поэтому статья получилась длинной и интересной. Все готовы? 😉
OSINT_1000: Polish businessman
A.U.R.O.R.A.: Lieutenant, it’s time for another memoir. Are you ready? This part of Scott’s diary is about Captain Picard and his brother.
Scott’s memoirs. April 19, 2047.
«Is it just a joke or true blackmail?! Captain has just called me and said that his brother – very rich businessman Wilczek — has found a USB drive on his table this morning which contains very dangerous extortion and threats. He doesn’t want anyone in the department to know what is happening as there is some dirt on this USB and the crook has more. He wants me to do the impossible and to find a blackmailer but it’s my only chance to come back to Earth».
Well, I assume Lieutenant Scott succeeded as you are on his place. But how did he manage to do it?.
Решение:
Пришло время последнего эпизода воспоминаний Скотта. На этот раз мы имеем дело с корпоративным шантажом. Богатому польскому бизнесмену была подброшена флешка, на которой содержится очень опасная для него информация. Наша задача — найти шантажиста. Но если раньше все было вполне реально, то на этот раз задача выглядит невыполнимой.
Нам был предоставлен образ флешки, в котором хранился odt-документ:
В документе всего две страницы, первая содержит письмо господину бизнесмену:
Вторая страница содержит часть переписки из почты этого бизнесмена и скан документа с пополнениями счета. Суммы, конечно, внушительные:
Чист данный человек или не совсем, судить не нам (а если и нам, то про себя). Наша задача — найти того, кто организовал шантаж. Ну что ж, приступим.
Все, что у нас есть — это образ с документом, в котором содержатся имя и название фирмы, а так же почта жертвы. По доменному имени даже можно найти какую-то информацию в сети. Но, как заметили участники, решавшие это задание: «Да сразу понятно, что это просто вода».
Поиск по имени тоже ничего примечательного нам не дает… Попробуем изучить документ, в частности его метаданные. Каждый хоть раз находил там что-то нужное.
Мы находим новое имя: «kasperkowalkiewicz». Отлично, есть зацепка! Продолжаем поиски, опираясь на нее. Следует заметить, что многие участники думали, что это и есть конец задания. Тут можно было вспомнить, что это самое сложное задание в ветке OSINT, и не останавливаться на достигнутом 😉
Где бы мы ни смотрели, поиск по имени ничего не дает. Единственное, в чем мы уверены — это в польском происхождении имени. Как говорилось в одной басне: «Иной перемудрит, стараясь найти решение какой-то проблемы, а оно, оказывается, лежит на поверхности». Попробуем начать сначала.
Рассмотрим имеющийся у нас образ флешки. Изучив его, мы найдем название, данное пользователем при каких-то условиях (отсылка на это и будет хинтом для пользователей во время соревнования):
В поиске аббревиатуры помогает «Википедия». Похоже, мы нашли дальнеший путь действий:
Далее проведем поиск по имени на «гите»:
Есть пользователь с таким именем! Посмотрим, что у него на странице и в репозиториях:
Мы узнали никнейм этого пользователя и нашли один репозиторий, в котором ютится одинокий скрипт на bash’е. Изучив скрипт, мы понимаем, что это недописанный чекер сайта, который работает исключительно через TOR (согласно комментарию в начале скрипта). Внизу есть комментарий на польском, который просит разработчика дописать его как можно скорее. Самой примечательной является строка, которая получает статус-код доступности сайта. IP-адрес в ней представлен в hex-виде:
Попробуем узнать, какой IP-адрес у сервера, и посмотрим, чем он «светит» наружу:
Мы видим, что hex преобразовался в читаемый IP-адрес. Этой информации нам недостаточно, смотрим дальше:
Неплохо, на нестандартном порту висит Апач, плюс есть git-папка с какими-то исходниками. Будем разбираться. Переходим на сайт:
Скорее всего, исходники у нас уже есть. Проверим содержимое выкачанных файлов:
Опа! В папке admin есть интересные файлы, попробуем поискать в них подсказку. Файл login.php содержит важную информацию:
А вот и словарный пароль: «qweqwe» — удача снова на нашей стороне! Пробуем залогиниться через адресную строку, формат запроса простой:
Пройдемся по записям в этой таблице:
Перейдя по первой записи, мы видим путь в строке браузера: http://185.143.173.87:8081/admin/?bot_id=1053. Параметр «id» всегда наталкивает на мысль об SQL-инъекции 😉
Начитавшись в гугле по теме «advanced sql injection techniques», демонстрируем свое превосходство:
В таблице «bots» нет ничего полезного. Изучим ту, что имеет более примечательное название:
В таблице «user_agent» среди множественного входа админа мы нашли 3 уникальных юзерагента, причем один из них явно юзерагент TOR-браузера:
Предположим, что пользователь заходил минимум с двух машин, ведь TOR-браузер может стоять на каждой из них (или даже с одной, т.к. подделать юзерагент не составляет труда. Он мог просто пользоваться двумя разными браузерами на одной машине). Нам необходимо получить информацию об IP-адресах, с которых выходил пользователь:
Интересно, что заходов было очень много — 33 записи являются уникальными. Очевидно, причина повторения адресов кроется в том, что пользователь заходил на сайт повторно с разницей в несколько минут. Это наводит на определенные мысли. Берем первый по списку IP-адрес и пробуем поискать о нем информацию:
Как мы видим, это TOR-нода. Попробуем рандомный IP c другим юзерагентом и получим примерно тоже самое:
Досадно… Выходит, что трафик Каспера Ковалькевича всегда «торифицирован», и он нам ничего не даст. Тем не менее, на всякий случай проверим все IP-адреса.
Всем известно, что TOR ежеденевно публикует список своих выходных узлов. Список доступен по этому адресу. Он обновляется каждый день, так как одни ноды исчезают, а другие добавляются. Сформируем два файла — в один поместим список выходных нод, а во второй полученную нами базу адресов. Далее попытаемся найти адреса, которых нет в списке TOR’а, если таковые имеются. Можно попробовать написать скрипт для получения разницы, но намного быстрее будет воспользоваться bash’ем. Сначала посчитаем количество строк в двух файлах, а затем сравним:
Разница совсем небольшая, можно проверить руками. Ищем в гугле: «наш_IP tor». Из всех IP-адресов только 188.68.237.55 никакого отношения к TOR’у не имеет:
Посмотрим информацию об этом IP-адресе:
Похоже, этот адрес принадлежит тому самому Касперу Ковалькевичу. Посмотрим, что на нем есть. На машине висит Апач, главная страница выдает какую-то странную фразу:
Ищем информацию по строкам: «i hereby claim» и находим отсылку на keybase.io. Keybase.io — это всеобщий репозиторий открытых ключей, где все ключи соответствуют уникальным именам пользователей. Попробуем отыскать ключ нашего пользователя. Попробуем погуглить по именам, которые мы ранее находили на данном сервере, но это нам ничего не дает. Почитав поподробнее про хранение ключей, мы выясняем, что ключ может лежать в папке «.well-known». Проверяем и этот вариант:
Ура! Здесь есть какой-то файл, ознакомимся с его содержимым:
Переходим на страницу пользователя по ссылке https://keybase.io/prepro :
Изучаем страницу пользователя и видим на ней сокращение от знакомого нам имени. Читаем юзеринфо, из которого мы узнаем, где и кем работает наш пользователь. Теперь у нас есть информация о шантажисте, которую мы позже передадим заинтересованным людям.
Blackice icecap что это
чо значит вот такое дело можно ли ломануть:
сканируемые сервисы : 2388
расширение сканера безопасности : 341
скрипты для всех веб серверов : 62
скрипты для серверов MsIIS : 75
скрипты для серверов не MS IIS : 55
скрипты для серверов Lotus : 6
скрипты для серверов Netscape : 2
список директорий для WEB : 123
список директорий для FTP : 385
список вариантов CD (ftp) : 45
словарь логинов для MySQL : 117
словарь паролей для MsSQL : 112
список комьюнити для SNMP : 2
внешние модули уязвимостей : 548
Имя компьютера «195.162.32.59» : www.omskelecom.ru
Компьютер находится в сети (TTL = 126) >>>
Cеть класса C (максимальное число компьютеров 254)
TCP порты
— открытые : 19
— закрытые : 2359
— недоступные : 10
— порт 80/tcp
сервер WWW : Microsoft-IIS/5.0 >>>
состояние : 200 (OK)
расположение : http://www.omskelecom.ru/Default.html >>>
текущие дата и время : (Wed, 21 May 2003 13:39:26 GMT)
последняя модификация : (Mon, 24 Mar 2003 07:27:12 GMT)
формат содержимого : (text/html)
возможность использования веб-сервера в качестве прокси-сервера >>>>
анонимность IP адреса не соблюдается
анонимность браузера не соблюдается
анонимность Cookie не соблюдается
анонимность Refer не соблюдается
анонимность дополнительного параметра не соблюдается
список файлов и директорий:
total 123
rwxrwxrwx 1 ftp ftp 0 Apr 11 18:29 Patches
текущая директория : «/»
возможен доступ ко всем файлам на диске (CWD *) >>>>>
возможен доступ ко всем файлам на диске (CWD /*) >>>>>
возможен доступ ко всем файлам на диске (CWD \*) >>>>>
возможна атака Break through FTP (обход файрвола) >>>>
ответ на Ms SQL запрос:
x #1 #7 #0 8Ъ >>>
существующие, но недоступные директории >>>
/include/
Русские Блоги
Как взломать 40 сайтов за 7 минут?
Нажмите выше » CSDN «, выберите» Официальный аккаунт «
Доставить в критический момент!
Прошлым летом я начал изучать методы защиты информации и взлома. В прошлом году я постоянно совершенствовал свои хакерские навыки, участвуя в различных военных играх, захватывая флаг и симулируя тесты на проникновение. Я также узнал много новых техник о том, «как заставить компьютер отклониться от ожидаемого поведения».
Короче говоря, мой опыт всегда ограничен смоделированными средами, и я считаю себя этичным хакером в белой шляпе, поэтому я никогда не вторгался в бизнес других людей, ни разу.
До настоящего времени. В этой статье рассказывается история моего взлома сервера, на котором размещено 40 веб-сайтов (точное количество), и того, что я обнаружил в процессе.
Обратите внимание: технология, описанная в этой статье, предполагает некоторые базовые знания в области информатики.
Друг сказал мне, что на его веб-сайте была обнаружена XSS-уязвимость, и он надеялся, что я смогу узнать больше. Это очень важный этап, потому что я попрошу его разрешить мне провести комплексное тестирование его веб-приложения и предоставить мне полный доступ к серверу хостинга. В конце концов он согласился.
В этой статье предположим, что адрес веб-сайта моего друга: http://example.com.
На этом этапе запускаю таймер и начинаю сканирование.
Сканирование было выполнено примерно за 2 минуты.
На этом сервере много открытых портов! Путем наблюдения я обнаружил, что порты FTP (порт 21) и SMB (порты 139/445) открыты. Я предполагаю, что сервер использует эти порты для размещения файлов и общих файлов. Я также обнаружил, что это веб-сервер (порт 80/443, прокси находится в Порт 8080/8081).
Поторопитесь, я запустил gobuster и перечислил все интересные файлы на веб-сервере, а заодно буду добывать информацию вручную.
Пока это заняло у меня около 3 минут. Однако ничего не добилось.
Во время просмотра веб-сайта он попросил меня войти в систему. Все в порядке, я создал учетную запись с виртуальным адресом электронной почты, затем через несколько секунд нажал на письмо с подтверждением и успешно вошел в систему.
На веб-сайте отобразилось приветственное сообщение, а во всплывающем диалоговом окне я перешел на страницу профиля с просьбой обновить мою фотографию профиля. Это очень внимательно.
Похоже, что сайт настроен, поэтому я решил протестировать уязвимость неограниченной загрузки файлов. Я выполнил следующую команду на терминале:
Я пытался загрузить «картинку», ха-ха! Сайт принимает загрузку exploit.php. Конечно, для этого файла нет эскиза, но это означает, что мой файл должен быть загружен где-то на сервере.
Получите местоположение эксплойта
В конце концов, всех очень беспокоят вопросы безопасности.
Следующее «скопировать путь изображения», по сути, означает скопировать следующий путь:
Похоже, мой троян для веб-страниц готов и работает:
Я обнаружил, что на веб-сервере запущен сценарий Perl (правда, Perl?), Поэтому я взял его из обычно используемой шпаргалки (http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet) Переверните оболочку на языке Perl, установите IP / порт, тогда я получу оболочку с низким уровнем привилегий (извините, скриншотов нет).
На 5-й минуте у меня уже была низкопривилегированная оболочка.
К моему удивлению, на сервисе размещено более 1 веб-сайта, всего 40 различных веб-сайтов. К сожалению, я сохранил не все подробные снимки экрана, а только следующий вывод:
Думаю, ты тоже это видишь. Шокирует то, что я могу читать все размещенные веб-сайты, а это значит, что я могу получить доступ к коду всех веб-сайтов. Я думал, что могу получить доступ только к коду example.com.
Стоит отметить, что в каталоге cgi-admin / pages все сценарии perl подключаются к базе данных mysql как root. Аутентификация базы данных хранится в виде обычного текста, например: root: pwned42.
Разумеется, MariaDB работает на сервере, и мне пришлось прибегнуть к этой проблеме (https://github.com/dockerfile/mariadb/issues/3) перед доступом к базе данных. Затем я выполнил следующую команду:
Снимок экрана после входа в базу данных с правами root выглядит следующим образом:
«Использовать пользователя базы данных», я могу получить доступ к 35 базам данных и могу просматривать / изменять содержимое базы данных.
Всего за 7 минут у меня есть все права на чтение и запись 35 (!) Баз данных.
На этом этапе я должен с этической точки зрения прекратить эту хакерскую операцию и разоблачить полученные данные. Эти потенциальные опасности уже вызывают серьезную тревогу.
Как злоумышленник распорядится этими данными:
Сброс содержимого всех баз данных привел к коллективному раскрытию данных всех 35 компаний. Таким образом (https://stackoverflow.com/questions/9497869/export-and-import-all-mysql-databases-at-one-time).
Удалить все базы данных, удалить сразу все данные 35 компаний.
Используйте cronjob, чтобы оставить черный ход, чтобы облегчить будущие посещения через apache. Таким образом (http://blog.tobiasforkel.de/en/2015/03/19/setup-cron-job-for-apache-user/).
Я должен заметить, что процесс mysql здесь выполняется как root, поэтому, если я попытаюсь запустить \! whoami, возможно получить root identity. К сожалению, я все еще апачей.
Хорошо, сделай перерыв, и таймер закончился.
В чем проблема?
Разоблачив свои выводы, я получил больше разрешений на дальнейшие раскопки.
Прежде чем искать способ повысить свои привилегии до root, чтобы нанести большой вред, я изучал, к каким другим интересным файлам могут получить доступ мои ограниченные пользователи.
В тот момент я вспомнил об открытом SMB-порту. Это означает, что определенная папка где-то должна быть доступна системным пользователям. После некоторой проверки в каталоге / home / samba / secured появились следующие каталоги (простите, пожалуйста, мой пакетный обзор):
Эти каталоги содержат файлы для каждого пользователя хостинговой компании. Сюда входят некоторые конфиденциальные данные, такие как:
Файл cookie sqlite
Пиратские электронные книги (я невольно смеюсь, когда вижу их)
WiFi SSID и пароль
Как злоумышленник распорядится этими данными:
Живите за пределами компании, авторизуйтесь в их интрасети и проводите различные интересные атаки, которые можно использовать в локальной сети;
Разместите все конфиденциальные данные, перечисленные выше, в Интернете.
Найдите время, чтобы просмотреть эти папки, и вы поймете, насколько серьезна эта проблема. Снова сделай перерыв.
Завершающий удар
Пока мои поиски исчерпали большую часть технологий, но кажется, что я не могу найти точку прорыва.
В этот момент я внезапно подумал, что в предыдущем задании «Захват флага» операционная система обычно вносит некоторые изменения, намеренно создает некоторые неправильные службы конфигурации и, наконец, предоставляет вам необходимые привилегии root. Однако в реальном мире люди не стали бы этого делать.
Я имею в виду, посмотрите на Equifax.
На каком Linux работает сервер?
Похоже, это старая версия ядра.
Что вы думаете, когда видите эту картинку? (Подсказка: эта проблема очень и очень серьезная)
Если нет, нажмите здесь:
В этом сообщении в блоге я нашел сценарий, который мне нужен для проверки уязвимости ядра:
Я немедленно написал электронное письмо, полностью раскрывая детали и потенциальное влияние каждого из вышеперечисленных шагов, и я могу вздохнуть с облегчением после того, как работа ночи закончилась.
Что может сделать злоумышленник:
Прочитать / изменить все файлы на сервере;
Оставить постоянный бэкдор (через apache);
Установите вредоносное ПО, и оно может распространиться во внутренней сети сервера;
Установить программы-вымогатели (например, базы данных 35 компаний, данные всех хостинговых компаний считаются заложниками);
Использовать сервер как майнер криптовалюты;
Использовать сервер как прокси;
Используйте сервер как сервер C2C;
Использовать сервер как часть ботнета;
. (можете себе представить);
На следующий день мой друг (он связался с компанией, эксплуатирующей сервер) сказал мне, что ошибка в загрузке файла была исправлена.
Подведем итог нашим выводам:
Веб-приложение имеет уязвимость неограниченной загрузки файлов, что дает злоумышленнику оболочку с низким уровнем привилегий;
Уязвимость аутентификации базы данных MySQL, которая позволит злоумышленнику читать и записывать 35 баз данных;
Множество читаемых конфиденциальных документов.
Наконец, злоумышленник может использовать ядро без исправлений, чтобы получить root-доступ.
Меры по улучшению
Во-первых, ошибка загрузки файла дала нам шанс начать. Поскольку серверная часть всего веб-приложения написана на Perl (а я не знаю Perl), я не могу предложить исправление.
Но я могу посоветовать одну вещь: не используйте версию perl 2017 года, но это всего лишь мое мнение, вы всегда можете доказать, что я неправ.
Что касается файловой системы, я предлагаю сослаться на принцип наименьших привилегий и тщательно назначать пользователям соответствующие права доступа к файлам. Таким образом, даже если пользователи с низким уровнем привилегий, такие как apache, могут получить доступ, они не могут читать какие-либо конфиденциальные файлы.
Определенно плохая идея иметь одинаковую аутентификацию для всех баз данных.
Единственная точка отказа обычно не годится.
Переводчик: Crescent Moon, редактор: Words
Нажмите на картинку, чтобы прочитать
Как я взломал 40 сайтов за 7 минут (перевод)
Прошлый летом я заинтересовался вопросами информационной безопасности и взлома. Последний год я много играл в wargames, «захват флага», тестирование на проникновение, постоянно совершенствуя навыки взлома и изучая новые способы заставить компьютеры отклоняться от ожидаемого поведения.
Короче говоря, мой опыт ограничивался имитируемой средой, и, считая себя официальным хакером, я никогда не совал нос в бизнес других людей.
Это будет подробная история о том, как я взломал сервер, на котором размещалось 40 (это точное число) веб-сайтов, и о моих находках.
Примечание. Некоторые предварительные знания CS необходимы для понимания технической составляющей статьи.
Друг сообщил мне, что его веб-сайт XSS уязвим, и попросил меня взглянуть. Я попросил у него официальное разрешение на полное тестирование его веб-приложения на его сервере. Ответ был положительным.
В статье я буду ссылаться на сайт моего друга – http://example.com
Первый шаг – найти как можно больше информации о своем враге, пытаясь как можно меньше его тревожить.
На этом этапе мы запускаем наш таймер и начинаем сканирование.
Сканирование завершается по истечении 2 минут.
Множество открытых портов! Судя по тому, что порты FTP (порт 21) и SMB (порты 139/445) открыты, можно предположить, что сервер используется для размещения и совместного использования файлов, а также является веб-сервером (порты 80/443 и прокси на 8080/8081).
При сканировании UDP-порта будет рассмотрено более 1000 портов, если вышеизложенной информации недостаточно. Единственным портом, с которым разрешено взаимодействовать (без учетных данных), является порт 80/443.
Оказывается, путь /admin был «административным инструментом», который позволял аутентифицированным пользователям изменять материал на веб-сервере. Он требует параметры доступа, которых у нас нет (спойлер: gobuster не нашел ничего ценного).
Прошло около 3 минут. Ничего полезного.
Веб-сайт просит нас войти. Нет проблем. Создаем учетную запись с фиктивной электронной почтой, щелкаем по электронной почте подтверждения и входим в систему через несколько секунд.
Веб-сайт приветствует нас, предлагает перейти к профилю и обновить фотографию. Как мило.
Похоже, сайт сделан на заказ. Я собираюсь протестировать уязвимость с неограниченной загрузкой файлов. На моем терминале я выполняю:
Я пытаюсь загрузить «картинку» и – бинго! Загрузчик позволяет загрузить файл exploit.php. Конечно, у него нет эскизов, но это значит, что мой файл где-то загружен.
В конце концов, люди заботятся о безопасности.
Похоже, что webshell готов и работает:
Видим, что веб-сервер запускает perl-скрипты (реально? perl?). Мы берём обратную оболочку perl из нашего любимого cheatsheet, устанавливаем IP/Port и получаем в качестве награды low-privileged оболочку – извините, нет скришота.
5 минут в оценке, и у нас уже есть оболочка с низким уровнем привилегий.
К моему огромному удивлению, на сервере размещался не 1 сайт, а сразу 40 разных. К сожалению, я не сохранил скриншоты каждой детали, но вывод был примерно таким:
Удивительно, но у меня был доступ на чтение ко всем размещенным веб-сайтам, а это означало, что я мог читать весь бэкенд-код сайтов. Я ограничился кодом example.com.
Примечательно, что внутри каталога cgi-admin/pages все скрипты perl соединялись с базой данных mysql как root. Учетные данные для базы данных были в открытом виде. Пусть они будут root:pwned42.
Разумеется, на сервере была запущена MariaDB, и мне пришлось решить эту проблему, прежде чем получить доступ к базе данных. После этого мы выполняем:
И мы находимся в базе данных с привилегиями root.
Через 7 минут у нас есть полный доступ для чтения / записи к содержимому 35 (!) баз данных.
Морально я обязан здесь остановиться и поделиться выводами. Потенциальный ущерб уже огромен.
Что может сделать злоумышленник
Процесс mysql запускался под root, поэтому я решил, что попробовал выполнить \! whoami в надежде получить root. К сожалению, я все еще был apache.
Время отдохнуть. Остановите таймер.
Что может пойти не так?
Я поделился своими выводами и получил разрешение копать глубже.
Прежде чем искать способы повысить свои привилегии до root и иметь возможность причинить огромный потенциальный ущерб, я посмотрел, какие другие интересные файлы мог бы читать, будучи ограниченным пользователем.
Я вспомнил об открытых портах SMB. Это означало, что где-то в папке должна быть другая папка, которая используется в системе среди пользователей. После небольшого поиска в каталоге /home/samba/secure появляется следующее:
Внутри всех этих каталогов были файлы каждого пользователя хостинговой компании. Это включало все виды конфиденциальных данных, среди прочего:
Что может сделать злоумышленник
Потребовалось некоторое время, чтобы пройти через папки и понять, насколько серьезна эта проблема.
Еще один перерыв.
Последний удар
Осмотревшись еще немного как apache, я решил, что пришло время пойти на большую рыбу – получить доступ root. Используя шпаргалки, начинаю перебирать систему.
В процессе исследования на уязвимости я уже перебрал большинство методов и, похоже, не смог найти ничего, что увеличило бы мою точку опоры.
В задачах Capture the Flag, которые я использую для игры, операционная система обычно пропатчена. Это некоторая намеренно неверно настроенная служба, которая в конечном итоге дает вам привилегии root. Однако в реальном мире люди не латают дыры.
Я имею в виду вот что: посмотрите на Equifax (не мог удержаться).
Какой Linux работает на сервере?
Это похоже на старую версию ядра.
Это напоминает вам что-то? Если нет, прочитайте здесь (подсказка: это ОЧЕНЬ серьезно).
Я нашел этот пост в блоге, который указал мне проверить, было ли ядро уязвимым для найденного здесь скрипта.
Временные метки и восстановленные сайты Firefox отредактированы
Игра закончена
Я мгновенно написал электронное письмо, полностью раскрывающее детали и потенциальное влияние каждого шага, как описано выше. Уф.
Что может сделать злоумышленник
На следующий день со мной связался друг (он связался с работающей на сервере компанией) и рассказал, что ошибка в загрузке файлов была исправлена.
Подводя итоги, мы обнаружили следующее:
Наконец, мы злоупотребили непропатченным ядром для получения доступа root.
Решения проблем
Начнем с аплоудера, который дал основной плацдарм. Поскольку бэкенд всего веб-приложения был написан в perl, я не могу предложить решения.
Решение, которое я бы предложил, было бы таким: не использовать perl в 2017 году, но это только мое мнение.
Что касается файловой системы, я рекомендую проявлять большую осторожность при назначении правильных прав доступа к файлам для пользователей в соответствии с принципом наименьших привилегий. Таким образом, даже если низкоприоритетный пользователь, такой как apache, получает доступ, он не может читать конфиденциальные файлы.
Запуск всех веб-сайтов на одном сервере – плохая идея, я не уверен, позволит ли докеризированный подход решить проблему.
Наличие одинаковых учетных данных для всех баз данных – безусловно, плохая идея.
Нежелательно иметь одиночные точки отказа.
