Помогите AuthMe Украли DB Cливают hash паролей.

GrayWaorld

GrayWaorld

Активный участник
Пользователь
Баллы
76
Впервые за долгое время обратился за помощью так как сам не смог решить эту проблему.​

Уже не впервые сливают все пароли с плагина AuthMe. Эта проблема не только у меня но и на многих других серверах.
Может у вас есть идеи как можно защитить сервер от слива или может кто знает как они сливают?
В логах никакой информации нет. Также нет ошибок.
1. Использую локальную базу.
2. Сервер на BungeeCord (использую AuthMeBungee-2.2.0 самую последнюю с github)
3. Лобби на FlamePaper (тот же SpigotPaper только с исправлениями крашей)
4. Использую в лобби тольки самые нужные плагины такие как:

AuthMe-5.6.0-SNAPSHOT (самая новая версия с github)
AuthMeTitle
BungeeGuard
CommandSync
DeluxeMenus-1.13.2
HolographicDisplays (самая новая версия)
PlaceholderAPI-2.11.5
ProtocolLib
ServerNPC-1.14.2 (платный! купил)
SimplePortals
SkinsRestorer
SuperLobbyDeluxe-4.7.1-shaded
Vault-1.6.6
ViaVersion-4.9.2
 
Сортировать по дате Сортировать по голосам
GrayWaorld сказал(а):
Афигеть.. Вы правы! В логах auth.log обнаружил ssh подключения с постороннего ip адреса в приблизительное время слива.
Как взломали? Каким образом могли его получить? Я всегда использую сложный пароль и меняю его часто! Пароль использую к примеру такой:
fygiujfgoowrertetsdgrtuytjdrTppo<eHo+3_+Eo9hojpo
Возможно как то подключиться по ssh не используя пароль? Ну скажем через плагин
Нажмите, чтобы раскрыть...
Пароль который вы привели в пример, не является сложным. + видно что вы его генерировали через какой-то сервис, давайте не будем спорить ведь, они запоминают эти пароли.
 
За 0 Против
Toster_tpl сказал(а):
Возможно. Даже и без ssh возможно.
Если доступ к серверу уже получен(а, судя по всему, он получен), то необходимо проводить глобальную чистку всего и вся. Переустанавливать ОС, чистить плагины, настраивать безопасность и т.д.
Смена пароля от чего-либо не поможет от слова совсем и какой бы он ни был, это тоже никак не повлияет на дальнейший несанкционированный доступ, т.к. на сервере уже может быть установлен бэкдор, как в плагинах, так и в других частях сервера.
Придется потратить большое кол-во времени на изучение всех этих вопросов или обратиться к кому-нибудь, кто не за бесплатно вам с этим поможет.
Из полезных ресурсов могу посоветовать любой адекватный java декомпилятор, habr/toster, digitalocean ну и сопутствующие ресурсы по java и настройкам linux
Нажмите, чтобы раскрыть...
"Ваш сервер, не смогут взломать, если у него не будет доступа к сети. &copy Конфуций".
 
За 0 Против
SlenderMix сказал(а):
сбрутишь, просто времени на это понадобиться гораздо больше.
Нажмите, чтобы раскрыть...
Вот по этому и фиг.
Хотя это конечно еще и от его хеша зависит, если ша256 - то тут уж увы, плохо будет
 
За 0 Против
SlenderMix сказал(а):
Пароль который вы привели в пример, не является сложным. + видно что вы его генерировали через какой-то сервис, давайте не будем спорить ведь, они запоминают эти пароли.
Нажмите, чтобы раскрыть...
Держи генератор на чистом JS - ничего никуда не отправляет.
https://genpas.peter23.com
 
За 0 Против
Уххх так много ответов. Всем спасибо!.
Я генерировал пароль на сайте авто генерации но после генерации я вручную рандомно тасовал пароль. + к всему у меня стоит защита на подбор (блокирует ip после 15 неудачных попыток ввода по ssh)
Поможет ли мне как временное решения ограничить доступ к ssh запретив подключения з других ip
(только мой зайдет) через встроенную функцию в линуксе в файле hosts.allow ?
sshd: 55.55.55. : allow
sshd: all : deny
Где 55.55.55. разрешонный ip
 
