Błąd konfiguracji w pakiecie datahub-helm powodował, że osobiste tokeny dostępu (personal access tokens) mogły być generowane z użyciem domyślnego, publicznie znanego klucza tajnego. Atakujący znający ten statyczny klucz może samodzielnie tworzyć ważne tokeny i uzyskać nieautoryzowany dostęp do instancji DataHub.
▸ Pokaż oryginał (EN)
datahub-helm provides the Kubernetes Helm charts for deploying Datahub and its dependencies on a Kubernetes cluster. Starting in version 0.1.143 and prior to version 0.2.182, due to configuration issues in the helm chart, if there was a successful initial deployment during a limited window of time, personal access tokens were possibly created with a default secret key. Since the secret key is a static, publicly available value, someone could inspect the algorithm used to generate personal access tokens and generate their own for an instance. Deploying with Metadata Service Authentication enabled would have been difficult during window of releases. If someone circumvented the helm settings and manually set Metadata Service Authentication to be enabled using environment variables directly, this would skip over the autogeneration logic for the Kubernetes Secrets and DataHub GMS would default to the signing key specified statically in the application.yml. Most deployments probably did not attempt to circumvent the helm settings to enable Metadata Service Authentication during this time, so impact is most likely limited. Any deployments with Metadata Service Authentication enabled should ensure that their secret values are properly randomized. Version 0.2.182 contains a patch for this issue. As a workaround, one may reset the token signing key to be a random value, which will invalidate active personal access tokens.
W wersjach datahub-helm od 0.1.143 do 0.2.182 mechanizm automatycznego generowania losowego klucza podpisującego dla Kubernetes Secrets działał wadliwie. Jeśli w czasie podatnego okna wdrożeniowego włączono Metadata Service Authentication — zwłaszcza poprzez ominięcie ustawień helm i bezpośrednie ustawienie zmiennych środowiskowych — komponent DataHub GMS pomijał logikę autogenerowania i używał statycznego klucza zdefiniowanego w pliku application.yml. Ponieważ wartość tego klucza jest publicznie dostępna, każdy może poznać algorytm generowania tokenów i na jego podstawie tworzyć własne, w pełni akceptowane przez serwer tokeny.
Atakujący może sfabrykować własne personal access tokeny i uzyskać wysoki poziom dostępu do instancji DataHub — w tym możliwość odczytu oraz modyfikacji danych — bez posiadania prawidłowych poświadczeń.
Należy zaktualizować datahub-helm do wersji 0.2.182 lub nowszej, która zawiera patch dla tego problemu. Jako obejście (workaround) można ręcznie zresetować klucz podpisywania tokenów do losowej wartości — spowoduje to unieważnienie wszystkich aktywnych personal access tokens. Wszystkie wdrożenia z włączoną opcją Metadata Service Authentication powinny zweryfikować, czy używane wartości kluczy tajnych są właściwie losowe.
datahub-helm w wersjach od 0.1.143 do poniżej 0.2.182, przy wdrożeniach z włączoną opcją Metadata Service Authentication
Według opisu większość wdrożeń prawdopodobnie nie miała włączonej opcji Metadata Service Authentication w podatnym przedziale czasowym, co ogranicza realny zasięg podatności. CWE-1394 dotyczy użycia domyślnego klucza kryptograficznego.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NDatahub Helm
APPDatahub0.1.143 – 0.2.182 (bez)
Powiązane podatności
DataHub is an open-source metadata platform. Prior to version 0.8.45, the `StatelessTokenService` of the DataH...
DataHub is an open-source metadata platform. Prior to version 1.3.1.8, the LDAP ingestion source is vulnerable...
DataHub is an open-source metadata platform. The DataHub frontend acts as a proxy able to forward any REST or ...
DataHub is an open-source metadata platform. When not using authentication for the metadata service, which is ...
DataHub is an open-source metadata platform. The AuthServiceClient which is responsible for creation of new ac...