Podatności ePA 3.x Integration

ePA 3.x Integration przed wersją 1.3.0 zawiera podatność w walidacji certyfikatów serwera VAU. Atakujący w pozycji sieciowej może przechwycić uzgadnianie VAU i podszyć się pod serwer, kontrolując klucze sesji i odczytując lub modyfikując zaszyfrowany ruch.

ePA 3.x Integration przed wersją 1.3.0 wyłącza weryfikację certyfikatów TLS zarówno dla połączeń ePA w app/vau/VAUProtokoll.py, jak i połączeń Konnektor w app/konnektor/Konnektor.py. Atakujący w pozycji sieciowej może przedstawić dowolny certyfikat, zakończyć połączenie TLS i przechwycić ruch ePA. Protokół VAU nie zapewnia skutecznego zabezpieczenia, ponieważ walidacja certyfikatów na poziomie aplikacji jest również uszkodzona. Sesja Konnektor używa self.session.verify ustawionego na False, więc atakujący podszywający się pod Konnektor może otrzymać wymianę certyfikatów wzajemnego TLS i obserwować operacje na karcie inteligentnej.

ePA 3.x Integration przed wersją 1.3.0 pozostawia request_counter bez zmian w app/vau/VAUProtokoll.py podczas konstruowania wiadomości VAU. Zamrożony licznik żądań klienta powoduje, że serwer ponownie używa kombinacji nonce i klucza AES-GCM w odpowiedziach. Atakujący sieciowy, zbierając powtarzające się szyfrogramy, może odzyskać XOR tekstów jawnych i użyć przewidywalnych nagłówków HTTP i pól JSON do odzyskania wrażliwych danych, w tym dokumentacji medycznej pacjentów. Powtarzające się nonce mogą również umożliwić odzyskanie klucza uwierzytelniającego GHASH, co pozwala na fałszowanie wiadomości AES-GCM i wstrzykiwanie złośliwych odpowiedzi.

ePA 3.x Integration implementuje przepływ autoryzacji i zapisuje obiekty informacji medycznych do niemieckiej elektronicznej dokumentacji pacjenta. Przed wersją 1.3.0, ePA 3.x Integration nie neutralizuje znaków CRLF w wartościach używanych przez app/vau/VAUProtokoll.py do konstruowania wewnętrznych żądań HTTP VAU. Funkcja build_inner_header interpoluje wartości uri, host, accept_type, content_type, content_length, USER_AGENT i insurant_id do linii żądań i nagłówków, w tym x-useragent i x-insurantid. Uwierzytelniony atakujący, który kontroluje wartość, może wstrzyknąć dodatkowe nagłówki do wewnętrznego żądania. W zależności od obsługi serwera ePA, wstrzyknięty nagłówek x-insurantid może ujawnić dokumentację innego pacjenta, a wstrzyknięte nagłówki Authorization mogą ominąć zamierzone uwierzytelnienie lub kontekst autoryzacji. Dane wejściowe USER_AGENT pochodzące z sesji mogą również zatruć żądania w całej sesji. Problem został naprawiony w wersji 1.3.0.