Speziell in der Software-Entwicklung, aber auch in Produktion und der Automatisierung und anderen Bereichen, finden Linux Workstations und Notebooks vermehrt Einsatz. Damit müssen auch Compliance Anforderungen zur Informationssicherheit wie ISO 27001, DSGVO, TISAX, etc. auf diesen Client-Systemen implementiert werden. Diese technischen und organisatorischen Maßnahmen (sogenannte TOMs) für die Zugriffskontrolle umfassen oft die Maßnahmen Verschlüsselung und Zwei-Faktoren-Authentisierung, oft auch Zwei-Faktoren Benutzeridentifizierung, Two-Factor-Authentication, Multi-Factor Authentication oder kurz 2FA / MFA bezeichnet. In diesem Beitrag zeigen wir den Einsatz von Time-Based OTP nach RFC 6238 über das Google Authenticator PAM Linux Modul.
In dem Versuchsaufbau nutzen wir die aktuelle (Stand August 2019) Ubuntu Desktop 19.04 mit aktuellen Updates. Da es sich um ein Standard Linux Package handelt, wird diese 2FA Methode auch mit anderen Linux Distributionen funktionieren.
Die Installation Google Authenticator 2FA PAM Moduls
Die Installation des benötigten Authentisierungsmoduls unter Linux ist einfach, da es direkt über die Ubuntu Distributionsquelle installiert werden kann. Vor der Installation von libpam-google-authenticator empfiehlt es sich das System zu aktualsieren.
$ sudo apt install libpam-google-authenticator
Das Authentisierungsmodul für Linux ist nun installiert. Jedoch muss die Zwei-Faktoren Methode für jeden Benutzer des Systems aktiviert werden und die Linux PAM Konfiguration für die Nutzung der 2FA geändert werden.
Aktivierung des TOTP 2FA für den Linux Benutzer
Melden Sie sich als Benutzer an der die 2FA Benutzeridentifizierung nutzen soll und starten Sie google-authenticator
$ google-authenticator
Nach der Beantwortung der Sicherheitsfrage, ob man einen Time-based Authentication Token erzeugen möchte, sieht man sofort den QR Code für die Smartphone App.
Den QR Code mit dem geheimen Schlüssel können Sie in jeder RFC 6238 — Time-Based One-Time-Password (TOTP) App nutzen. Alternativ zu der Google Authenticator App stehen eine Vielzahl an freien Apps wie Authy, Microsoft Authenticator, LastPass Authenticator, FreeOTP Authenticator oder der Yubico Authenticator zur Verfügung. Sofern Sie noch keine kompatible App auf Ihrem Smartphone installiert haben, laden Sie nun eine TOTP App auf Ihr Smartphone und scannen den QR Code ein. Alternativ können Sie auch den “Secret Key” manuell in der entsprechenden App eingeben.
Hier als Beispiel die Google Authenticator App mit dem eingelesenen QR Code:
Im Anschluss gibt eine Reihe von Sicherheitsfragen:
Do you want me to update your “/home/dschuster/.google_authenticator” file? (y/n) y
Ja, klar!
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
Aus Sicherheitsgründen empfehle ich diese Frage mit “y” (yes) zu beanworten.
By default, a new token is generated every 30 seconds by the mobile app. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server.
Do you want to do so? (y/n) y
Da die meisten Systeme heute eine permanente Zeitsynchronisierung über Internet konfiguriert haben, empfehle ich diese Frage mit “y” (yes) zu beantworten.
If the computer that you are logging into isn’t hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y
Das PAM Modul bietet einen zusätzlichen Brute-Force Schutz, daher empfehlen wir diese Frage mit “y” (yes) zu beantworten.
Das Benutzerkonto ist nun für 2FA mit dem Google Authenticator vorbereitet. Nun muss der Linux Login Prozess um die Zwei-Faktoren-Authentisierung erweitert werden.
Linux PAM Konfiguration
Die PAM Konfiguration erfolgt in den Dateien im Verzeichnis /etc/pam.d
Hier gibt es verschiedene Konfigurationsdateien für den Consolen Login (Datei: login), den Remote Zugriff per ssh (Datei: sshd) und für die grafische Linux GUI (Datei: gdm-password).
Zwei-Faktoren Benutzeridentifizierung für Linux Consolen Login
Um die TOTP 2FA für das Linux Consolen Login (Text-Screen direkt auf dem Client oder dem Server) zu aktivieren, ändern Sie die Datei /etc/pam.d/login als root Benutzer entsprechend dem folgenden Beispiel:
#The PAM configuration file for the Shadow ‘login’ service
auth optional pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth requisite pam_nologin.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#parsing /etc/environment needs “readenv=1”
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
#Standard Un*x authentication.
@include common-auth
session optional pam_motd.so noupdate
#MODIFICATION: required for Google Authenticator 2FA
auth required pam_google_authenticator.so
#This allows certain extra groups to be granted to a user
auth optional pam_group.so
#Sets up user limits according to /etc/security/limits.conf
session required pam_limits.so
#Prints the last login info upon successful login
session optional pam_lastlog.so
#Prints the message of the day upon successful login.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
#
session optional pam_mail.so standard
#Create a new session keyring.
session optional pam_keyinit.so force revoke
#Standard Un*x account and session
@include common-account
@include common-session
@include common-password
Zwei-Faktoren Benutzeridentifizierung für Linux GUI (GDM Oberfläche)
Um die TOTP 2FA für den Ubuntu Window-Manager GDM zu aktivieren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benutzer entsprechend dem folgenden Beispiel:
#%PAM‑1.0
auth requisite pam_nologin.so
auth required pam_succeed_if.so user != root quiet_success
@include common-auth
#Required for Google Authenticator 2FA
auth required pam_google_authenticator.so
auth optional pam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_limits.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-session
session optional pam_gnome_keyring.so auto_start
@include common-password
Zwei-Faktoren Benutzeridentifizierung 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 folgenden Beispiel:
#PAM configuration for the Secure Shell service
#Standard Un*x authentication.
@include common-auth
session optional pam_motd.so noupdate
#Required for Google Authenticator 2FA
auth required pam_google_authenticator.so
account required pam_nologin.so
#Standard Un*x authorization.
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
session optional pam_keyinit.so force revoke
#Standard Un*x session setup and teardown.
@include common-session
session optional pam_motd.so motd=/run/motd.dynamic
#session optional pam_motd.so noupdate
session required pam_limits.so
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
@include common-password
Der Linux GUI 2FA Login
Der Linux Consolen 2FA Login
Der Linux Remote SSH 2FA Login
Google Authenticator Sicherheitsüberlegungen
Der zweite Faktor der Benutzeridentifizierung beim Google Authenticator ist ein Code der über eine Smartphone App generiert wird. Diese vier Angriffsvektoren sind offensichtlich:
1. Angriff auf den kryptographischen Algorithmus
Der vom Google Authenticator PAM Modul benutzte TOTP 2FA Methode basiert auf dem RFC 6238, siehe Link. Der RFC wurde 2011 veröffenticht, die Entwürfe dazu gehen aber bis April 2008 zurück. Das sind aktuell (August 2019) bereits über 11 Jahre die der Algorithmus gealtert ist.
Genau da setzt einer der Angriffe an, gelingt es nämlich bereits zwei Codes abzufangen kann man das Secret in nur wenigen Minuten errechnen.
Der von linux-ninja dokumentierte Angriff benötigt eine Datei test.hash im Format $TOKEN:$TIMESTAMP
z.B:
833060:1263384780
549115:1528848780
Dann kann man mit dem hashcat Tool unter Linux potentielle Secret Keys errechnen, die in der Datei totp.potfile gespeichert werden.
$ hashcat ‑m17300 ‑a3 ‑o totp.potfile test.hash ?l?l?l?l?l?l?l
Zu guter letzt, muss man die errechneten potentiellen Secret Keys nach der gefundenen Häufigkeit sortieren und hat eine Kopie des streng geheimen Secret Keys.
$ cut ‑d: ‑f3 totp.potfile | sort | uniq ‑c | sort ‑nr | head
Mit einer normalen Notebook Grafikkarte rechnet das hashcat Tool gerade mal knapp über 1 Stunde an den Ergebnissen. Das birgt ein hohes Sicherheitsrisiko für diesen zweiten Faktor!
2. Angriff auf das Smartphone
Der Secret Key, der die TOTP Codes generiert, ist im Smartphone gespeichert. Gelangt man an ein Backup des Smartphones oder kann man wie bei Android üblich auf die Datenbanken/Dateien des Mobiltelefons zugreifen hat man so einfachen Zugriff auf den Secret Key und erstellt eine Kopie des Schlüssels.
Speziell in BYOD Umgebungen, wo 2FA Benutzer ihre eigenen Smartphones mit einer frei gewählten Authenticator App für die Zwei-Faktoren-Authentisierung nutzen gibt es zu wenig Kontrolle über die Sicherheit der gespeicherten Schlüssel.
3. Man-in-the-Middle Angriffe / Phishing Angriffe
Gelingt es einem Angreifer über Phishing Seiten, gefälschte DNS Einträge oder über das Aufbrechen von HTTPS Verbindungen eine gefälschte Webseite oder einen falschen Server dem Benutzer zu präsentieren, wird dieser seine Zugangdaten und auch den Google Authenticator Code auf dem gefälschten Dienst eingeben. Dieser Man-in-the-Middle Angriff leitet dann die abgefangenen Zugangsdaten und den Google Authenticator Code an den richtigen Dienst weiter, meldet den Benutzer an und hat fortan die volle Kontrolle über den gesamten Datenverkehr dieser Verbindung.
Sobald ein Angreifer zweimal den Benutzer getäuscht hat, hat der Angreifer zwei Codes über die er wiederum mit dem hashcat Tool den Secret Key errechnen kann und dann unbemerkt den Account nutzen kann.
4. Brute-Force Angriffe
Dienste welche die Anzahl der Authentisierungsversuche nicht limitieren können auch über Brute-Force Angriffe attackiert werde. Hier versucht der Angreifer automatisiert eine große Anzahl an Codes in kurzer Zeit aus und da es sich “nur” um 999 999 mögliche Codes handelt, ist dieser Angriff technisch keine Hürde.
[…] die Zwei-Faktoren-Benutzeridentifizierung (2FA, Zwei-Faktor-Authentisierung) mit dem Google Authenticator und mit einer 2FA Smartcard unter Linux ausführlich getestet und die Implementierung […]
Der Punkt “1. Angriff auf den kryptographischen Algorithmus” ist KEIN Angriff auf den Algorithmus selbst, sondern auf den geheimen Wert. In dem erwähnten Artikel konnte das Secret “hashcat” rasch geknackt werden. Gute Implementierungen verwenden ein 20 Byte Scret (160 Bit), das dem Angriff etwa 1298074214633706907132624082305024 (2 hoch 110) Stunden standhalten sollte.
Danke für den Hinweis! Na dann ist es leider um so trauriger, dass die häufig genutzten MFA Authenticator Apps so eine schlechte Implementierung nutzen.
Ich bin ohnehin mehr ein Freund einer starken kryptogaphischen Authentisierung mit X.509 Zertifikaten, egal ob von einer Smartcard, einem Token wie dem Yubikey oder mit Hilfe einer Smartphone App.