Cloud Key не проходит проверку PCI-DSS.

Cloud Key не проходит проверку PCI-DSS., UniFi Network

davork

Guest

13.01.2017 16:47:00

Привет! Cloud Key Firmware UCK.mtk7623.v0.5.9.6794855.161129.1409

У нас два объекта: на одном статический IP и cloud key, и мы хотим объединить всё оборудование Unifi под одним выделенным cloud key.
Для этого добавили правило в файрволле, чтобы разрешить запросы inform от оборудования Unifi на удалённом объекте.
Но, как оказалось, версия Tomcat на CloudKey — именно та, которую PCI-DSS квартальный сканер, который мы обязаны проходить, считает высокой угрозой.

Ниже — детали провала по PCI-DSS тесту.
Есть идеи? Подозреваю, что скоро найдут, что смена порта проблему не решит.

Спасибо,
Том

СВОДКА УГРОЗ (THREAT REFERENCE):

Уязвимая версия Apache Tomcat: 7.0.70
Риск: высокий (3)
Порт: 8080/tcp
Протокол: tcp
ID угрозы: web_dev_tomcatver

Подробности: Уязвимость XSS на странице ошибки 404
Дата: 21.12.2009
Apache Tomcat подвержен XSS-уязвимости, так как не очищает корректно ввод пользователя.
Злоумышленник может использовать это для выполнения произвольного скрипта в браузере ничего не подозревающего пользователя на сайте, который работает на этом сервере.
Множество исправлений в версиях 6.0.47, 7.0.72, 8.0.38, 8.5.6 и 9.0.0.

CVE: 2016-0762, 2016-5018, 2016-6794, 2016-6796, 2016-6797

Версии Apache Tomcat с 6.0.0 до 6.0.45, 7.0.0 до 7.0.70, 8.0.0.RC1 до 8.0.36, 8.5.0 до 8.5.4, и 9.0.0.M1 до 9.0.0.M9 имеют несколько уязвимостей:

- Атака по времени из-за ошибки в процессе аутентификации Tomcat Realm.
- Обход Security Manager путём манипуляции параметрами конфигурации для JSP сервлета или через служебные методы Tomcat.
- Раскрытие системных свойств из-за ошибок в механизме замены свойств в конфигурационных файлах Tomcat.
- Неограниченный доступ к глобальным ресурсам из-за ошибки в ResourceLinkFactory.
- Уязвимость в init-скрипте Apache Tomcat (19.09.2016) — возможное локальное повышение привилегий по причине небезопасной работы с файлами логов.
- Проблема HTTP_PROXY (httpoxy) — уязвимость, позволяющая злоумышленникам с помощью специально сформированного HTTP Proxy заголовка перенаправлять исходящий HTTP-трафик приложения через произвольный прокси.

Информация с цели:
Сервис: 8080/TCP

[Вывод ошибки сервера Apache Tomcat/7.0.70]

---

Если коротко: ваша версия Tomcat устарела и уязвима, что вызывает серьезные проблемы с безопасностью по требованиям PCI-DSS. Переключение порта — это лишь временная мера, лучше обновить прошивку или заменить Tomcat на безопасную версию.

vConsulting

Guest

30.08.2017 06:23:00

Наверное, потому что это было бы абсолютно и полностью бесполезно с самоподписанными сертификатами, которые никак нельзя проверить. Или, ну знаете, можно купить сертификат или, как обычно, люди, которым нужна соответствие PCI-DSS, обычно имеют собственную инфраструктуру PKI... И как это решит проблему? Всё равно придётся ОТКЛЮЧИТЬ любое проверку сертификатов в inform по умолчанию, иначе inform будет полностью сломан и ничего не будет работать.

Очевидно, мы не выходим за рамки привычного, потому что такие механизмы изначально не были включены. Если бы были, это было бы довольно просто: доверенный (или корпоративно доверенный) центр выдаёт цепочку сертификатов, которая потом устанавливается на устройство перед дальнейшей настройкой, включая доверенные сертификаты, которые уже были развернуты на Cloud Key или Cloud Controller для inform.

Я упрощаю и пропускаю несколько шагов процесса, но мне кажется, что тут всё предельно ясно: «Точка А» ведёт к «Точке Б», которая ведёт к «Точке В», и в итоге — желаемый результат.

Главное, что это можно сделать и уже делалось. Да, для этого нужно больше, чем просто комплект UBNT, но такой сценарий довольно специфичный.

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

Я на этом и остановлюсь.

Вот именно! Это может быть «старая» тема, которую я достал, и может касаться старой версии ПО CloudKey, но проблема по-прежнему существует!

Спасибо, AvalonDanvers!

С наилучшими пожеланиями, Даниэль...

doktornotor

Guest

28.08.2017 07:24:00

Дизайн стека Java-монстра уже убил всю линейку продуктов mFi. Я всё ещё надеюсь, что где-то в глубине кто-то занимается перепроектированием всей системы управления, используя нормальные инструменты. Такие, которые не подразумевают Tomcat, тухлую MongoDB — и, честно говоря, такие, что вообще не связаны с Java.

AvalonDanvers

Guest

28.08.2017 03:03:00

Наверное, потому что это было бы абсолютно и полностью бесполезно с самоподписанными сертификатами, которые никак нельзя проверить. Или, знаешь, можно купить сертификат, или, как обычно, у большинства, кому нужна соответствие PCI-DSS, уже есть своя PKI…