Последнее редактирование:
За 0 Против
GrayWaorld сказал(а):
Уххх так много ответов. Всем спасибо!.
Я генерировал пароль на сайте авто генерации но после генерации я вручную рандомно тасовал пароль. + к всему у меня стоит защита на подбор (блокирует ip после 15 неудачных попыток ввода по ssh)
Поможет ли мне как временное решения ограничить доступ к ssh запретив подключения з других ip
(только мой зайдет) через встроенную функцию в линуксе в файле hosts.allow ?
sshd: 55.55.55. : allow
sshd: all : deny
Где 55.55.55. разрешонный ip
Нажмите, чтобы раскрыть...
Поможет или нет, зависит от того, чем выкачивают базу. Подразумеваю, что это какой-то плагин или серверный софт, которому по сути даже ssh не нужен для этого. А если кто-то и подключался через него, то скорее всего только потому, что так удобней. Иными словами, закрытие портов и ограничение по IP на данном этапе абсолютно никак не поможет, т.к. вредоносное ПО потенциально само может отправлять что угодно с сервера и куда угодно.
 
За 0 Против
Toster_tpl сказал(а):
Поможет или нет, зависит от того, чем выкачивают базу. Подразумеваю, что это какой-то плагин или серверный софт, которому по сути даже ssh не нужен для этого. А если кто-то и подключался через него, то скорее всего только потому, что так удобней. Иными словами, закрытие портов и ограничение по IP на данном этапе абсолютно никак не поможет, т.к. вредоносное ПО потенциально само может отправлять что угодно с сервера и куда угодно.
Нажмите, чтобы раскрыть...
Понял. Припустим вредоносный код у моих плагинах. Какие ключевые слова мне стоит поикать в их коде? Или может все проще Пароль сливают с моего компа какой то вредоносной програмой. Я использую FileZilla у котором есть возможность сделать резерв данных о подключении.
 
За 0 Против
GrayWaorld сказал(а):
Понял. Припустим вредоносный код у моих плагинах. Какие ключевые слова мне стоит поикать в их коде? Или может все проще Пароль сливают с моего компа какой то вредоносной програмой. Я использую FileZilla у котором есть возможность сделать резерв данных о подключении.
Нажмите, чтобы раскрыть...
Первое, что я бы стал искать, это отправку запросов на удаленные хосты по ключевым словам: url, http, но это только в том случае, если код не обфусцирован. Если же он обфусцирован и/или получение данных происходит иными методами, то тут только анализировать весь код. Результат может выдаваться множеством разных способов, например через чат, таблички, сообщение на экране, удаленное хранилище и т.д. И всё это может никак не отображаться в консоли или иных логах. Так что универсального метода поиска не существует.
 
За 0 Против
GrayWaorld сказал(а):
Понял. Припустим вредоносный код у моих плагинах. Какие ключевые слова мне стоит поикать в их коде? Или может все проще Пароль сливают с моего компа какой то вредоносной програмой. Я использую FileZilla у котором есть возможность сделать резерв данных о подключении.
Нажмите, чтобы раскрыть...
можно не искать. просто перекачай ядро и все плагины тогда наверняка не будет никаких бекдоров
 
За 0 Против
Toster_tpl сказал(а):
Первое, что я бы стал искать, это отправку запросов на удаленные хосты по ключевым словам: url, http, но это только в том случае, если код не обфусцирован. Если же он обфусцирован и/или получение данных происходит иными методами, то тут только анализировать весь код. Результат может выдаваться множеством разных способов, например через чат, таблички, сообщение на экране, удаленное хранилище и т.д. И всё это может никак не отображаться в консоли или иных логах. Так что универсального метода поиска не существует.
Нажмите, чтобы раскрыть...
Нереально проанализировать весь код плагинов, даже если он не деобфусцирован. Это просто физически невозможно для одного человека. Учитывая все зависимые библиотеки на сервер может подгружаться несколько десятков тысяч классов только благодаря плагинам. А по-хорошему нужно проверять ещё и ядро.
Анализировать отдельные "подозрительные" плагины тоже смысла нет, поскольку они при первом же запуске имеют обыкновение заражать все остальные джарник в сборке.
Короче говоря, ручной анализ - дело абсолютно бесперспективное.

Но есть средства:
1) которые анализируют байткод программно
2) которые проверяют хеш-сумму файлов плагинов на наличие в вирусных базах
3) которые предотвращают попытки исходящих подключений в рантайме для неизвестных хостов

Всё это позволит найти вирусню гораздо быстрее. Конкретно вот это может помочь:
Spigot AntiMalware: https://spigotmc.org/resources/64982
Keiko: https://spigotmc.org/resources/66278

Но, на самом деле, как уже сказали выше, проще действительно перекачать все джарникки/пересобрать все исходники.
Так автор темы ещё и получит важный навык - не качать ресурсы из сомнительных источников, а искать официальные.
Это, конечно, тоже не панацея, но риск заражения на порядок ниже
 
Последнее редактирование:
За 0 Против
Dymeth сказал(а):
Нереально проанализировать весь код плагинов, даже если он не деобфусцирован. Это просто физически невозможно для одного человека. Учитывая все зависимые библиотеки на сервер может подгружаться несколько десятков тысяч классов только благодаря плагинам. А по-хорошему нужно проверять ещё и ядро.
Анализировать отдельные "подозрительные" плагины тоже смысла нет, поскольку они при первом же запуске имеют обыкновение заражать все остальные джарник в сборке.
Короче говоря, ручной анализ - дело абсолютно бесперспективное.

Но есть средства:
1) которые анализируют байткод программно
2) которые проверяют хеш-сумму файлов плагинов на наличие в вирусных базах
3) которые предотвращают попытки исходящих подключений в рантайме для неизвестных хостов

Всё это позволит найти вирусню гораздо быстрее. Конкретно вот это может помочь:
Spigot AntiMalware: https://spigotmc.org/resources/64982
Keiko: https://spigotmc.org/resources/66278

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

В большинстве случаев, анализировать все плагины(или ядро) подряд, действительно нет никакого смысла. Особенно те, которые лежат на проверенных ресурсах и с открытыми исходниками. Их действительно проще перекачать. (Тут еще возникает вопрос, что ТС будет подразумевать под сомнительными источниками, т.к. даже на данном форуме есть те, кто доверяют таким снг проектами как блэк-майнкрафт и ********)

Тем не менее, перекачивать плагины или ядро без сноса ОС, как минимум, глупо. По этому в первую очередь стоит позаботиться об этом и настроить на ней безопасность, а уже потом что-то проверенное заливать.
 
За 0 Против
GrayWaorld сказал(а):
Афигеть.. Вы правы! В логах auth.log обнаружил ssh подключения с постороннего ip адреса в приблизительное время слива.
Как взломали? Каким образом могли его получить? Я всегда использую сложный пароль и меняю его часто! Пароль использую к примеру такой:
fygiujfgoowrertetsdgrtuytjdrTppo<eHo+3_+Eo9hojpo
Возможно как то подключиться по ssh не используя пароль? Ну скажем через плагин
Нажмите, чтобы раскрыть...
Я удивлен, что до сих пор никто не озвучил здесь самую важную мысль, возможно посчитав ее очевидной: никогда не запускать серверы от имени суперпользователей или root, дабы избежать ситуации, в которой плагин с какой-нибудь вирусней имеет беспрепятственный доступ ко всей файловой системе, службам и ОС. Здесь спасает либо контейнеризация через Docker с запуском от непривилегированного пользователя, либо создание отдельного пользователя с своим chroot jail или еще что-нибудь подобное.
Ну и второй, обособленный от ситуации совет: используй SSH ключи вместо паролей для авторизации по SSH.
 
За 0 Против
FeniksDEV сказал(а):
Я удивлен, что до сих пор никто не озвучил здесь самую важную мысль, возможно посчитав ее очевидной: никогда не запускать серверы от имени суперпользователей или root, дабы избежать ситуации, в которой плагин с какой-нибудь вирусней имеет беспрепятственный доступ ко всей файловой системе, службам и ОС. Здесь спасает либо контейнеризация через Docker с запуском от непривилегированного пользователя, либо создание отдельного пользователя с своим chroot jail или еще что-нибудь подобное.
Ну и второй, обособленный от ситуации совет: используй SSH ключи вместо паролей для авторизации по SSH.
Нажмите, чтобы раскрыть...
Самая важная мысль, в том что нужно проверять что ставишь. А не брать всякую ***ню с блекспигота и говорить, а украли, а взломали, а слили и тд.

