Spe­zi­ell in der Soft­ware-Ent­wick­lung, aber auch in Pro­duk­ti­on und der Auto­ma­ti­sie­rung und ande­ren Berei­chen, fin­den Linux Work­sta­tions und Note­books ver­mehrt Ein­satz. Damit müs­sen auch Com­pli­an­ce Anfor­de­run­gen zur Infor­ma­ti­ons­si­cher­heit wie ISO 27001, DSGVO, TISAX, etc. auf die­sen Cli­ent-Sys­te­men imple­men­tiert wer­den. Die­se tech­ni­schen und orga­ni­sa­to­ri­schen Maß­nah­men (soge­nann­te TOMs) für die Zugriffs­kon­trol­le umfas­sen oft die Maß­nah­men Ver­schlüs­se­lung und Zwei-Fak­to­ren-Authen­ti­sie­rung, oft auch Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung, Two-Fac­tor-Authen­ti­ca­ti­on, Mul­ti-Fac­tor Authen­ti­ca­ti­on oder kurz 2FA / MFA bezeich­net. In die­sem Bei­trag zei­gen wir den Ein­satz von Time-Based OTP nach RFC 6238 über das  Goog­le Authen­ti­ca­tor PAM Linux Modul.

In dem Ver­suchs­auf­bau nut­zen wir die aktu­el­le (Stand August 2019) Ubun­tu Desk­top 19.04 mit aktu­el­len Updates. Da es sich um ein Stan­dard Linux Packa­ge han­delt, wird die­se 2FA Metho­de auch mit ande­ren Linux Dis­tri­bu­tio­nen funktionieren.

  • LUKS Disk Encryption

  • Con­so­le Login

  • GUI Log­in

  • Remo­te SSH Login

Imple­men­tie­rung: ein­fach 100%
Funk­ti­ons­um­fang 75%
Sicher­heit 50%

Die Instal­la­ti­on Goog­le Authen­ti­ca­tor 2FA PAM Moduls

Die Instal­la­ti­on des benö­tig­ten Authen­ti­sie­rungs­mo­duls unter Linux ist ein­fach, da es direkt über die Ubun­tu Dis­tri­bu­ti­ons­quel­le instal­liert wer­den kann. Vor der Instal­la­ti­on von lib­pam-goog­le-authen­ti­ca­tor emp­fiehlt es sich das Sys­tem zu aktualsieren.

$ sudo apt install libpam-google-authenticator

Das Authen­ti­sie­rungs­mo­dul für Linux ist nun instal­liert. Jedoch muss die Zwei-Fak­to­ren Metho­de für jeden Benut­zer des Sys­tems akti­viert wer­den und die Linux PAM Kon­fi­gu­ra­ti­on für die Nut­zung der 2FA geän­dert werden.

Akti­vie­rung des TOTP 2FA für den Linux Benutzer

Die fol­gen­den Kon­fi­gu­ra­tio­nen habe ich in einer nicht pro­duk­ti­ven, vir­tu­el­len Test­um­ge­bung erstellt. Daher ver­zich­te ich auf das Unkennt­lich­ma­chen von Authen­ti­sie­rungs-Codes, Secu­ri­ty Keys oder dem QR Code.

Mel­den Sie sich als Benut­zer an der die 2FA Benut­ze­r­iden­ti­fi­zie­rung nut­zen soll und star­ten Sie goog­le-authen­ti­ca­tor

$ goog­le-authen­ti­ca­tor

Nach der Beant­wor­tung der Sicher­heits­fra­ge, ob man einen Time-based Authen­ti­ca­ti­on Token erzeu­gen möch­te, sieht man sofort den QR Code für die Smart­pho­ne App.