И как это решит проблему? Всё равно придётся по умолчанию отключать проверку сертификатов для inform, иначе inform полностью сломается и ничего не будет работать.

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

Я упрощаю и пропускаю несколько шагов процесса, но это потому, что как будто пишешь: «Пункт А» ведёт к «Пункту Б», который ведёт к «Пункту В» и в конце — к желаемому результату.

Суть в том, что это можно сделать, и это уже делалось. Да, это требует больше, чем просто набор от UBNT, но такой кейс довольно специфичный.

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

На этом я и остановлюсь.

doktornotor

Guest

28.08.2017 01:24:00

Вероятно, потому что это было бы абсолютно и полностью бесполезно с самоподписанными сертификатами, которые никак не проверить. Либо, знаете, можно купить сертификат, либо, как всегда, большинство людей, которым нужна соответствие PCI-DSS, уже имеют свою собственную PKI... И как это тогда решит проблему? Всё равно придётся по умолчанию ОТКЛЮЧАТЬ проверку сертификатов для inform, иначе inform будет полностью сломан и ничего не будет работать.

AvalonDanvers

Guest

27.08.2017 23:27:00

Наверное, потому что это было бы абсолютно и совершенно бесполезно с самоподписанными сертификатами, которые никак не проверить. Или, знаете, можно купить сертификат, а как обычно, большинство людей, которым нужна соответствие PCI-DSS, уже имеют собственную PKI...

doktornotor Guest	#7 27.08.2017 08:59:00 Наверное, потому что это было бы совершенно и полностью бесполезно с самоподписанными сертификатами, которые никак нельзя проверить.

AvalonDanvers

Guest

27.08.2017 07:41:00

Ага, значит, это из тех случаев. Я читал интересную статью про NESTы и передачу зашифрованных данных по незащищённому соединению. Сегодня шифрование — настолько простая вещь, что я не понимаю, почему UBNT не шифрует соединение для inform. Такое ощущение, что это явно упущение в плане «лучших практик».

dpurgert

Guest

26.08.2017 10:35:00

Да, порт информирования не зашифрован (http), но полезная нагрузка там зашифрована; так что всё равно «безопасно™». Хотя, с другой стороны, я давно уже не запускал Wireshark, может, стоит проверить ещё раз... а пока надо найти свободный UAP 😀

AvalonDanvers

Guest

#10

26.08.2017 10:14:00

Видимо, я выкопал «старый» пост, и да, мы уже на версии 0.7.3, но уязвимость XSS всё ещё, похоже, присутствует. Интересно будет почитать реакцию UBNT на то, что в механизме информирования, который используют для настройки инфраструктуры Unifi, до сих пор есть давно известные дыры, даже если

@vConsulting

тоже выкопал древний пост. Однако, с другой стороны: почему Cloud Key получает прямой доступ к инфраструктуре, соответствующей PCI-DSS? Тут уже два серьёзных вопроса: во-первых, это Apache Tomcat — у него, кажется, каждый день появляется новая уязвимость, а во-вторых — и пусть меня кто-нибудь поправит, если я ошибаюсь, но URL информирования передаётся в открытом виде (по моим сведениям, именно поэтому Cloud Key или Cloud Controller используют порт 8080). Это не совсем лучшие практики для PCI-DSS. Просто к сведению — эта тема занимает четвёртое или пятое место в поисковике Google, если искать информацию о соответствии PCI-DSS на Apache Tomcat. А материалы, что идут выше, — это актуальные статьи о том, как обеспечить соответствие PCI-DSS на последней версии Apache Tomcat.

vConsulting Guest	#11 26.08.2017 06:31:00 Похоже, я наткнулся на «старый» пост, и да, сейчас у нас уже версия 0.7.3, но уязвимость XSS, похоже, до сих пор присутствует.

dpurgert Guest	#12 25.08.2017 20:29:00 Имейте в виду, что @vConsulting откопал пост с января...

cainmp Guest	#13 25.08.2017 20:21:00 Не говоря уже о том, что прошивка в оригинальном посте (0.5.9) уже достаточно старая, а с тех пор вышли патчи tomcat. Обновление до самой свежей прошивки UCK и версии UniFi вполне может решить проблему.

emilstahl Guest	#14 25.08.2017 17:07:00 Почему ваш Cloud Key находится в сети/инфраструктуре, соответствующей требованиям PCI-DSS?

vConsulting

Guest

#15

25.08.2017 16:57:00

Или Ubiquiti мог бы просто сделать свою работу и исправить это с помощью простого обновления как минимум до самой новой версии 7 — а ещё лучше, до самой новой версии 8.5. Это не должно быть проблемой для конечных пользователей. С наилучшими пожеланиями, Даниэль...

andyc Guest	#16 25.08.2017 07:17:00 Настройте правила фаервола так, чтобы входящие пакеты на этот порт принимались только с IP-адреса вашего удалённого сайта.

vConsulting Guest	#17 25.08.2017 04:53:00 Я тоже немного в замешательстве, честно говоря. Ведь это довольно легко исправить для Ubiquiti и это известная уязвимость в безопасности — даже домашний сканер Bitdefender её находит!

Читают тему (гостей: 1)