Недавно мы рассказывали про новые функции обеспечения информационной безопасности в свежем релизе Apache NiFi 1.14.0. В продолжение темы cybersecurity, сегодня рассмотрим пару внутренних уязвимостей с умеренной степенью серьезности. Читайте далее, чем опасно раскрытие конфиденциальных данных и значений параметров свойств процессора при переходе в режим отладки, а также как была устранена эта угроза.
Уязвимость чувствительных данных в Apache NiFi
Чтобы упростить свою ежедневную работу с Apache NiFi, при управлении процессорами дата-инженер может оптимизировать их конфигурации через параметризацию значений свойств. Эти свойства также можно настроить для хранения чувствительных значений. Например, с помощью процессора GetSFTP пользователь может извлекать файлы с сервера SFTP и создавать из них потоковые файлы (FlowFiles). При этом в пользовательском веб-интерфейсе Apache NiFi на вкладке настроек и свойств процессора виден список настраиваемых свойств: имя хоста, порт, имя пользователя, пароль и прочая важная информация.
Изначально свойства процессора могли содержать буквальные значения или переменные. При этом каждое свойство требовалось настроить для поддержки языка выражений в коде процессора. Но конфиденциальные параметры, такие как пароли, не поддерживали это из-за отсутствия механизма для защиты сохраненных значений переменных. В релизе Apache NiFi 1.10.0 подобные свойства могут быть помечены как конфиденциальные и защищенные в хранилище и через API без изменений в коде процессора. Благодаря этому свойство пароля можно установить как чувствительный параметр. После этого пароль зашифровывается, и в поле его значения в веб-GUI NiFi отобразится сообщение об этом.
В релизе 1.10.0 администратор NiFi может включить логирование на уровне отладки, чтобы определить, на какие входные данные свойств ссылаются один или несколько параметров, и убедиться, что синтаксический анализ выполняется правильно. Свойства могут иметь жестко заданные буквальные или параметризованные значения, например, парсер языка выражений платформы в режиме отладки org.apache.nifi.parameter.ExpressionLanguageAgnosticParameterParser выдаст следующий результат [1]:
For input #{my_password_parameter} found 1 Parameter references: [org.apache.nifi.parameter.ReferenceLocationPath@9876543e]
В этом сообщении не отображается конфиденциальная информация с чувствительными данными и не раскрывается имя параметра. Но если значение свойства не параметризовано, а жестко запрограммировано, лог будет выглядеть так:
For input thisIsABadPassword found 0 Parameter references: []
После ввода вместо формата параметра показывается текстовую фразу thisIsABadPassword, что указывает на пароль и является яркой уязвимостью системы безопасности. Таким образом, когда свойство процессора имело жестко запрограммированное значение, а не заданное параметром, логи печатали эту фразу открытом текстом. Таким образом, если пользователь набрал фактический пароль, пытаясь сослаться на параметр, и не нашел совпадения, в логе отобразится жестко закодированное значение открытого текста, т.е. пароль.
Подобная уязвимость с раскрытием конфиденциальных данных считается одной из главных угроз информационной безопасности. Эта ошибка, обнаруженная в релизе Apache NiFi 1.10.0, была исправлена в следующем выпуске в январе 2020 года [2]. Поскольку утечка данных появилась в логах, исправление заключалось в удалении строки logger.debug в 2-х классах синтаксического анализатора: ExpressionLanguageAwareParameterParser и ExpressionLanguageAgnosticParameterParser. Теперь ни один пользователь не сможет регистрировать конфиденциальные параметры. Однако, простое решение не всегда самое правильное и изящное. Что не так с устранением этой угрозы и как она влияет на удобство работы дата-инженера с Apache NiFi, мы рассмотрим далее.
Решение проблемы раскрытия конфиденциальных данных в логах
Итак, найденная уязвимость с раскрытием конфиденциальных данных была устранена путем изменения кода классов ExpressionLanguageAwareParameterParser и ExpressionLanguageAgnosticParameterParser. Поскольку эти модули не зависели от других, устранить найденную проблему было относительно легко. Удаление logger.debug позволило быстро предотвратить раскрытие конфиденциальных данных, но это лишило пользователей и разработчиков возможности просматривать нечувствительные параметры. Классы синтаксического анализатора перестали проверять, являются ли параметры чувствительными или нет, т.к. объекты анализа не знают об этом состоянии. Без этого синтаксический анализатор не может определить, какие параметры не должны отображаться. Таким образом, пока параметры не будут обрабатываться избирательно, логирование аналогично ведению журнала с ошибками [1].
Эта проблема связана с другой уязвимостью, когда механизм выполнения NiFi без сохранения состояния создавал выходные данные журнала, которые включали значения чувствительных свойств. При запуске потока распечатывалась JSON-конфигурация его определения, которая могла содержать конфиденциальные значения в виде открытого текста. Для смягчения рисков было реализовано безопасное хеширование Argon2, чтобы предоставить детерминированное регистрируемое значение, которое не раскрывает чувствительного свойства. Это исправление реализовано в августе 2020 года в релизе Apache NiFi 1.12.0 [3].
Еще больше полезных тонкостей администрирования и использования Apache NiFi для современной дата-инженерии вы узнаете на специализированных курсах для разработчиков, ИТ-архитекторов, инженеров данных, администраторов, Data Scientist’ов и аналитиков Big Data в нашем лицензированном учебном центре обучения и повышения квалификации в Москве:
Источники
- https://medium.com/apache-nifi-security/apache-nifi-sensitive-parameters-vulnerability-f10016aace22
- https://nifi.apache.org/security.html#CVE-2020-1928
- https://nifi.apache.org/security.html#CVE-2020-9486