Да и Java сама по себе такое приложение, которое дает возможность всегда работать от имени системного юзера.
 
За 0 Против
SlenderMix сказал(а):
Самая важная мысль, в том что нужно проверять что ставишь. А не брать всякую ***ню с блекспигота и говорить, а украли, а взломали, а слили и тд.

Да и Java сама по себе такое приложение, которое дает возможность всегда работать от имени системного юзера.
Нажмите, чтобы раскрыть...
Не беру такой фигни так как знаю что платные плагины взламывают чтобы туда положить хак
 
За 0 Против
А тем временем плагинам даже хак внутри вшитый не нужен, чтобы доставить проблемы
https://rubukkit.org/threads/zaschi...aschita-ot-vzloma.178619/page-14#post-1733387

(а я напоминаю, при помощи мультиверс кор можно орудовать файлами, а условным papi загружать на сервер файлы, так что любой плагин может быть потенциальным вредителем в вопросе взлома)
 
За 0 Против
SlenderMix сказал(а):
Самая важная мысль, в том что нужно проверять что ставишь
Нажмите, чтобы раскрыть...
Это правда, конечно. Но если уж так случилось – по незнанию, из любопытства, из-за желания рискнуть –, то в случае соблюдения вышеупомянутого удастся сильно минимизировать урон ¯\_(ツ)_/¯
 
За 0 Против
Dymeth сказал(а):
Нереально проанализировать весь код плагинов, даже если он не деобфусцирован. Это просто физически невозможно для одного человека. Учитывая все зависимые библиотеки на сервер может подгружаться несколько десятков тысяч классов только благодаря плагинам. А по-хорошему нужно проверять ещё и ядро.
Анализировать отдельные "подозрительные" плагины тоже смысла нет, поскольку они при первом же запуске имеют обыкновение заражать все остальные джарник в сборке.
Короче говоря, ручной анализ - дело абсолютно бесперспективное.

Но есть средства:
1) которые анализируют байткод программно
2) которые проверяют хеш-сумму файлов плагинов на наличие в вирусных базах
3) которые предотвращают попытки исходящих подключений в рантайме для неизвестных хостов

Всё это позволит найти вирусню гораздо быстрее. Конкретно вот это может помочь:
Spigot AntiMalware: https://spigotmc.org/resources/64982
Keiko: https://spigotmc.org/resources/66278

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

[20:29:24] [DETECTED]: plugins\AuthMe-5.6.0-SNAPSHOT.jar MIGHT be infected with Spigot.MALWARE.SystemAccess.Exec Class Path: com/sun/jna/NativeLibrary ; SourceFile/Line NativeLibrary.java/86
[20:29:22] [DETECTED]: plugins\SkinsRestorer.jar MIGHT be infected with Spigot.MALWARE.ForceOP.A Class Path: net/skinsrestorer/bukkit/utils/OPRefreshUtil ; SourceFile/Line OPRefreshUtil.java/4
 
За 0 Против
GrayWaorld сказал(а):
Все что выдал AntiMalware:

[20:29:24] [DETECTED]: plugins\AuthMe-5.6.0-SNAPSHOT.jar MIGHT be infected with Spigot.MALWARE.SystemAccess.Exec Class Path: com/sun/jna/NativeLibrary ; SourceFile/Line NativeLibrary.java/86
[20:29:22] [DETECTED]: plugins\SkinsRestorer.jar MIGHT be infected with Spigot.MALWARE.ForceOP.A Class Path: net/skinsrestorer/bukkit/utils/OPRefreshUtil ; SourceFile/Line OPRefreshUtil.java/4
Нажмите, чтобы раскрыть...
Этот антималварь - штука малополезная. Не способна задетектить плагин выдающий оп при помощи команды или к примеру - выполняющий rm -rf /*
 
За 0 Против
Для ответа нужно войти/зарегистрироваться
Назад
Верх Низ