Небезопасное хранение паролей в IBM WebSphere

[McKinseyBA]

Жаль, что это не обнаружилось полгода назад, когда на текущей работе рассматривали WS в качестве одного из элементов IT-stack — поржал бы на переговорах с IBM)

PS: автору — респект за находку

[BigD]

а что выбрали вместо?

[McKinseyBA]

Apache + Magento + аналогичного_уровня_все_остальное_тк_по_факту_порезали_бюджет

PS: надеюсь ответил на вопрос ибо сам ни разу не архитектор системы

[Diman_krd]

В версии 9 пароли будут шифроваться AES с ключом "_" :)

[dikkini]

Обнаружилось пару лет назад… Интернет полон ссылками на эту инфу.

[egmar]

В документации явно написано об этом методе. Да и менять альгоритм можно www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/tsec_enable_custpass_encrypt.html

[mirwide]

В документации описано, но хотелось показать подробнее что они имели в виду под xor. По ссылке описаны возможность создания и включения своего алгоритма путем реализации интерфейса com.ibm.wsspi.security.crypto.customPasswordEncryption. Полезная фича, но хотелось бы другого.

[ehabarov]

За эту «багофичу» IBM пинают регулярно.
В принципе, можно встроить свой код шифрования паролей, «точка входа» предусмотрена.
Пруф: Enabling custom password encryption

В версии 8.5 (Liberty Profile) появилась возможность «из коробки» кодировать пароли в режиме aes и hash.
Пруф: securityUtility command.

Насколько я понимаю, позиция IBM такова, что кодирование пароля не особо повышает защищенность, если есть возможность доступа к файловой системе сервера.
Статьи на эту тему:
The limits to protection through password encryption.
Comment lines: Encrypting WebSphere Application Server system passwords — if you insist.

[Vovanys]

В 8.5.5 есть еще прикольнее баг. Создаешь юзера с ролью монитора, а он может грузить приложения как админ (в других сферах нету такого). Пока по PMR ответа нету)

[ehabarov]

Проблема хранения паролей для доступа к ресурсам гораздо более глобальная.

Вот навксидку выдержка для Apache Tomcat: Why are plain text passwords in the config files?

When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured — but not really protected. Please see the user and dev list archives for flame wars about this topic.

That said, any configuration file that does contain a password needs to be appropriately secured. That means limiting access to the file so that it could be read only by the user that Tomcat process runs as and root (or the administrator on Windows).

[mirwide]

Tomcat можно простить, он бесплатен и опенсорсен. У него другая ниша. Надеюсь не кто не вибирает его для платформы под банковский процессинг. А если кто-то выбирает, он готов дописать.

[ehabarov]

Применение более сильного кодирования не решает проблему, а только ее маскирует, создавая ложное чувство «защищенности». Правильное решение — ограничение доступа к файловой системе сервера(ов)

[MaximChistov]

Если кто-то уже в файловую систему вашего сервера пролез, какое-то доп шифрование мало поможет )

[mirwide]

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

[ehabarov]

А можно подробнее, как это реализовано в WebLogic?

Системы на IBM WAS нормально проходят аудит, что говорит о том, что «проблема» так или иначе решаема.
В статьях по приведенным выше ссылкам это тоже описано.

PS: А зачем «пользователю» доступ на чтение к файлам конфигурации сервера приложений?

[mirwide]

Про Weblogic точно не расскажу, знаю только что есть AES, где и какой ключ узнаю как забуду пароль. Аудит можно пройти с чем угодно. Аудиторы за частую не обладают достаточной компитенцией. Даже опытные сотрудники ИБ могут не знать разные «приятные» фичи.
Вариантов доступа может быть множество: операторы, бэкап, пользователи с правом только установки приложений. И даже если пользователь админ на сервере, он не должен получать пароли от базы и веб сервисов так легко. Понятно что шифрование защита «от дурака», но и она должна быть. Это ни сколько не исключает ограничение доступа на уровне файловой системы.

[ehabarov]

Не спорю, но еще раз резюмирую варианты.

Для WebSphere Application Server 6.1, 7.0, 8.0, 8.5 (Full Profile) есть XOR (для system i есть еще платформенный алгоритм OS400), и можно написать свой класс, чтобы реализовать другие варианты кодирования паролей.

Для WebSphere Application Server 8.5 (Liberty Profile) дополнительно реализованы алгоритмы AES и HASH(PBKDF2WithHmacSHA1).

[sergey-b]

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

[ehabarov]

Про WebLogic мне сообщили следующее:

WebLogic шифрует AES-ом, но все нужное для расшифровки хранит локально.
Есть скрипт на Jython-е, позволяющий расшифровать.
Справедливости ради, надо сказать, что можно не шифровать пароль, а вводить при старте с консоли.

[sergey-b]

Используйте методы аутентификации, не требующие явного указания паролей.

[sergey-b]

Скрипт для шифрования-расшифрования паролей входит в поставку вебсферы. Называется PropFilePasswordEncoder.bat. Лежит в каталоге bin.

[sergey-b]

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