Den QR Code mit dem gehei­men Schlüs­sel kön­nen Sie in jeder RFC 6238 — Time-Based One-Time-Pass­word (TOTP) App nut­zen. Alter­na­tiv zu der Goog­le Authen­ti­ca­tor App ste­hen eine Viel­zahl an frei­en Apps wie Authy, Micro­soft Authen­ti­ca­tor, Last­Pass Authen­ti­ca­tor, Free­OTP Authen­ti­ca­tor oder der Yubico Authen­ti­ca­tor zur Ver­fü­gung. Sofern Sie noch kei­ne kom­pa­ti­ble App auf Ihrem Smart­pho­ne instal­liert haben, laden Sie nun eine TOTP App auf Ihr Smart­pho­ne und scan­nen den QR Code ein. Alter­na­tiv kön­nen Sie auch den “Secret Key” manu­ell in der ent­spre­chen­den App eingeben.

Hier als Bei­spiel die Goog­le Authen­ti­ca­tor App mit dem ein­ge­le­se­nen QR Code:

Im Anschluss gibt eine Rei­he von Sicherheitsfragen:

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 authentication
token? This restricts you to one log­in about every 30s, but it increases
your chan­ces to noti­ce or even pre­vent man-in-the-midd­le attacks (y/n) y

Aus Sicher­heits­grün­den emp­feh­le ich die­se Fra­ge mit “y” (yes) zu beanworten.

By default, a new token is gene­ra­ted every 30 seconds by the mobi­le app. In order to com­pen­sa­te for pos­si­ble time-skew bet­ween the cli­ent and the ser­ver, we allow an extra token befo­re and after the cur­rent time. This allows for a time skew of up to 30 seconds bet­ween authen­ti­ca­ti­on ser­ver and cli­ent. If you expe­ri­ence pro­blems with poor time syn­chro­niz­a­ti­on, you can incre­a­se the win­dow from its default size of 3 per­mit­ted codes (one pre­vious code, the cur­rent code, the next code) to 17 per­mit­ted codes (the 8 pre­vious codes, the cur­rent code, and the 8 next codes). This will per­mit for a time skew of up to 4 minu­tes bet­ween cli­ent and server.
Do you want to do so? (y/n) y

Da die meis­ten Sys­te­me heu­te eine per­ma­nen­te Zeit­syn­chro­ni­sie­rung über Inter­net kon­fi­gu­riert haben, emp­feh­le ich die­se Fra­ge mit “y” (yes) zu beantworten.

If the com­pu­ter that you are log­ging into isn’t har­den­ed against bru­te-for­ce log­in attempts, you can enab­le rate-limi­t­ing for the authen­ti­ca­ti­on modu­le. By default, this limits atta­ckers to no more than 3 log­in attempts every 30s.
Do you want to enab­le rate-limi­t­ing? (y/n) y

Das PAM Modul bie­tet einen zusätz­li­chen Bru­te-For­ce Schutz, daher emp­feh­len wir die­se Fra­ge mit “y” (yes) zu beantworten.

Das Benut­zer­kon­to ist nun für 2FA mit dem Goog­le Authen­ti­ca­tor vor­be­rei­tet. Nun muss der Linux Log­in Pro­zess um die Zwei-Fak­to­ren-Authen­ti­sie­rung erwei­tert werden.

Linux PAM Konfiguration

Die PAM Kon­fi­gu­ra­ti­on erfolgt in den Datei­en im Ver­zeich­nis /etc/pam.d

Hier gibt es ver­schie­de­ne Kon­fi­gu­ra­ti­ons­da­tei­en für den Con­so­len Log­in (Datei: log­in), den Remo­te Zugriff per ssh (Datei: sshd) und für die gra­fi­sche Linux GUI (Datei: gdm-password).

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Linux Con­so­len Login

Um die TOTP 2FA für das Linux Con­so­len Log­in (Text-Screen direkt auf dem Cli­ent oder dem Ser­ver) zu akti­vie­ren, ändern Sie die Datei /etc/pam.d/login als root Benut­zer ent­spre­chend dem fol­gen­den Beispiel:

#The PAM con­fi­gu­ra­ti­on file for the Shadow ‘log­in’ service
auth optio­nal pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth requi­si­te pam_nologin.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­si­on requi­red pam_loginuid.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#par­sing /etc/environment needs “readenv=1”
ses­si­on requi­red pam_env.so readenv=1
ses­si­on requi­red pam_env.so readenv=1 envfile=/etc/default/locale
#Stan­dard Un*x authentication.
@include common-auth
ses­si­on optio­nal pam_motd.so noupdate
#MODIFICATION: requi­red for Goog­le Authen­ti­ca­tor 2FA
auth requi­red pam_google_authenticator.so
#This allows cer­tain extra groups to be gran­ted to a user
auth optio­nal pam_group.so
#Sets up user limits accord­ing to /etc/security/limits.conf
ses­si­on requi­red pam_limits.so
#Prints the last log­in info upon suc­cess­ful login
ses­si­on optio­nal pam_lastlog.so
#Prints the mes­sa­ge of the day upon suc­cess­ful login.
ses­si­on optio­nal pam_motd.so motd=/run/motd.dynamic
ses­si­on optio­nal pam_motd.so noupdate
#
ses­si­on optio­nal pam_mail.so standard
#Crea­te a new ses­si­on keyring.
ses­si­on optio­nal pam_keyinit.so for­ce revoke
#Stan­dard Un*x account and session
@include common-account
@include common-session
@include common-password

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Linux GUI (GDM Oberfläche)

Um die TOTP 2FA für den Ubun­tu Win­dow-Mana­ger GDM zu akti­vie­ren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benut­zer ent­spre­chend dem fol­gen­den Beispiel:

#%PAM‑1.0
auth requi­si­te pam_nologin.so
auth requi­red pam_succeed_if.so user != root quiet_success
@include common-auth
#Requi­red for Goog­le Authen­ti­ca­tor 2FA
auth requi­red pam_google_authenticator.so
auth optio­nal pam_gnome_keyring.so
@include common-account
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­si­on requi­red pam_loginuid.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
ses­si­on optio­nal pam_keyinit.so for­ce revoke
ses­si­on requi­red pam_limits.so
ses­si­on requi­red pam_env.so readenv=1
ses­si­on requi­red pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-session
ses­si­on optio­nal pam_gnome_keyring.so auto_start
@include common-password

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Remo­te Zugriff per SSH

Um die TOTP 2FA für den Remo­te Zugriff per SSH zu akti­vie­ren, ändern Sie die Datei /etc/pam.d/sshd als root Benut­zer ent­spre­chend dem fol­gen­den Beispiel:

#PAM con­fi­gu­ra­ti­on for the Secu­re Shell service
#Stan­dard Un*x authentication.
@include common-auth
ses­si­on optio­nal pam_motd.so noupdate
#Requi­red for Goog­le Authen­ti­ca­tor 2FA
auth requi­red pam_google_authenticator.so
account requi­red pam_nologin.so
#Stan­dard Un*x authorization.
@include common-account
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­si­on requi­red pam_loginuid.so
ses­si­on optio­nal pam_keyinit.so for­ce revoke
#Stan­dard Un*x ses­si­on set­up and teardown.
@include common-session
ses­si­on optio­nal pam_motd.so motd=/run/motd.dynamic
#ses­si­on optio­nal pam_motd.so noupdate
ses­si­on requi­red pam_limits.so
ses­si­on requi­red pam_env.so user_readenv=1 envfile=/etc/default/locale
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
@include common-password

Der Linux GUI 2FA Login

Der Linux Con­so­len 2FA Login

Der Linux Remo­te SSH 2FA Login

Goog­le Authen­ti­ca­tor Sicherheitsüberlegungen

Der zwei­te Fak­tor der Benut­ze­r­iden­ti­fi­zie­rung beim Goog­le Authen­ti­ca­tor ist ein Code der über eine Smart­pho­ne App gene­riert wird. Die­se vier Angriffs­vek­to­ren sind offensichtlich:

1. Angriff auf den kryp­to­gra­phi­schen Algorithmus

Der vom Goog­le Authen­ti­ca­tor PAM Modul benutz­te TOTP 2FA Metho­de basiert auf dem RFC 6238, sie­he Link. Der RFC wur­de 2011 ver­öf­fen­ticht, die Ent­wür­fe dazu gehen aber bis April 2008 zurück. Das sind aktu­ell (August 2019) bereits über 11 Jah­re die der Algo­rith­mus geal­tert ist.

Genau da setzt einer der Angrif­fe an, gelingt es näm­lich bereits zwei Codes abzu­fan­gen kann man das Secret in nur weni­gen Minu­ten errechnen.

Der von linux-nin­ja doku­men­tier­te 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 Linux poten­ti­el­le Secret Keys errech­nen, die in der Datei totp.potfile gespei­chert werden.

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

Zu guter letzt, muss man die errech­ne­ten poten­ti­el­len Secret Keys nach der gefun­de­nen Häu­fig­keit sor­tie­ren und hat eine Kopie des streng gehei­men Secret Keys.

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

Mit einer nor­ma­len Note­book Gra­fik­kar­te rech­net das hash­cat Tool gera­de mal knapp über 1 Stun­de an den Ergeb­nis­sen. Das birgt ein hohes Sicher­heits­ri­si­ko für die­sen zwei­ten Faktor!

2. Angriff auf das Smartphone

Der Secret Key, der die TOTP Codes gene­riert, ist im Smart­pho­ne gespei­chert. Gelangt man an ein Back­up des Smart­pho­nes oder kann man wie bei Android üblich auf die Datenbanken/Dateien des Mobil­te­le­fons zugrei­fen hat man so ein­fa­chen Zugriff auf den Secret Key und erstellt eine Kopie des Schlüssels.

Spe­zi­ell in BYOD Umge­bun­gen, wo 2FA Benut­zer ihre eige­nen Smart­pho­nes mit einer frei gewähl­ten Authen­ti­ca­tor App für die Zwei-Fak­to­ren-Authen­ti­sie­rung nut­zen gibt es zu wenig Kon­trol­le über die Sicher­heit der gespei­cher­ten Schlüssel.

3. Man-in-the-Midd­le Angrif­fe / Phis­hing Angriffe

Gelingt es einem Angrei­fer über Phis­hing Sei­ten, gefälsch­te  DNS Ein­trä­ge oder über das Auf­bre­chen von HTTPS Ver­bin­dun­gen eine gefälsch­te Web­sei­te oder einen fal­schen Ser­ver dem Benut­zer zu prä­sen­tie­ren, wird die­ser sei­ne Zugang­da­ten und auch den Goog­le Authen­ti­ca­tor Code auf dem gefälsch­ten Dienst ein­ge­ben. Die­ser Man-in-the-Midd­le Angriff lei­tet dann die abge­fan­ge­nen Zugangs­da­ten und den Goog­le Authen­ti­ca­tor Code an den rich­ti­gen Dienst wei­ter, mel­det den Benut­zer an und hat fort­an die vol­le Kon­trol­le über den gesam­ten Daten­ver­kehr die­ser Verbindung.

Sobald ein Angrei­fer zwei­mal den Benut­zer getäuscht hat, hat der Angrei­fer zwei Codes über die er wie­der­um mit dem hash­cat Tool den Secret Key errech­nen kann und dann unbe­merkt den Account nut­zen kann.

4. Bru­te-For­ce Angriffe

Diens­te wel­che die Anzahl der Authen­ti­sie­rungs­ver­su­che nicht limi­tie­ren kön­nen auch über Bru­te-For­ce Angrif­fe atta­ckiert wer­de. Hier ver­sucht der Angrei­fer auto­ma­ti­siert eine gro­ße Anzahl an Codes in kur­zer Zeit aus und da es sich “nur” um 999 999 mög­li­che Codes han­delt, ist die­ser Angriff tech­nisch kei­ne Hürde.