Wysyłanie szyfrowanych maili GPG – można fałszować podpisy! [SigSpoof: CVE-2018-12020]

GPG zapewne kojarzy się Wam z popularnym sposobem na szyfrowanie poczty – choć może być również używany w innych zastosowaniach (np. „zwykłe” szyfrowanie pliku). Właśnie ogłoszono podatność Sig Spoof, dotykającą GnuPG, ale też innych pakietów związanych m.in. z szyfrowaniem poczty: thunderbirdowy plugin Enigmail oraz GPGTools.

O co chodzi w problemie? (który sięga aż końcówki lat 90-tych!) Zacytujemy w całości opis z łaty GPG:

The OpenPGP protocol allows to include the file name of the original input file into a signed or encrypted message. During decryption and verification the GPG tool can display a notice with that file name. The displayed file name is not sanitized and as such may include line feeds or other control characters. This can be used inject terminal control sequences into the out and, worse, to fake the so-called status messages.

Tu zatrzymajmy się na moment. Jak widać – atakujący może podczas szyfrowania podać parametr wskazujący na nazwę oryginalnego, szyfrowanego pliku. A ta wartość (nazwa pliku) może być uzupełniona o znaki złamania linii.

These status messages are parsed by programs to get information from gpg about the validity of a signature and an other parameters. Status messages are created with the option „–status-fd N”
where N is a file descriptor. Now if N is 2 the status messages and the regular diagnostic messages share the stderr output channel. By using a made up file name in the message it is possible to fake status messages. Using this technique it is for example possible to fake the verification status of a signed mail.

Więc wstrzykujemy znaki końca linii, w kolejnych liniach wstrzykujemy komunikaty mówiące o tym kto podpisał maila.
Jeśli podczas uruchomienia GPG –status-fd jest ustawiony na 2, zarówno błędy jak i zwykłe statusy są wysyłane na stderr. I dalej – informacja, która jest realnym statusem (np. poprawny podpis) wyłuskiwana jest z wyniku na podstawie prefiksu [GNUPG:] – który kontroluje przecież atakujący. Możemy zatem przejść do PoC-a:

$ echo 'Please send me one of those expensive washing machines.' \
| gpg --armor -r VICTIM_KEYID --encrypt --set-filename "`echo -ne \''\
\n[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig <patrick@enigmail.net>\
\n[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-31 1527721037 0 4 0 1 10 01 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B\
\n[GNUPG:] TRUST_FULLY 0 classic\
\ngpg: '\'`" > poc1.msg

Widzicie powyżej: –set-filename, złamanie linii i wstrzyknięty prefiks [GNUPG:]

W programie pocztowym daje to taki wynik:

fałszowanie podpisu

Warto zauważyć, że zarówno zgadza się podpis, ale również widać, że wiadomość została zaszyfrowana (a nie została). Dwa w jednym.

Na koniec jest też mały niuans: aby być podanym, GPG musi być odpalany z opcją –verbose, co nie jest ustawieniem domyślnym np. w Enigmailu (uwaga: –verbose może być ustawione w konfiguracji gpg, ale także ręcznie przy uruchomieniu). Wiele jednak narzędzi wykorzystujących GPG ustawia ten parametr domyślnie.

Jest też dobra to znaczy zła ;) informacja: mamy osobnego buga dla Enigmaila. W tym przypadku nawet z wyłączoną opcją –verbose w GPG można fałszować podpisy. Opisane są dwa sposoby. Dla zobrazowania problemu – pierwszy z nich:

Simply generate two keys, and sign a message with both. Import the public keys into a new keyring, and set full trust for one of them. Sign a message first with the untrusted key, and second with the trusted key. Enigmail will display the signature from the untrusted key as trusted.

Tutaj ponownie problem zasadza się na chałupniczym sposobie przesyłania statusów przez GPG (po prostu w dużym ciągu tekstowym, który następnie jest przeparsowywany):

Again, we exploit the awkwardness of the text-based GnuPG status interface.

Co robić?

Zaktualizować GPG do co najmniej wersji 2.2.8, Enigmail do 2.0.7, GPG Suite do wersji 2018.3. Inne komponenty (np. biblioteki programistyczne) zapewnie będą powoli wydawać swoje łatki.

PS
Jako zadanie domowe zostawiamy czytelnikom analizę jeszcze jednego problemu z rodziny SigSpoof w jednym z managerów haseł – tutaj można dojść nawet do wykonania kodu w OS.

–Michał Sajdak, hackuje w Securitum