W Jira Service Management Server i Data Center odkryto krytyczną podatność umożliwiającą atakującemu podszywanie się pod innego użytkownika i uzyskanie nieautoryzowanego dostępu do instancji. Błąd jest szczególnie groźny, ponieważ nie wymaga żadnego uwierzytelnienia ani interakcji ze strony ofiary.
▸ Pokaż oryginał (EN)
An authentication vulnerability was discovered in Jira Service Management Server and Data Center which allows an attacker to impersonate another user and gain access to a Jira Service Management instance under certain circumstances_._ With write access to a User Directory and outgoing email enabled on a Jira Service Management instance, an attacker could gain access to signup tokens sent to users with accounts that have never been logged into. Access to these tokens can be obtained in two cases: * If the attacker is included on Jira issues or requests with these users, or * If the attacker is forwarded or otherwise gains access to emails containing a “View Request” link from these users. Bot accounts are particularly susceptible to this scenario. On instances with single sign-on, external customer accounts can be affected in projects where anyone can create their own account.
Podatność polega na możliwości przechwycenia tokenów rejestracyjnych wysyłanych pocztą elektroniczną do kont użytkowników, którzy nigdy się nie zalogowali. Warunkiem koniecznym jest posiadanie przez atakującego dostępu do zapisu w User Directory oraz włączona na instancji funkcja wysyłania poczty wychodzącej. Token można zdobyć na dwa sposoby: atakujący jest dołączony do zgłoszenia lub żądania Jira razem z docelowym użytkownikiem, albo atakujący uzyskuje dostęp do wiadomości e-mail zawierającej link „View Request" należącej do tego użytkownika. Konta typu bot są szczególnie narażone; na instancjach z single sign-on zagrożone mogą być również zewnętrzne konta klientów w projektach z otwartą rejestracją.
Atakujący może przejąć tożsamość innego użytkownika i uzyskać pełny dostęp do instancji Jira Service Management z uprawnieniami tej osoby, co prowadzi do ujawnienia poufnych danych oraz możliwości ich modyfikacji.
Należy zastosować patche dostępne u producenta zgodnie z referencjami (https://jira.atlassian.com/browse/JSDSERVER-12312). Tymczasowo zaleca się ograniczenie dostępu do zapisu w User Directory oraz — jeśli to możliwe — wyłączenie funkcji wysyłania poczty wychodzącej do czasu zainstalowania poprawki. Należy również zweryfikować konta użytkowników, którzy nigdy się nie logowali, ze szczególnym uwzględnieniem kont bot.
Atlassian Jira Service Management Server oraz Data Center — wersje wskazane w referencjach producenta (szczegóły w JSDSERVER-12312)
Podatność dotyczy wyłącznie instancji, na których jednocześnie włączone jest wysyłanie poczty wychodzącej oraz atakujący posiada dostęp do zapisu w User Directory. Konta bot oraz projekty z otwartą rejestracją i single sign-on są szczególnie narażone według opisu producenta.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NAtlassian Jira Service Management
APPAtlassian5.5.05.3.0 – 5.3.3 (bez)5.4.0 – 5.4.2 (bez)
Powiązane podatności
Atlassian — pominięcie Servlet Filters umożliwia auth bypass i XSS
Atlassian Jira Seraph – Auth Bypass przez spreparowane żądanie HTTP
Atlassian Jira Data Center — RCE przez brak uwierzytelnienia w Ehcache RMI
XXE w Terracotta Quartz Scheduler — atak przez opis zadania XML
This High severity RCE (Remote Code Execution) vulnerability was introduced in version 5.2 of Confluence Data ...