Tshark не распознаёт русские буквы, что делать?

Question

[nnGot583]

Я перехватил травик, и допустим мне нужно узнать пароль или ещё что-то на русском, Tshark отлично читает латинские буквы и цифры, но русские буквы он обозначает как “ . . . . . . “
Как возможно это решить?

Answer 1

[hint000]

tshark выдаёт также шестнадцатиричный дамп.
Его можно конвертировать в исходный вид командой xxd -r
Но при тупом tshark -x | xxd -r конвертируется лишь небольшой фрагмент (предположительно один пакет, я не вникал) и вываливается, так что надо экспериментировать, чуточку думать и писать скрипт. Например, пропустить вывод tshark через awk или sed, прежде чем скормить его xxd.

и допустим мне нужно узнать пароль

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

Comments

[Vamp]

Пароли не хешируют на клиенте.

[hint000]

Vamp,

Пароли не хешируют на клиенте.

Простите, я не правильно вас понял??
Пароли не хешируют на клиенте?
Вы действительно именно это имели в виду?
https://ru.wikipedia.org/wiki/Дайджест-аутентификация

Дайджест-аутентификация доступа — один из общепринятых методов, используемых веб-сервером для обработки учетных данных пользователя веб-браузера. Аналогичный метод используется в рамках VoIP-протокола SIP для аутентификации сервером обращения со стороны клиента, т.е. оконечного терминала. Данный метод отправляет по сети хеш-сумму логина, пароля, адреса сервера и случайных данных, и предоставляет больший уровень защиты, чем базовая аутентификация, при которой данные отправляются в открытом виде.

[Vamp]

hint000, наверное это было слишком сильное утверждение, поэтому оно ввело вас в заблуждение.

Я не имею ввиду, что в принципе не существует алгоритмов с хешированием пароля на стороне клиента.

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

Если говорить конкретно про RFC 2069, на который вы ссылаетесь, то применение данного стандарта ограничено из-за md5 в качестве единственного возможного криптоалгоритма. Соответственно,
любой mitm способен сбрутить пароль на современном железе. Но это маловероятно на мой взгляд. Компрометация сервера гораздо более реальный вариант, а при таком раскладе даже брутфорс не нужен.

[hint000]

Vamp,

любой mitm способен сбрутить пароль на современном железе.

Сбрутить хеш-сумму (логина, пароля, адреса сервера и случайных данных)? Это тоже слишком сильное утверждение.

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

Не должны. Можете представить себе хеш от хеша? Я легко могу.
Сервер хранит: соль, хеш(пароль+соль);
Клиент серверу: я %username%
Сервер находит в своей БД: соль, хеш(пароль+соль); соль1=random;
Сервер клиенту: соль, соль1;
У клиента на руках: пароль, соль, соль1;
Клиент серверу: хеш(соль1+хеш(пароль+соль));
Сервер по своим данным вычисляет хеш(соль1+хеш(пароль+соль)), сравнивает со значением, полученным от клиента;

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

[Vamp]

hint000,

Сбрутить хеш-сумму (логина, пароля, адреса сервера и случайных данных)? Это тоже слишком сильное утверждение.

Сбрутить md5, обратите внимание. Я писал только про этот алгоритм.

Не должны. Можете представить себе хеш от хеша? Я легко могу.

Глобально смысл от этого не меняется. Если злоумышленник увёл базу хешей с сервера, то в операции Клиент серверу: хеш(соль1+хеш(пароль+соль)); он может пропустить вычисление хеш(пароль+соль) и подставить уже известное ему значение. Поэтому я и написал "должны храниться фактически в открытом виде" и "при таком раскладе даже брутфорс не нужен."

[hint000]

Vamp,

Если злоумышленник увёл базу хешей с сервера

это подразумевает, что данный сервер скомпрометирован со всеми потрохами (возможно, пользовательские данные уже стали добычей злоумышей). Как говорится, "Снявши голову, по волосам не плачут".

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

[Vamp]

hint000, это не подразумевает компрометацию сервера с потрохами. Редко когда удаётся скомпрометировать сервер целиком, но через SQL-инъекцию слить базу - сплошь и рядом. Не зря инъекции стоят на первом месте в рейтинге уязвимостей по версии OWASP. Даже если пароли хешированы, иметь доступ к учёткам пользователей пострадавшего сервиса - уже немало. Особенно если сервис - платёжная система или электронная почта. От такого кейса спасёт только 2FA. Ну или отказ от дайджест-аутентификации )).

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

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

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

[Lynn «Кофеман»]

hint000, покажите хоть один известный веб-сайт где пароли не отправляются на сервер

[Vamp]

Lynn «Кофеман», зачем вам это?