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

По работе часто сталкиваюсь с продуктами IBM: WebSphere Application Server (WAS) и другими на его основе. И как и все иногда забываю пароли, в особенности это касается тестовых систем или тех, которым не уделяешь должного внимания.

В очередной раз не вспомнив пароля, решил посмотреть, а как его хранит наш сервер приложений. Проанализировав несколько файлов конфигурации, таких как security.xml, wimconfig.xml и resources.xml обнаружил все пароли когда-либо введённые в консоли администрирования, в том числе и пароль главного админа. Хранились они во вполне безобидном на первый взгляд виде.

serverPassword="{xor}KD4sPjsyNjE="


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

если a ⊕ b = c, то a ⊕ c = b

… нашёл ключ для той системы, где пароль известен:

283E2C3E3B323631 ⊕ 77617361646D696E = 5F(ASCII код _)

Конечно же он всегда одинаков, то есть пароль хранится фактически отрытым текстом, xor на _ не скрывает его даже от пользователей не понимающих ничего в шифровании. Напомню, что так хранятся все пароли: для хранилищ ключей, для доступа к Active Directory, для доступа к базе, которая ввиду специфики использования WAS зачастую хранит информацию, доступ к которой должен быть максимально ограничен. Любой, получивший доступ к файлам конфигурации, становится автоматически администратором сервера приложений и получает пароли от баз данных и других ресурсов.

Продукты линейки WebSphere достаточно дороги и недоступны малым и даже средним компаниям. Например, на сегодняшний день лицензия WAS для среднего 2-х сокетного сервера x86 стоит порядка $200 000, WebSphere Portal в несколько раз дороже. Обычно его не ставят на x86, для RISC лицензия стоит ещё дороже. В основном их используют в госорганах и банковской сфере, а в таких организация требования к безопастности особые, например, разделение ролей (администратор ОС, БД, сервера приложений). В такой ситуации это технически нереализуемо.

Написал небольшой скрипт, чтоб «вспоминать» пароли на лету.

import base64

char = ''

input = raw_input("Enter: ")

data = base64.b64decode(input)

for character in data:

    hex_char = hex(int(character.encode('hex'), 16) ^ int('_'.encode('hex'), 16))[2:]

    char = char + hex_char.decode('hex')

print 'Password:', char

Алгоритм неизменен во всех версия WAS, включая самую последнюю 8.5.5 и во всех продуктах на его базе: Portal Server, BPM, ESB и другие. Надеюсь, в версии 8.6 или хотя бы 9 пароли будут шифроваться AES.
Поделиться публикацией
Комментарии 22
    +3
    Жаль, что это не обнаружилось полгода назад, когда на текущей работе рассматривали WS в качестве одного из элементов IT-stack — поржал бы на переговорах с IBM)

    PS: автору — респект за находку
      0
      а что выбрали вместо?
        0
        Apache + Magento + аналогичного_уровня_все_остальное_тк_по_факту_порезали_бюджет

        PS: надеюсь ответил на вопрос ибо сам ни разу не архитектор системы
      +6
      В версии 9 пароли будут шифроваться AES с ключом "_" :)
        0
        Обнаружилось пару лет назад… Интернет полон ссылками на эту инфу.
          +2
          В документации явно написано об этом методе. Да и менять альгоритм можно www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/tsec_enable_custpass_encrypt.html
            0
            В документации описано, но хотелось показать подробнее что они имели в виду под xor. По ссылке описаны возможность создания и включения своего алгоритма путем реализации интерфейса com.ibm.wsspi.security.crypto.customPasswordEncryption. Полезная фича, но хотелось бы другого.
            +1
            За эту «багофичу» 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.
              0
              В 8.5.5 есть еще прикольнее баг. Создаешь юзера с ролью монитора, а он может грузить приложения как админ (в других сферах нету такого). Пока по PMR ответа нету)
                +4
                Проблема хранения паролей для доступа к ресурсам гораздо более глобальная.

                Вот навксидку выдержка для 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).
                  –2
                  Tomcat можно простить, он бесплатен и опенсорсен. У него другая ниша. Надеюсь не кто не вибирает его для платформы под банковский процессинг. А если кто-то выбирает, он готов дописать.
                    +2
                    Применение более сильного кодирования не решает проблему, а только ее маскирует, создавая ложное чувство «защищенности». Правильное решение — ограничение доступа к файловой системе сервера(ов)
                  +1
                  Если кто-то уже в файловую систему вашего сервера пролез, какое-то доп шифрование мало поможет )
                    0
                    Дело не в атаке, а разделении прав. Если пользователь имеет readonly права на конфиг, мне не хотелось бы чтоб он получал еще доступ ко всем отстальным ресурсам. Для атаки это ерундовая защита, один лишний шаг, чтоб извлечь пароль из памяти и в любом случае мы храним ключ на этом же сервере.
                    Если это будет реализованно как в WebLogic вполне достаточно, потому что если пароль открытым текстом, это повод даже чисто формально WAS не использовать в некоторых областях.
                      0
                      А можно подробнее, как это реализовано в WebLogic?

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

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

                          Для 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).
                            0
                            В Weblogic точно так же в xml файлах лежат открытые пароли. Так гораздо честнее, чем делать вид, что пароли якобы защищены. Администратор знает, какие файлы надо беречь от посторонних глаз. А системы, где пароли как бы зашифрованы, дают ложное ощущение безопасности. Владелец ресурса думает, что пароли посторонним недоступны, а взломщик, который знает детали реализации, достает их в два счета.
                              0
                              Про WebLogic мне сообщили следующее:
                              WebLogic шифрует AES-ом, но все нужное для расшифровки хранит локально.
                              Есть скрипт на Jython-е, позволяющий расшифровать.
                              Справедливости ради, надо сказать, что можно не шифровать пароль, а вводить при старте с консоли.
                        0
                        Используйте методы аутентификации, не требующие явного указания паролей.
                          0
                          Скрипт для шифрования-расшифрования паролей входит в поставку вебсферы. Называется PropFilePasswordEncoder.bat. Лежит в каталоге bin.
                            0
                            Единственный вариант безопасного хранения паролей — шифровать их ключом, который запрашивается при запуске. В этом случае пароль будет лежать в открытом виде только в памяти. Но тогда теряется возможность автоматического перезапуска сервера в случае аппаратных или системных сбоев.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое