информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСтрашный баг в WindowsЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
 Рекордное число уязвимостей в 2021 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Пока нет SSL... 14.05.06 19:45  Число просмотров: 1946
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Прошу помочь немного подсказать, как залатать уязвимости протокола что ниже. SSL пока не сделан в тестовой версии. Сделаю, если дело дойдёт до продакшн.

Задача:
У меня есть приложение, состоящее из БД (неважно какая) + server, который слушает Интернет (кастом протокол) + клиент, который должен просить server обратиться к БД и выполнить некоторую работу. БД - в локалке. Server там же, но слушает на внешнем интерфейсе. Клиент - может быть в Африке.

Пока всё это хозяйство тестируется (несекурные информационные бизнес процессы).
Как лучше построить проверку подлинности клиента, если, данные, передаваемые клиентом серверу несекретные, но надо быть уверенным, что именно наш клиент коннектится к серверу, и посылает всяческие команды? Если дело дойдёт до продакшен, то заменю то, что ниже на SSL. Пока нет SSL, я склепал простой протокол для аутентификации клиента? О чём и речь ниже.


Если кто-то захочет помочь и высказаться, то:

I). О протоколе:

Используется TCP. После аутентификации происходит передача одной команды серверу и соединение закрывается. Если надо выполнить другую команду, то клиент должен начать всё сначала, выполнить "серверный пакет" в пределах одного TCP соединения (в терминах TCP). Ожидается, что в день клиент будет посылать один-два "серверных пакета" (здесь "пакет" = аутентификация + команда).

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

II). О «не нашем человеке» по середине. Он умеет:

1) создавать "сырые" пакеты, иногда предугадывая seq # TCP, пересчитывая конторольные суммы, и т .д. Таким образом он может "влезать" в соединения, подменяя пакеты клиента или сервера искажёнными данными. Может посылать повторные пакеты – копии пакетов от настоящего клиента.
2) может находится на маршрутиризаторе, как встроенное враждебными силами ПО. Получив IP пакет, он может его отправить далее искажённым серверу и клиенту.
3) знает спецификацию данного кастом протокола.

III). Спецификация:

Сервер может определить из БД сохранённый hash (userpasswod) hPwd для клиента username. Клиент его вычисляет hPwd.

1) КЛИЕНТ посылает:
- username (как есть);
- challenge_1 (случайная последовательность байт)
- переходит к п.3, см. ниже.

Клиент хочет первым проверить подлинность сервера, чтоб сервер ответил на clallenge_1 значением hash_1 = hash ( clallenge_1 + hPwd ). Если клиент не получит такого результата сразу после этого пакета, то соединение будет им завершено.

2) СЕРВЕР получив данные username и challenge_1 выполняет следующее:
- вычисляет "ответ" hash_1 = hash( challenge_1 + hPwd ) на challenge_1 клиента;
- создаёт для клиента свой challenge_2 (случайная последовательность байт);
- посылает клиенту ответ на его challenge_1 в виде hash_1, и при этом посылает свой challenge_2;

Т.е. сервер делает две вещи. Он отвечает клиенту на clallenge_1 значением hash_1. Одновременно он просит клиента, в свою очередь, подтвердить подлинность ответом на challenge_2.
Сервер хочет, чтоб клиент ответил ему на clallenge_2 значением hash_2 = hash ( clallenge_2 + hPwd ). Если он не получит такого результата в следующем от клиента пакете, то соединение будет завершено сервером.

3) КЛИЕНТ проверяет подлинность сервера. Он сверяет полученный от сервера hash_1 со значением, рассчитываемым по challenge_1 и userpassword. Если ожидания клиента по п.1. не выполнены, т.е. если hash_1 != hash (challenge_1 + hPwd), то это не "наш" сервер. Тогда заканчиваем. Иначе клиент готовит “полезную команду”, п.4.

4) Клиент готовит и отправляет пакет серверу:
- вычисляет hash_2 = hash (challenge_2 + hPwd) (это удостоверение подлинности клиента для сервера, здесь challenge_2 – тот чалендж, что был получен от сервера);
- включает в пакет несекретные коды команд серверу, который сервер будет выполнять (полезные команды).
- вычисляет контрольную сумму, которую включает в заголовок пакета. Контрольная сумма рассчитывается по значению последовательности байт всего пакета (заголовков и команд) + hash_1 + hPwd, которые потом отбрасываются перед отправкой.

5) СЕРВЕР сравнивает полученный hash_2 с вычисляемым значением hash_2_srv = hash( challenge_2 + hPwd ) . Это будет служить проверкой подлинности клиента. Если hash_2_srv == hash_2, то сервер, считает, что это "наш" клиент. Иначе сервер закрывает соединение. Далее от проверяет контрольную сумму, добавляя к полученному пакету сохраненное с начала соединения значение hash_1, и hPwd. Если CRC OK, выполяется команда клиента. CRC должна гарантировать целостность данных.


Спасибо.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach