Speziell in der Soft­ware-Entwick­lung, aber auch in Pro­duk­tion und der Automa­tisierung und anderen Bere­ichen, find­en Lin­ux Work­sta­tions und Note­books ver­mehrt Ein­satz. Damit müssen auch Com­pli­ance Anforderun­gen zur Infor­ma­tion­ssicher­heit wie ISO 27001, DSGVO, TISAX, etc. auf diesen Client-Sys­te­men imple­men­tiert wer­den. Diese tech­nis­chen und organ­isatorischen Maß­nah­men (soge­nan­nte TOMs) für die Zugriff­skon­trolle umfassen oft die Maß­nah­men Ver­schlüs­selung und Zwei-Fak­toren-Authen­tisierung, oft auch Zwei-Fak­toren Benutzeri­den­ti­fizierung, Two-Fac­tor-Authen­ti­ca­tion, Mul­ti-Fac­tor Authen­ti­ca­tion oder kurz 2FA / MFA beze­ich­net. In diesem Beitrag zeigen wir den Ein­satz von Time-Based OTP nach RFC 6238 über das  Google Authen­ti­ca­tor PAM Lin­ux Mod­ul.

In dem Ver­such­sauf­bau nutzen wir die aktuelle (Stand August 2019) Ubun­tu Desk­top 19.04 mit aktuellen Updates. Da es sich um ein Stan­dard Lin­ux Pack­age han­delt, wird diese 2FA Meth­ode auch mit anderen Lin­ux Dis­tri­b­u­tio­nen funk­tion­ieren.

  • LUKS Disk Encryp­tion

  • Con­sole Login

  • GUI Login

  • Remote SSH Login

Imple­men­tierung: ein­fach 100%
Funk­tion­sum­fang 75%
Sicher­heit 50%

Die Instal­la­tion Google Authen­ti­ca­tor 2FA PAM Moduls

Die Instal­la­tion des benötigten Authen­tisierungsmoduls unter Lin­ux ist ein­fach, da es direkt über die Ubun­tu Dis­tri­b­u­tion­squelle instal­liert wer­den kann. Vor der Instal­la­tion von lib­pam-google-authen­ti­ca­tor emp­fiehlt es sich das Sys­tem zu aktu­alsieren.

$ sudo apt install lib­pam-google-authen­ti­ca­tor

Das Authen­tisierungsmod­ul für Lin­ux ist nun instal­liert. Jedoch muss die Zwei-Fak­toren Meth­ode für jeden Benutzer des Sys­tems aktiviert wer­den und die Lin­ux PAM Kon­fig­u­ra­tion für die Nutzung der 2FA geän­dert wer­den.

Aktivierung des TOTP 2FA für den Lin­ux Benutzer

Die fol­gen­den Kon­fig­u­ra­tio­nen habe ich in ein­er nicht pro­duk­tiv­en, virtuellen Tes­tumge­bung erstellt. Daher verzichte ich auf das Unken­ntlich­machen von Authen­tisierungs-Codes, Secu­ri­ty Keys oder dem QR Code.

Melden Sie sich als Benutzer an der die 2FA Benutzeri­den­ti­fizierung nutzen soll und starten Sie google-authen­ti­ca­tor

$ google-authen­ti­ca­tor

Nach der Beant­wor­tung der Sicher­heits­frage, ob man einen Time-based Authen­ti­ca­tion Token erzeu­gen möchte, sieht man sofort den QR Code für die Smart­phone App.

Den QR Code mit dem geheimen Schlüs­sel kön­nen Sie in jed­er RFC 6238 — Time-Based One-Time-Pass­word (TOTP) App nutzen. Alter­na­tiv zu der Google Authen­ti­ca­tor App ste­hen eine Vielzahl an freien Apps wie Authy, Microsoft Authen­ti­ca­tor, Last­Pass Authen­ti­ca­tor, FreeOTP Authen­ti­ca­tor oder der Yubi­co Authen­ti­ca­tor zur Ver­fü­gung. Sofern Sie noch keine kom­pat­i­ble App auf Ihrem Smart­phone instal­liert haben, laden Sie nun eine TOTP App auf Ihr Smart­phone und scan­nen den QR Code ein. Alter­na­tiv kön­nen Sie auch den “Secret Key” manuell in der entsprechen­den App eingeben.

Hier als Beispiel die Google Authen­ti­ca­tor App mit dem ein­ge­le­se­nen QR Code:

Im Anschluss gibt eine Rei­he von Sicher­heits­fra­gen:

Do you want me to update your “/home/dschuster/.google_authenticator” file? (y/n) y

Ja, klar!

Do you want to dis­al­low mul­ti­ple uses of the same authen­ti­ca­tion
token? This restricts you to one login about every 30s, but it increas­es
your chances to notice or even pre­vent man-in-the-mid­dle attacks (y/n) y

Aus Sicher­heits­grün­den empfehle ich diese Frage mit “y” (yes) zu bean­worten.

