vTiger – przestarzałe API i słabe logowanie

Przestarzałe API i słabe logowanie w vTiger zwiększają ryzyko nieautoryzowanego dostępu do danych kontaktów.

vTiger CRM i zakres problemu ze starszym API

vTiger CRM to internetowa aplikacja CRM używana do obsługi kontaktów, organizacji, potencjalnych klientów, zgłoszeń i historii działań handlowych. W starszych instalacjach komunikacja z aplikacją może odbywać się przez endpoint webservice.php. Interfejs webservice udostępnia operacje takie jak pobieranie wyzwania sesyjnego, logowanie, opisywanie modułów, wyszukiwanie rekordów, odczyt, tworzenie, aktualizowanie i usuwanie danych. Klient API przekazuje między innymi nazwę użytkownika, klucz dostępu, identyfikator sesji oraz identyfikatory rekordów.

Określenie „przestarzałe API” nie oznacza automatycznie, że każda wersja vTiger CRM jest podatna. Ryzyko zależy od konkretnej wersji aplikacji, użytych dodatków, konfiguracji serwera WWW, sposobu publikacji endpointu i aktualizacji kodu. Problem pojawia się wtedy, gdy integracja korzysta ze starego mechanizmu uwierzytelniania, nie wymusza szyfrowanego połączenia HTTPS, nie ogranicza dostępu do API albo pozostawia publicznie dostępne funkcje, których użytkownicy nie potrzebują. W takim układzie przejęcie konta integracyjnego może umożliwić odczyt lub zmianę danych kontaktów.

Jak działa uwierzytelnianie w webservice.php

W klasycznym webservice API vTiger klient najpierw pobiera wyzwanie dla określonego użytkownika. Następnie przygotowuje wartość uwierzytelniającą na podstawie otrzymanego tokenu i klucza dostępu użytkownika, a wynik przekazuje podczas operacji logowania. Po poprawnym zalogowaniu serwer zwraca nazwę sesji, która jest używana przy kolejnych żądaniach. Takie rozwiązanie jest charakterystyczne dla starszego interfejsu vTiger Webservice, ale nie zastępuje ochrony transportu. Jeżeli żądania są wysyłane przez zwykłe HTTP, dane logowania, tokeny sesyjne albo treść operacji mogą zostać przechwycone przez osobę mającą dostęp do tej samej sieci.

Słabe logowanie oznacza tu przede wszystkim niewystarczającą rejestrację zdarzeń bezpieczeństwa, a nie sam fakt istnienia plików logów. Instalacja powinna pozwalać ustalić, kiedy wykonano logowanie do API, z jakiego adresu pochodziło żądanie, jakiego konta użyto, czy logowanie zakończyło się błędem oraz jakie operacje wykonano później. Przydatne są również informacje o odpowiedziach HTTP, błędach aplikacji i czasie wykonania żądania. Sam adres IP nie identyfikuje jednak jednoznacznie osoby, ponieważ wiele komputerów może korzystać ze wspólnego NAT-u, serwera proxy lub firmowej bramy sieciowej.

Ślady nieprawidłowego przepływu danych

Podczas analizy należy porównać trzy źródła informacji: logi aplikacji vTiger, logi serwera WWW oraz logi systemu lub usługi obsługującej bazę danych. Rozbieżność między nimi jest ważnym sygnałem. Jeżeli aplikacja zwraca klientowi błąd logowania, ale w logu serwera WWW widać serię poprawnych żądań do operacji odczytu rekordów, trzeba sprawdzić, czy nie użyto wcześniej wydanej sesji. Jeżeli w logach pojawiają się zapytania dotyczące kontaktów bez odpowiadającego im zdarzenia logowania, może to wskazywać na brak kompletnego audytu, błędne mapowanie identyfikatora sesji albo pośrednią integrację korzystającą z utrwalonego tokenu.

Niepokojące są powtarzalne żądania z nieznanych adresów, próby logowania wieloma nazwami użytkowników, nagły wzrost operacji retrieve lub query, a także zmiany rekordów wykonywane poza godzinami pracy. Warto sprawdzić, czy konto używane przez integrację ma uprawnienia wykraczające poza wymagany zakres. Konto pobierające kontakty nie powinno otrzymywać praw do usuwania rekordów, zmiany konfiguracji ani zarządzania użytkownikami, jeżeli nie jest to potrzebne. Analiza musi uwzględniać również mechanizmy rotacji kluczy, unieważniania sesji i retencji logów, ponieważ brak tych elementów utrudnia ustalenie, co faktycznie wydarzyło się po wykryciu incydentu.

Bezpieczna kontrola konfiguracji na stanowisku użytkownika

Na laptopie lub komputerze PC można rozpocząć od sprawdzenia adresu używanego przez przeglądarkę albo lokalny program integracyjny, certyfikatu HTTPS, komunikatów o błędach oraz czasu wystąpienia problemu. Warto ustalić, czy aplikacja jest osiągana przez właściwy adres, czy przeglądarka nie zgłasza błędów certyfikatu i czy lokalne rozszerzenie lub program nie zapisuje klucza dostępu w zwykłym pliku tekstowym. Nie należy kopiować prawdziwych kluczy API do zgłoszeń ani testować operacji zapisu na produkcyjnych kontaktach. Kontrolę można wykonać na koncie testowym, z ograniczonymi uprawnieniami i po wcześniejszym wykonaniu kopii zapasowej.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach z dostępem do vTiger może sprawdzić lokalne przyczyny po stronie stanowiska: działanie systemu, przeglądarki, certyfikatów, połączenia sieciowego oraz programów uruchamianych razem z systemem. Sama poprawa konfiguracji laptopa nie zastępuje aktualizacji vTiger, ograniczenia dostępu do endpointu ani przeglądu logów po stronie serwera aplikacji. Te elementy powinny zostać zweryfikowane przez administratora odpowiedzialnego za konkretną instalację CRM.