Замечание к документу "Вопрос конечно интересный... (+)"   >>>

Тема: прошу прощения что так поздно, но все таки...

22.02.2002 17:49:37 Alex G. Taranenko написал:

> Это конечно не бага, но уязвимость.
> Социальная инженерия штука опасная...

> Ее недооценивать нельзя.

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

> Сама по себе возможность определить почтовый файл конкретного
> пользователя как бы и не страшна, но в купе с другими слабостями Domino и не
> брежностью пользователей...
предлагаю разделить небрежность пользователей и слабости domino. отдельно выделить "слабости" и лень админа.

>
> Позволю себе пофантазировать.
> Читаю я в рассылке что ЗАО СуперСтрой внедрило новую систему документооборота
> на Lotus Notes\Domino и презентовало свой портал. Круто! ЗАО СуперСтрой...

предлагаю реальную компанию - ЗАО "КубаньGSM". документооборот не внедрили, но вебсайт сделали. сайт www.kubangsm.ru

> Ба, да это же контора в которой работает менеджером мой сосед Вася Пупкин!
> Здорово! Сейчас он у меня ответит за своего помешаного ротвелера который
> покусал меня месяц назад... Что мне для начала нужно?
> 0. Адрес представительства ЗАО СуперСтрой (url в рассылке)
> 1. Путь и название почтового файла
> 2. Логин
> 3. Пароль

> Захожу на сайт ЗАО СуперСтрой...
> Первое (до гадалки не ходи!) будет \mail\vpupkin.nsf (или вариации) [уязвимость
> №1]
> В качестве второго (каким бы нибыл шортнейм) я могу _также_ использовать
> фамилию!
> Т. е. Pupkin.(уязвимость №2 - и еще какая!)
> Таким образом из 3 необходимых компонент я _сразу_ знаю 2!
>

0. www.kubangsm.ru

1.на выбор пользователя. по умолчанию вы предположите rvarenik.nsf. и будете правы. теперь вы можете получить к нему доступ.

2. логин у него rodion. почта соответсвенно rodion@kubangsm.com (особенности компании, на почте другой домен)

> А пароль...
> Может ему админ и поставил нормальный пароль на авторизацию с web, но ведь он
> 99% самостоятельно
> сменил его на удобный _ему_!

мой случай не является показателем, у меня пароль почему то большой, но все таки - можно вопрос? КАК простой смертный может поменять себе пароль для доступа через WEB ? у меня пользователи конечно дикие, и с лотусом работают мало, но и в предыдущей компании менять могли только через админа. если я у себя ВДРУГ решу дать им такую возможность - это будет отдельное приложение, типа шаблонного от ириса по регистрации веб-пользователей. и там, я гарантирую, будет и контроль длины, и анализ по предыдущим паролям, и срок жизни.

> А умник админ ни сном ни духом [уязвимость 3]...
> Можно конечно сначала попробовать 12345, фамилию или дату рождения...
> Но я знаю что он обожает своего долбаного ротвеллера, и я набираю "Спайк"...

эх, сказал бы я пароль свой, не буду, лишнее :)

> Вот и все! Осталось порытся в его почтовом ящике и отослать свежий
> маркетинговый план от его имени всем конкурентам...
> Вот такая, блин, социальная инженерия... :((
> При такой схеме вся безопасность при доступе с web'а ложится на пароль который
> завел себе пользователь. Я считаю что это не есть правильно.
не совсем корректный пример, но если мне пришло письмо pupkin@mail.ru то я знаю

0. url - mai.ru

1. путь и название почтового файла - не нужно

2. логин - pupkin

3. пароль - как и в описанном вами случае.

подводим итог - Domino не хуже.

> Насчет уязвимости №1 - я понимаю что здесь все зависит от админа, и он может

[skip]
> Конечно можно и самому подобное слепить, но лучше чтобы это был _штатный_
> механиз с возможность вклчения его в задачу биллинга.

на notes.net есть пример базы для централизованного входа.
>
> Насчет уязвимости №2 - я считаю что Lotus'у обязательно необходимо закрыть
> при авторизации через web возможность использования нескольких вариантов login
> name ( среди которых last name ).
> Для авторизации должен использоватся только short name, и он не должен быть
> слишком интуитивным!
не принципиально, смотри пример с mail.ru

> Насчет уязвимости №3 - _Факт_ самостоятельной смены пользователем пароля (да
> еще и для web-авторизации) должен становится известен админу, а возможно и
> проходить с некоторым его участием.

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

> Классно было бы иметь _штатный_ механизм проверки паролей для web-авторизации
> на "стойкость" в момент когда пользователь его вводит.
я программер, мне проще написать систему для ведения паролей пользователей под веб :) не за 100$ но можно :)

> To All:
> Если я в чем то ошибаюсь просьба не пинать, а поделится опытом.

опыт у меня не большой, но я делал исходя из свой задач, в результате

1. у меня 3 сервера, 1 во внутренней, 2 - во внешней сети. почта пользователей соответственно лежит во внутреннем. так что искать мыльные ящики на www.kubangsm.ru можно, но большого смысла нет.

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

3. если говорить о закрытии рассылки из ящика то можно просто установить корпоративную политику типа "через веб только читать", проставить соответствующий крыжик в ACL и будь ты хоть трижды менеджер базы - доступ к ней из веба ты получишь только на чтение.

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