By default, a new token is gen­er­at­ed every 30 sec­onds by the mobile app. In order to com­pen­sate for pos­si­ble time-skew between the client and the serv­er, we allow an extra token before and after the cur­rent time. This allows for a time skew of up to 30 sec­onds between authen­ti­ca­tion serv­er and client. If you expe­ri­ence prob­lems with poor time syn­chro­niza­tion, you can increase the win­dow from its default size of 3 per­mit­ted codes (one pre­vi­ous code, the cur­rent code, the next code) to 17 per­mit­ted codes (the 8 pre­vi­ous codes, the cur­rent code, and the 8 next codes). This will per­mit for a time skew of up to 4 min­utes between client and serv­er.
Do you want to do so? (y/n) y

Da die meis­ten Sys­teme heute eine per­ma­nente Zeit­syn­chro­nisierung über Inter­net kon­fig­uri­ert haben, empfehle ich diese Frage mit “y” (yes) zu beant­worten.

If the com­put­er that you are log­ging into isn’t hard­ened against brute-force login attempts, you can enable rate-lim­it­ing for the authen­ti­ca­tion mod­ule. By default, this lim­its attack­ers to no more than 3 login attempts every 30s.
Do you want to enable rate-lim­it­ing? (y/n) y

Das PAM Mod­ul bietet einen zusät­zlichen Brute-Force Schutz, daher empfehlen wir diese Frage mit “y” (yes) zu beant­worten.

Das Benutzerkon­to ist nun für 2FA mit dem Google Authen­ti­ca­tor vor­bere­it­et. Nun muss der Lin­ux Login Prozess um die Zwei-Fak­toren-Authen­tisierung erweit­ert wer­den.

Lin­ux PAM Kon­fig­u­ra­tion

Die PAM Kon­fig­u­ra­tion erfol­gt in den Dateien im Verze­ich­nis /etc/pam.d

Hier gibt es ver­schiedene Kon­fig­u­ra­tions­dateien für den Con­solen Login (Datei: login), den Remote Zugriff per ssh (Datei: sshd) und für die grafis­che Lin­ux GUI (Datei: gdm-pass­word).

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Lin­ux Con­solen Login

Um die TOTP 2FA für das Lin­ux Con­solen Login (Text-Screen direkt auf dem Client oder dem Serv­er) zu aktivieren, ändern Sie die Datei /etc/pam.d/login als root Benutzer entsprechend dem fol­gen­den Beispiel:

#The PAM con­fig­u­ra­tion file for the Shad­ow ‘login’ ser­vice
auth option­al pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth req­ui­site pam_nologin.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­sion required pam_loginuid.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#pars­ing /etc/environment needs “readenv=1”
ses­sion required pam_env.so readenv=1
ses­sion required pam_env.so readenv=1 envfile=/etc/default/locale
#Stan­dard Un*x authen­ti­ca­tion.
@include com­mon-auth
ses­sion option­al pam_motd.so noup­date
#MODIFICATION: required for Google Authen­ti­ca­tor 2FA
auth required pam_google_authenticator.so
#This allows cer­tain extra groups to be grant­ed to a user
auth option­al pam_group.so
#Sets up user lim­its accord­ing to /etc/security/limits.conf
ses­sion required pam_limits.so
#Prints the last login info upon suc­cess­ful login
ses­sion option­al pam_lastlog.so
#Prints the mes­sage of the day upon suc­cess­ful login.
ses­sion option­al pam_motd.so motd=/run/motd.dynamic
ses­sion option­al pam_motd.so noup­date
#
ses­sion option­al pam_mail.so stan­dard
#Cre­ate a new ses­sion keyring.
ses­sion option­al pam_keyinit.so force revoke
#Stan­dard Un*x account and ses­sion
@include com­mon-account
@include com­mon-ses­sion
@include com­mon-pass­word

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Lin­ux GUI (GDM Ober­fläche)

Um die TOTP 2FA für den Ubun­tu Win­dow-Man­ag­er GDM zu aktivieren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benutzer entsprechend dem fol­gen­den Beispiel:

#%PAM‑1.0
auth req­ui­site pam_nologin.so
auth required pam_succeed_if.so user != root quiet_success
@include com­mon-auth
#Required for Google Authen­ti­ca­tor 2FA
auth required pam_google_authenticator.so
auth option­al pam_gnome_keyring.so
@include com­mon-account
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­sion required pam_loginuid.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
ses­sion option­al pam_keyinit.so force revoke
ses­sion required pam_limits.so
ses­sion required pam_env.so readenv=1
ses­sion required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include com­mon-ses­sion
ses­sion option­al pam_gnome_keyring.so auto_start
@include com­mon-pass­word

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Remote Zugriff per SSH

Um die TOTP 2FA für den Remote Zugriff per SSH zu aktivieren, ändern Sie die Datei /etc/pam.d/sshd als root Benutzer entsprechend dem fol­gen­den Beispiel:

#PAM con­fig­u­ra­tion for the Secure Shell ser­vice
#Stan­dard Un*x authen­ti­ca­tion.
@include com­mon-auth
ses­sion option­al pam_motd.so noup­date
#Required for Google Authen­ti­ca­tor 2FA
auth required pam_google_authenticator.so
account required pam_nologin.so
#Stan­dard Un*x autho­riza­tion.
@include com­mon-account
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­sion required pam_loginuid.so
ses­sion option­al pam_keyinit.so force revoke
#Stan­dard Un*x ses­sion set­up and tear­down.
@include com­mon-ses­sion
ses­sion option­al pam_motd.so motd=/run/motd.dynamic
#ses­sion option­al pam_motd.so noup­date
ses­sion required pam_limits.so
ses­sion required pam_env.so user_readenv=1 envfile=/etc/default/locale
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
@include com­mon-pass­word

Der Lin­ux GUI 2FA Login

Der Lin­ux Con­solen 2FA Login

Der Lin­ux Remote SSH 2FA Login

Google Authen­ti­ca­tor Sicher­heit­süber­legun­gen

Der zweite Fak­tor der Benutzeri­den­ti­fizierung beim Google Authen­ti­ca­tor ist ein Code der über eine Smart­phone App gener­iert wird. Diese vier Angriffsvek­toren sind offen­sichtlich:

1. Angriff auf den kryp­tographis­chen Algo­rith­mus

Der vom Google Authen­ti­ca­tor PAM Mod­ul benutzte TOTP 2FA Meth­ode basiert auf dem RFC 6238, siehe Link. Der RFC wurde 2011 veröf­fen­ticht, die Entwürfe dazu gehen aber bis April 2008 zurück. Das sind aktuell (August 2019) bere­its über 11 Jahre die der Algo­rith­mus geal­tert ist.

Genau da set­zt ein­er der Angriffe an, gelingt es näm­lich bere­its zwei Codes abz­u­fan­gen kann man das Secret in nur weni­gen Minuten errech­nen.

Der von lin­ux-nin­ja doku­men­tierte Angriff benötigt eine Datei test.hash im For­mat $TOKEN:$TIMESTAMP

z.B:

833060:1263384780
549115:1528848780

Dann kann man mit dem hash­cat Tool unter Lin­ux poten­tielle Secret Keys errech­nen, die in der Datei totp.potfile gespe­ichert wer­den.

$ hash­cat ‑m17300 ‑a3 ‑o totp.potfile test.hash ?l?l?l?l?l?l?l

Zu guter let­zt, muss man die errech­neten poten­tiellen Secret Keys nach der gefun­de­nen Häu­figkeit sortieren und hat eine Kopie des streng geheimen Secret Keys.

$ cut ‑d: ‑f3 totp.potfile | sort | uniq ‑c | sort ‑nr | head

Mit ein­er nor­malen Note­book Grafikkarte rech­net das hash­cat Tool ger­ade mal knapp über 1 Stunde an den Ergeb­nis­sen. Das birgt ein hohes Sicher­heit­srisiko für diesen zweit­en Fak­tor!

2. Angriff auf das Smart­phone

Der Secret Key, der die TOTP Codes gener­iert, ist im Smart­phone gespe­ichert. Gelangt man an ein Back­up des Smart­phones oder kann man wie bei Android üblich auf die Datenbanken/Dateien des Mobil­tele­fons zugreifen hat man so ein­fachen Zugriff auf den Secret Key und erstellt eine Kopie des Schlüs­sels.

Speziell in BYOD Umge­bun­gen, wo 2FA Benutzer ihre eige­nen Smart­phones mit ein­er frei gewählten Authen­ti­ca­tor App für die Zwei-Fak­toren-Authen­tisierung nutzen gibt es zu wenig Kon­trolle über die Sicher­heit der gespe­icherten Schlüs­sel.

3. Man-in-the-Mid­dle Angriffe / Phish­ing Angriffe

Gelingt es einem Angreifer über Phish­ing Seit­en, gefälschte  DNS Ein­träge oder über das Auf­brechen von HTTPS Verbindun­gen eine gefälschte Web­seite oder einen falschen Serv­er dem Benutzer zu präsen­tieren, wird dieser seine Zugang­dat­en und auch den Google Authen­ti­ca­tor Code auf dem gefälscht­en Dienst eingeben. Dieser Man-in-the-Mid­dle Angriff leit­et dann die abge­fan­genen Zugangs­dat­en und den Google Authen­ti­ca­tor Code an den richti­gen Dienst weit­er, meldet den Benutzer an und hat for­t­an die volle Kon­trolle über den gesamten Daten­verkehr dieser Verbindung.

Sobald ein Angreifer zweimal den Benutzer getäuscht hat, hat der Angreifer zwei Codes über die er wiederum mit dem hash­cat Tool den Secret Key errech­nen kann und dann unbe­merkt den Account nutzen kann.

4. Brute-Force Angriffe

Dien­ste welche die Anzahl der Authen­tisierungsver­suche nicht lim­i­tieren kön­nen auch über Brute-Force Angriffe attack­iert werde. Hier ver­sucht der Angreifer automa­tisiert eine große Anzahl an Codes in kurz­er Zeit aus und da es sich “nur” um 999 999 mögliche Codes han­delt, ist dieser Angriff tech­nisch keine Hürde.