чит с подменой uuid
Как взламывают сервера в Minecraft
Привет, новый подраздел! Решил в честь открытия рассказать вам из личного опыта о том, как взламывали и взламывают сервера на RU Проектах!
Чтобы рассказать о более популярных методах взлома, я решил показать вам старый способ, очень древний.
Это на столько старый баг, что в то время существовал FalseBook.
Как всё работало:
1)Устанавливаем Nodus
2)Заходим в minecraft со стандартным ником (Своим)
3)Заходим на сервер, и смотрим ник модератора или админа
4)Выходим с сервера, запускаем во втором окне еще 1 minecraft
5)Заходим во вкладку Account Settings
6)Пишем слеш и ник админа или модератораПримерно так (/admin228 )
7)Заходим со второго minecraft на сервер со стандартным ником, ждем пока кикнет (Когда кикнет нечего не нажимать)
8)Когда кикнуло со второго аккаунта и пишем ( /op «свой ник» ) и выходим
9)Заходим с основного и у вас есть админка
Второй способ взлома админки (через табличку)
2)Выживаем, крафтим табличку, Ставим табличку на землю.
3)Пишем во второй строчке
Данная вещь уже по серьёзнее, и в свои времена трепала почти каждому третьему проекту нервы. Не только нервы, но и силы. Так как даже мы не понимали по началу каким образом ломали наши сервера.
Суть данного способа заключается в открытых портах, через которые подключался человек, после чего можно было творить всё что душе угодно. На самом деле способ тоже довольно старый, и я нашёл только способ его решения.
Ещё смешнее способ, суть его состоит в вшитом эксплоите в плагине. Точнее, в вшитой команде внутри плагина. Этим способом пользовались Ютуберы в Ру сегменте по майнкрафту, снимая «Сливы школо-серверов». Они загружали готовые сборки серверов на форумы по игре, загружали в эти сборки плагин, в котором сидел злой Эксплоит.
Список подобных команд, которые вшивали в плагины. После их выполнения выдавался полный доступ (в плагине Пермишенс выдавалась «*» эта звёздочка в плагине значит, что вам выдаются права на все команды)
/ncp delay op ник- выполняет команду от лица консоли
Minecraft Способы взлома серверов Minecraft, и способы их прикрытия
Добро пожаловать!
VipersMax
Гл. Администратор
Дисклеймер.
Способы взлома представлены (исключительно) в информативных целях. (нет)
Я не подталкиваю никого использовать эти способы, (Наоборот) так как возможно
вы понесете за них административное наказание. (Всем насрать)
Перейдем к описания каждого способа.
1. Взлом сервера, который использует связку BungeeCord используя «прямое» подключение к режимам игры, минуя лобби. (Через порты)
Действия «хацкера» : Взломщик, имея при себе лишь IP сервера сканирует его с целью найти открытые порты, находит, меняет в клиенте свой ник на ник админа, входит на сервер используя найденный порт минуя авторизацию (В том случаи если на сервере в режиме «Survival» (к примеру) не стоит плагин на авторизацию.
Описание: В конфиге spigot.yml на сервере жертвы, к которому вы пытаетесь подключится, значение параметра bungeecord выставлено на «true».
Эта опция по большей мере отвечает за факт передачи реального IP игрока при подключении к серверу, находящемуся в сети Bungee.
Если эта опция включена, то при попытке входа на сервер не через «Банжи» вы будете отключены. К сожалению (или нет), это обходится еще проще, чем вы могли себе представить.
Решение проблемы: ЗАКРЫТИЕ ПОРТОВ x2
3. Ломаем через порты, но нам преграждает путь плагин AuthMe.
Описание: Вы пытаетесь зайти под ником «одмена» и вам преграждает путь плагин на авторизацию.
Действия «хацкера» : Чтобы обойти авторизацию, хакер использует злополучную подмену UUID ( Universally Unique Identifier).
У каждого игрока имеется свой уникальные идентификатор (а-ля IP адрес). Всвязи с переходом на новую систему, многие плагины (в том числе и PermissionsEx)
перепилили свою структуру, отныне PEX определяет ваши права не по нику, а по UUID, в отличие от AuthMe. Иначе говоря, права теперь привязаны к UUID.
Через некоторые чит-клиенты имеют функцию подмены UUID. Подменив UUID свой, на админский вы получите его права. Например можно использовать невинный BungeeCord, который при подключении к серверу, где опция bungeecord установлена на true передаст серверу, тот UUID и IP адрес, который вы заставите его передать.
Решение проблемы: ЗАКРЫТИЕ ПОРТОВ x3
Действия «хацкера» : Если хакер обнаруживает, что ваш сервер пользуется «Кором», то он запускает локальный сервер с плагином ProxyConnector, и указывает в его конфиге IP адрес сервера, где стоит «Кор», и без лишних заморочек подключается к «Кору». Ну а дальше, соответственно отправляет команду на любой из подключенных серверов к «Кору», используя «sendcommand».
5. Ломаем, используя плагин с изначально встроенной взломкой.
Описание: Подсовываем плагин и изначально встроенной взломкой, админам сервера.
Действия «хацкера» : Хакер берет «полезный» плагин с изначально встроенной взломкой, и втирается в доверие к админам сервера, которые потом в последствии ставят плагин на сервер.
Решение проблемы: Не будьте так доверчивы.
6. Взлом не настроенного bungeecord.
Описание: Есть сервера, админы которых либо ленивые, либо не умеют настраивать bungeecord полностью, тем самым подвергая сервер взлому.
Решение проблемы: Всегда настраивайте Bungee полностью, иначе вы в опасности и + ЗАКРЫТИЕ ПОРТОВ x5
Софт:
НА все архивы пароль: lzt
Взлом сервера
Опки нефиг давать школьникам. Скорей всего банальная ситуация. Один из твоих Опов усановил их клиент и тупо сам отправил свой пароль злоумышленникам. Ну а дальше думаю объяснять не нужно что можно с опкой или повышенными правами с сервером сделать. Так что работай над безопасностью.
Опки нефиг давать школьникам. Скорей всего банальная ситуация. Один из твоих Опов усановил их клиент и тупо сам отправил свой пароль злоумышленникам. Ну а дальше думаю объяснять не нужно что можно с опкой или повышенными правами с сервером сделать. Так что работай над безопасностью.
нет, опок ни у кого нет. Единственный чел,у которого есть ‘*’, кроме меня и коллеги обладает неплохим паролем и ненастолько глуп, чтобы ставить этот клиент.
Список плагинов скинь, может смогу сказать больше.
Прикрепленные файлы
Ip в личку скинь проверю кое что.
Ip в личку скинь проверю кое что.
смотрел. раздал опки друзьям, заходил за ники администраторов (мой и коллеги) со своего ip. Видимо, как-то обошел авторизацию. Потом дал группе юзеров * в пермишенс и по традиции засетил спавн.
У меня тоже был случай, они же взломали. Проблема была в том, что один из совладельцев зашёл на какой то серв левый и спасил там пароль. Предположительно серв был именно вот этих героев. Ну и собсвенно зашёл под ним. так же опки раздал ну и как у тебя короч.
У меня тоже был случай, они же взломали. Проблема была в том, что один из совладельцев зашёл на какой то серв левый и спасил там пароль. Предположительно серв был именно вот этих героев. Ну и собсвенно зашёл под ним. так же опки раздал ну и как у тебя короч.
На других серверах у меня пароли другие. плагины со spigotmc в основном, часть с dev bukkit.
Узнайте у него, не качал ли он какие либо лаунчеры. Это позволит отсеять этот вариант.
Узнайте у него, не качал ли он какие либо лаунчеры. Это позволит отсеять этот вариант.
Обойти авторизацию невозможно. Скорей всего пароль был всё таки спален. Ладно, если всё будет очень плохо скиньте логи, будет время гляну. Может чем то да помогу. По данным что вы дали очень трудно установить причину(Если вы конечно не ванга), можно лишь предположить. На практике ещё не разу не сталкивался с тем, что бы серв был взломан каким то магическим способом. Дело всегда либо в кривой сборке, либо в сотрудниках сервера, которые пренебрегают правилами безопасности.
Не забывайте про подмену UUID (будь он неладен).
Обойти авторизацию невозможно. Скорей всего пароль был всё таки спален. Ладно, если всё будет очень плохо скиньте логи, будет время гляну. Может чем то да помогу. По данным что вы дали очень трудно установить причину(Если вы конечно не ванга), можно лишь предположить. На практике ещё не разу не сталкивался с тем, что бы серв был взломан каким то магическим способом. Дело всегда либо в кривой сборке, либо в сотрудниках сервера, которые пренебрегают правилами безопасности.
Не забывайте про подмену UUID (будь он неладен).
Слышал о таком способе. Не могли бы пояснить действия взломщика, подменяющего uuid? а то подробностей я не читал.
Слышал о таком способе. Не могли бы пояснить действия взломщика, подменяющего uuid? а то подробностей я не читал.
При создании сессии на сервер отправляется админский UUID. Спец.клиенты есть такие. А так как сейчас все плагины работают с UUID, а не никами, то наш герой получает админские права, вне зависимости от ника.
При создании сессии на сервер отправляется админский UUID. Спец.клиенты есть такие. А так как сейчас все плагины работают с UUID, а не никами, то наш герой получает админские права, вне зависимости от ника.
тогда как этого избежать?
тогда как этого избежать?
2. Сменить PEX на версию помоложе (которая UUID не использует).
Чит с подменой uuid
Описание
Ведущий плагин UUID all-in-one.
Блокировать пользователей, которые сменили свое название на просто проверка пользователи наименование историю или UUID.
UUID-это простой в использовании и легкий плагин, который будет проверять и показывать вам UUID игроков, чтобы вы могли использовать его для настройки недавно обновленных плагинов, поддерживающих UUID. Девайс может видеть ребенка прямо сейчас, но обновление выйдет! 🙂
Плагин очень легкий, и вы даже не будете знать, что он там! Производительность сервера не покажет разницы. Даже если вы думаете: «Мне это не нужно», все равно полезно установить его на свой сервер, потому что может наступить время, когда вам нужно будет проверить UUID игроков на наличие ссылок для вашего сервера — ну вот, теперь вы можете!
Вам действительно не нужно читать эту следующую часть.
Небольшая заметка о том, как я делаю свои версии обновлений:
V1.2.3 — 1 = Когда я переделываю плагин или делаю массовое обновление. 2 = Когда я добавляю новую функцию (Количество функций, добавленных corrspands к заданному числу) 3 = Количество ошибок/проблем, которые я исправил | So V2.4.21 = Я переделал плагин 1 раз (V1.0-это только первый выпуск плагина) Я добавил 4 новые функции с момента запуска нового капитального ремонта (V2) и исправил 21 проблему/ошибку с момента запуска капитального ремонта (V2)
Особенности:
Очень легкий плагин.
Проверьте UUID игрока быстро и легко.
Полная поддержка консоли.
Автоматическое обновление.
Как генерируются UUID
Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.
Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.
Теория
UUID (universally unique IDentifier) — это 128-битное число, которое в разработке ПО используется в качестве уникального идентификатора элементов. Его классическое текстовое представление является серией из 32 шестнадцатеричных символов, разделённых дефисами на пять групп по схеме 8-4-4-4-12.
Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:
Значения на позициях M и N определяют соответственно версию и вариант UUID.
Версия
Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:
Вариант
Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.
Мы определяем его по первым 1-3 старшим битам на позиции N.
1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B
Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.
Версия 1 (время + уникальный или случайный идентификатор хоста)
В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).
Идентификатор получают с помощью конкатенации 48-битного МАС-адреса, 60-битной временной метки, 14-битной «уникализированной» тактовой последовательности, а также 6 битов, зарезервированных под версию и вариант UUID.
Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.
Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.
Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.
Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.
Сборка UUID версии 1 происходит так:
Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.
Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.
Версия 2 (безопасность распределённой вычислительной среды)
Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.
Версия 3 (имя + MD5-хэш)
Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.
Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.
Обратите внимание, что namespace сам по себе является UUID.
В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.
Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.
При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.
Версия 4 (ГПСЧ)
Самая простая реализация.
6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.
Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.
В современных языках чаще всего используются UUID версии 4.
Её реализация достаточно простая:
Версия 5 (имя + SHA-1-хэш)
Единственное отличие от версии 3 в том, что мы используем алгоритм хэширования SHA-1 вместо MD5. Эта версия предпочтительнее третьей (SHA-1 > MD5).
Практика
Одним из важных достоинств UUID является то, что их уникальность не зависит от центрального авторизующего органа или от координации между разными системами. Кто угодно может создать UUID с определённой уверенностью в том, что в обозримом будущем это значение больше никем не будет сгенерировано.
Это позволяет комбинировать в одной БД идентификаторы, созданные разными участниками, или перемещать идентификаторы между базами с ничтожной вероятностью коллизии.
UUID можно использовать в качестве первичных ключей в базах данных, в качестве уникальных имён загружаемых файлов, уникальных имён любых веб-источников. Для их генерирования вам не нужен центральный авторизующий орган. Но это обоюдоострое решение. Из-за отсутствия контролёра невозможно отслеживать сгенерированные UUID.
Есть и ещё несколько недостатков, которые нужно устранить. Неотъемлемая случайность повышает защищённость, однако она усложняет отладку. Кроме того, UUID может быть избыточным в некоторых ситуациях. Скажем, не имеет смысла использовать 128 битов для уникальной идентификации данных, общий размер которых меньше 128 битов.
Уникальность
Может показаться, что если у вас будет достаточно времени, то вы сможете повторить какое-то значение. Особенно в случае с версией 4. Но в реальности это не так. Если бы вы генерировали один миллиард UUID в секунду в течение 100 лет, то вероятность повторения одного из значений была бы около 50 %. Это с учётом того, что ГПСЧ обеспечивает достаточное количество энтропии (истинная случайность), иначе вероятность появления дубля будет выше. Более наглядный пример: если бы вы сгенерировали 10 триллионов UUID, то вероятность появления двух одинаковых значений равна 0,00000006 %.
А в случае с версией 1 часы обнулятся только в 3603 году. Так что если вы не планируете поддерживать работу своего сервиса ещё 1583 года, то вы в безопасности.
Впрочем, вероятность появления дубля остаётся, и в некоторых системах стараются это учитывать. Но в подавляющем большинстве случаев UUID можно считать полностью уникальными. Если вам нужно больше доказательств, вот простая визуализация вероятности коллизии на практике.