Security: Grundlagen

Siehe auch

• Security: Tools

Security-Organisationen und deren Profile

• ACSC (Australian Cyber Security Centre)

  • Essential Eight (E8)

  • Information Security Manual (ISM)

• ANSSI (Agence nationale de la sécurité des systèmes d’information)

• C2S (U.S. Government Commercial Cloud Services)

  • ist ein Clone des CIS-Profils

• CIS (Center for Internet Security)

  • Centos Linux 8 Benchmark v1.0.0

  • Red Hat Enterprise Linux 8 Benchmark v1.0.0

  • und viele mehr

• CJIS (Criminal Justice Information Services)

• CNSSI: Committee on National Security Systems Instruction

• CSCF (Centralized Super Computing Facility)

• DISA FSO (Defense Information Systems Agency, Field Security Operations)

  • CCI

  • SRG

  • STIG

• FBI CJIS (Criminal Justice Information Services)

  • Security Policy 103

  • CJIS-5.5.6

• FISMA (Federal Information Security Management Act)

• HIPAA (Health Insurance Portability and Accountability Act)

• ISO

  • ISO 27001

• NIST (National Institute of Standards and Technology)

  • Unclassified Information on Non-federal Information Systems and Organizations

  • ncp: NIST National Checklist Program

  • CL-IL-AL: C No. 1253

  • NIST-800-171

  • NIST-800-53

• PCI-DSS (Payment Card Industry Data Security Standard)

  • v3.2.1 Control Baseline

• USGCB: United States Government Configuration Baseline

Threat Modelling: Was ist Bedrohungsmodellierung?

Bei der Threat-Modellierung wird ermittelt, gegen welche relevanten Bedrohungen man sich schützen möchte. Es hilft sicherzustellen, dass Systeme einen angemessenen Schutz bieten, ohne die Benutzer mit übermässig komplizierten Sicherheitshürden zu belasten.

Beispiel: Es soll ein Auto geschützt werden. Ohne nach dem „vor was“ zu fragen, wird man die falschen Schutzmassnahmen umsetzen, beispielsweise indem man eine dicke Mauer zieht und einenen Kanal mit Krokodilen um das Auto legt. Das schützt vielleicht vor Diebstahl, aber nicht vor schwerem Hagel, wofür ein einfaches Dach genügt hätte.

Wie Threat-Modelling in der IT konkret aussehen kann, zeigt der Artikel Attack Tree auf Wikipedia

Kryptographische Protokolle

Eine grobe Zusammenfassung, was die Protokolle ausmacht und was sie voneinander unterscheidet.

Secure Sockets Layer (SSL)

Ursprünglich 1994 für die Absicherung von HTTP durch Netscape entwickelt, wofür es bis heute hauptsächlich eingesetzt wird. Der Aufruf „https://“ führt zu einem „HTTP auf einer SSL-Schicht“. SSL ist jedoch nicht spezifisch auf HTTP zugeschnitten, sondern wird auch unterhalb von IMAP, POP3, SMTP usw. verwendet. Die SSL-Versionen 2 und 3 gelten als unsicher. Auf ihren Einsatz sollte verzichtet werden.

Transport Layer Security (TLS)

TLS v1.0 enstand 1999 und meldet sich im Header als „SSL v3.1“. Die konkrete Implementierung OpenSSL bietet unter anderem das Kommandozeilenprogramm openssl zum Beantragen, Erzeugen und Verwalten von Zertifikaten. Die Funktionsweise ist zweigeteilt.

1. Authentifizierung:

   Der Server identifiziert sich gegenüber dem Client mit einem X.509-Zertifikat. Der Client überprüft die Vertrauenswürdigkeit des X.509-Zertifikats gegen eine Public-Key-Infrastruktur (PKI) und ob der Servername mit dem im Zertifikat übereinstimmt. Der Client identifiziert sich optional mit einem eigenen Zertifikat (das sogenannte „two-way SSL“).
2. Verschlüsselung:

   Je nach Serverkonfiguration sendet der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder beide berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis, aus dem ein kryptographischer Schlüssel abgeleitet wird. Die gesamte nachfolgende Kommunikation wird mit Hilfe des Schlüssels und nach Aushandlung eines Algorithmus wie AES, 3DES, Arcfour etc. verschlüsselt und zum Schutz von Nachrichten-Integrität und -Authentizität mit einem „Message Authentication Code“ (MAC) abgesichert.

Secure Shell (SSH)

Das seit 1995 entwickelte SSH ist ein auf TCP aufsetzendes Transport- und Benutzerauthentifizierungsprotokoll plus eine Sammlung an Tools. Es wird meist dazu genutzt, eine entfernte Kommandozeile lokal zu verwenden, Dateien auf einen entfernten Rechner zu senden oder von diesem zu kopieren. Die Funktionsweise ist auch hier zweigeteilt.

1. Authentifizierung:

   Der Server identifiziert sich gegenüber dem Client mit einem RSA-, DSA- oder ECDSA-Zertifikat. Der Client identifiziert sich mit einem Passwort oder per Public Key Authentifizierungsmethode (mit einem privaten Schlüssel; sein öffentlicher Schlüssel ist auf dem Server hinterlegt). Private Schlüssel können zusätzlich mit einem Passwort geschützt werden. Weitere Elemente wie YubiKey können zur Authentifizierung hinzugezogen werden.
2. Verschlüsselung:

   Die gesamte nachfolgende Kommunikation wird nach Erzeugung eines geheimen Schlüssels und Aushandlung eines Algorithmus wie AES, 3DES, Arcfour etc. verschlüsselt und zum Schutz von Nachrichten-Integrität und Authentizität mit einem MAC abgesichert.

SSL/TLS ist nicht mit SSH zu verwechseln:

• Eine TLS Server-Authentifizierung ist immer optional. Das Protokoll unterstützt auch einen voll-anonymen Betrieb, bei dem sich keine Seite identifizieren muss. Solche Verbindungen sind anfällig für Man-in-the-Middle-Attacken. Im SSH Transport Layer ist die Server-Authentifizierung Pflicht, was gegen solche Attacken schützt. Zwar könnte ein Client die Prüfung des öffentlichen Serverschlüssels z.B. per .ssh/known_hosts überspringen, trotzdem muss das bewusst implementiert werden.

• TLS authentifiziert Clients und Server mittels X.509-Zertifikaten. Im Vergleich zu SSH erschwert dies den Einsatz von TLS in der Praxis, da es eine funktionierende PKI voraussetzt. Zudem sind Zertifikate komplizierter zu erstellen und zu verwalten; dafür bietet eine PKI ein skalierbares Schlüsselmanagement, was SSH fehlt.

• TLS bietet nur „Public Key“ als Client-Authentifizierungsmethode, also bei weitem nicht die Bandbreite wie SSH.

• TLS kann mit dem Funktionsumfang von SSH nicht mithalten: das SSH Connection Protocol (SSH-CONN) verwendet einen darunterliegenden SSH Transport Layer (SSH-TRANS), um einer Anwendung mehrere logische Datenkanäle zu multiplexen sowie die Möglichkeit zur entfernten Ausführung von Programmen, Terminal-Management, getunnelte TCP-Verbindungen, Flow Control etc. zur Verfügung zu stellen. Werden solche Techniken mit TLS verwendet, ist es kombiniert mit einem anderen Protokoll (z.B. eine HTTP-basierte Passwort-Authentifizierung in einem SSL-Tunnel).

• Beispiel aus der Praxis ist der Unterschied zwischen SFTP und FTPS. SFTP ist SSL-basiertes FTP und wird vom OpenSSH-Daemon umgesetzt - für einen Linux-Server perfekt, auf einem Windows-Server schwierig. Sicheres FTP unter Windows ist meist als FTPS implementiert, also FTP über SSL (Gespann IIS und IE).

Die Gemeinsamkeiten zwischen SSL/TLS und SSH:

• Beide bieten einen Full-Duplex Byte-Stream zu ihren Clients mit kryptographisch abgesicherter Verschlüsselung und Datenintegrität sowie optionaler Benutzerauthentifizierung - in grossen Teilen auf Basis der gleichen Verschlüsselungsalgorithmen.

• Unter Linux wird OpenSSL benötigt, um OpenSSH zu compilieren - jedoch nur, weil OpenSSH Verschlüsselungsbibliotheken aus OpenSSL verwendet; sonst hat OpenSSH nichts mit OpenSSL zu tun.

Schlüsselaustauschverfahren

Andere Begriffe: Key Exchange, Kx, Kex, Handshake Encryption, Key Agreement Protocol

Gängige Verfahren für den Schlüsselaustausch sind:

• Diffie-Hellman (DH):

  1976. Diffie-Hellman-Schlüsselaustausch. Beide Partner senden sich über einen unsicheren Kanal eine Nachricht und berechnen mit Hilfe mathematischer Funktionen den geheimen Schlüssel, die in die eine Richtung (für die Gesprächspartner) schnell, zurück dagegen (für Man-in-the-Middle) nur mit grösstem Aufwand ermittelbar sind. Heute wird die Nachricht mit grossen Primzahlen und diskreten Logarithmen berechnet, zur Verhinderung von Man-in-the Middle-Attacken digital signiert und mit einem MAC abgesichert. Kann im Gegensatz zu RSA nicht dazu verwendet werden, Zertifikate zu signieren.
• ECDH:

  Elliptic Curve Diffie-Hellman. DH-Implementierung mittels elliptischer Kurven. Gruppen auf bestimmten elliptischen Kurven eignen sich für eine effiziente Berechnung von Potenzen, die das Diffie-Hellman-Problem schwer lösbar machen.
• ECDH/ECDSA:

  Elliptic Curve Diffie–Hellman / Elliptic Curve Digital Signature Algorithm. Bietet Forward Secrecy.
• KRB5:

  Kerberos.
• PSK:

  Pre-shared Key. Schlüssel sind vor der Kommunikation beiden Teilnehmern bekannt, zum Beispiel im WLAN (Verschlüsselungsmethode WPA-PSK). Im Internet aufgrund der notwendigen Schlüsselverteilung nicht einsetzbar, hier werden Public-Key-Verfahren eingesetzt.
• RSA:

  1977. War das erste veröffentlichte asymmetrische Verschlüsselungsverfahren überhaupt, entwickelt am MIT. Die Firma RSA Security hat eine schlüsselsignierende Certificate Authority etabliert, die 1995 zu Verisign wurde - in 2013 mit einem Umsatz von knapp 1 Mrd. Dollar. Auch wenn RSA als wahres Multitalent neben Schlüsselaustausch und Authentifizierung noch zur Verschlüsselung eingesetzt werden kann, ist es im Vergleich zu Verfahren wie 3DES und AES mindestens um den Faktor 1000 langsamer. In der Praxis wird RSA daher meist nur zum Austausch eines Schlüssels für die symmetrische Verschlüsselung benutzt (und kommt auch als Verschlüsselungsverfahren unter RHEL / CentOS nicht vor). Für die Verschlüsselung der Daten werden andere Verfahren eingesetzt.

Warnung

SSL-abgesicherte Web-, Mail-, SSH- und VPN-Server verwenden bei DHE_EXPORT die ursprünglich von der US-Regierung abgeschwächten, für den Export zugelassenen Methoden - das heisst, Server und Client dürfen sich damit auf nur 512 Bit breite Primzahlen beschränken, die auf fast allen Systemen auch noch aus nur zweien ausgewählt wird.

Die auf den DH-Algorithmus zielende Logjam-Attacke von Ende Mai 2015 nutzt den Umstand, dass man eine bekannte Primzahl im Vorfeld der Attacke bereits so zerlegen kann, dass der Rechenaufwand zur Rückberechnung des Sitzungschlüssels extrem sinkt (im Schnitt 90 Sekunden).

Abhilfe: Primzahlen ab 2048 Bit Länge verwenden, oder auf DHE verzichten und auf Diffie-Hellman mit elliptischen Kurven (ECDH) umsteigen, dem ein gänzlich anderes mathematisches Problem zugrundeliegt.

Verschlüsselungsverfahren

Andere Begriffe: Cipher, Chiffre, Encoding, Enc

Die Verschlüsselung ist eine Funktion, die abhängig von einem Schlüssel einen Klartext in einen Geheimtext überführt. Mit der Umkehrfunktion erhält man aus dem Geheimtext wieder den Klartext. Verschlüsselungs-Algorithmen unterteilen sich in symmetrische und asymmetrische Methoden.

Das Verschlüsselung von Daten bedeutet, sie so zu ändern, dass es für andere Personen fast unmöglich ist, sie ohne einen Schlüssel lesen zu können. Ein einfaches Beispiel ist die Caesar-Chiffre, bei der jeder Buchstabe im Alphabet um eine feste Anzahl von Zeichen verschoben wird. Bei einer Anzahl von 3 wird ein A zu einem D, ein B wird zu einem E und so weiter. Aus meet me now wird phhw ph qrz. Wenn man nicht weiss, um wie viele Buchstaben verschoben wurde, ist es aufwändig, den Inhalt der Nachricht zu entschlüsseln.

Moderne Verschlüsselung ist natürlich weitaus komplizierter und verwendet mathematische Tricks, um die Entschlüsselung extrem zu erschweren.

Symmetrische Verschlüsselungsverfahren

Bei symmetrischen Algorithmen besitzen beide Kommunikationspartner denselben Schlüssel und müssen diesen vor Beginn der Kommunikation sicher ausgetauscht haben (zum Beispiel mittels Diffie-Hellman-Schlüsselaustausch oder der Zusendung per Post). Der Schlüssel wird zur Verschlüsselung als auch zur Entschlüsselung verwendet. Typische Schlüssellängen sind z.B. 128, 192 oder 256 Bit.

Bemerkung

Das symmetrische Verschlüsselungsverfahren AES mit 128 Bit Schlüssellänge und das asymmetrische Verfahren RSA mit 2048 Bit Schlüssellänge werden 2015 als (gerade) noch ausreichend sicher betrachtet. Es wird empfohlen, AES mit 256 Bit und RSA mit maximal 4096 Bit zu verwenden, falls besonders schützenswerte Daten abgesichert werden müssen. RSA-Schlüssl mit mehr als 4096 Bit verschwenden zu viel Rechenleistung.

Symmetrische Verfahren können Klartext auf zwei Arten verschlüsseln:

1. Bei der Blockverschlüsselung (Block Siphers) wird der Klartext vor der Verschlüsselung in Blöcke gleicher Grösse aufgeteilt. Zu kleine Blöcke werden durch bedeutungslose Zeichen aufgefüllt, so dass sie eine höhere Übertragungskapazität in Anspruch nehmen. Eine typische Blockgrösse ist z.B. 128 Bit. Ein Verschlüsselungsalgorithmus beschreibt zunächst nur, wie ein Block verarbeitet wird. Zur Verarbeitung einer Nachricht beliebiger Länge lassen sich Blockchiffres in verschiedenen Betriebsmodi verwenden. Beispiele für Betriebsmodi („Mode of Operation“) sind:

   • AEAD:

     Authenticated Encryption with Associated Data. Algorithmentypen, die verhindern, dass auf jede beliebige Nachricht die Entschlüsselung angewendet werden kann (z.B. aus Angreifer-Sicht einem „Decryption Oracle“ Brute Force Nachrichten zur Entschlüsselung senden, um diese zu analysieren) - nur korrekt nach Schema verschlüsselte Nachrichten können entschlüsselt werden. Konkrete Verteter dieses Betriebsmodus sind:

     • CCM:

       Counter with CBC-MAC; kombiniert den Counter Mode zur Verschlüsselung mit dem CBC-MAC-Modus zur Integritätssicherung
     • CWC:

       Carter–Wegman with CTR Mode; kombiniert den CTR Mode zur Verschlüsselung mit dem polynomialen Carter–Wegman MAC.
     • EAX:

       2003. Kombiniert den CTR Mode zur Verschlüsselung mit dem OMAC.
     • GCM:

       Galois/Counter Mode; 2004. Basiert auf CTR, auf Parallelität und hohen Datendurchsatz ausgelegt. Kommt auch in Festplatten zum Einsatz. Die GCM-Operation benötigt vier Eingabewerte: einen geheimen Schlüssel, einen Initialisierungsvektor, den Klartext und einen Wert für „additional authenticated data“ (AAD). Er liefert zwei Ergebnisse, den Chiffretext (gleich lang wie der Klartext) und ein Autorisierungs-Tag.
     • IAPM:

       Integrity Aware Parallelizable Mode. War der erste Modus, der Verschlüsselung und Integritätssicherung in einem Schritt erledigte. Verdrängt durch GCM.
     • OCB:

       Offset Codebook Mode; 2001. Erledigt Verschlüsselung und Integritätssicherung in einem Schritt. Verdrängt durch GCM.

   • CBC:

     Cipher Block Chaining; aus dem Jahr 1976. Der Block wird per XOR (exklusives Oder) verknüpft. Sehr gut bei nicht-zufälligen (also alltäglichen) Inhalten. Zerstört Klartextmuster, identische Klartextblöcke ergeben unterschiedliche Geheimtexte, erschwert Angriffe, ist aber anfällig für den Plaintext Recovery Attack, wird daher durch den Vulnerability-Scanner „Nessus“ von Tenable bemängelt.
   • ECB:

     Electronic Codebook; aufgrund von konzeptionellen Schwächen nicht empfohlener Betriebsmodus, da die verschlüsselten Blöcke unter Umständen Rückschlüsse auf die Originalnachricht zulassen. In RHEL nicht verfügbar.
   • OMAC:

     One-key MAC; ähnlich wie CBC. Patentfrei, free for all use.

2. Bei der Stromverschlüsselung (Stream Ciphers) wird der Klartext zeichen- oder bitweise verschlüsselt. Folgende Betriebsmodi schalten eine Blockverschlüsselung in eine Stromverschlüsselung um:

   • CFB:

     Cipher Feedback; ähnlich wie CBC. Klartext wird bitweise XOR (exklusives ODER) verknüpft.
   • CTR:

     Counter Mode. Klartext wird bitweise XOR (exklusives ODER) verknüpft. Der Unterschied zu anderen liegt in der Verknüpfung einer Zufallszahl pro Chiffrat mit einem Zähler.
   • OFB:

     Output Feedback. Klartext wird bitweise XOR (exklusives ODER) verknüpft.

In RHEL / CentOS an der einen oder anderen Stelle verwendete symmetrische Algorithmen sind:

• 3DES, TripleDES:

  1998. Dreifach-DES-Verschlüsselung mit drei unabhängigen, voneinander verschiedenen Schlüsseln. Schlüssellänge 168 („3des(168)“), 112 or 56 Bit, Blockgrösse 64 Bit.
• AES:

  1998. Seit dem Jahr 2000 ist der hinter dem „Advanced Encryption Standard“ steckende Rijndael-Algorithmus ein FIPS. In Intel- und AMD-Prozessoren sind Befehlsinstruktionen für AES nutzbar. Schlüssellänge 128 („aes128“), 192 („aes192“) oder 256 Bit („aes256“). Bei den CBC-Varianten beträgt die Blockgrösse 128 Bit.
• AESGCM:

  2008/2009. AES mit implizitem AEAD-Modus GCM. Hochgradig performant. In TLS erst ab Version 1.2 verfügbar.
• Blowfish (BF):

  1993. Blockverschlüsselung; Schlüssellänge zwischen 32 und 448 Bit (Standard 128 Bit), Blockgrösse 64 Bit. Frei verwendbar, sehr sicher, langsam.
• Camellia:

  2000. Durch Mitsubishi Japan entwickelte Blockverschlüsselung. Wird seit Firefox 37 nicht mehr unterstützt (wichtig bei Einsatz in einem Webserver wie Apache). Schlüssellänge 128, 192 oder 256 Bit, Blockgrösse 128 Bit.
• CAST-128, CAST5:

  1996. CAST5 ist eine alternative Bezeichnung für CAST-128. Schlüssellänge 40 bis 128 Bit, Blockgrösse 64 Bit.
• DES:

  1977. Data Encryption Standard. Blockverschlüsselung; Schlüssellänge 56 Bit, Blockgrösse 64 Bit. DES gilt seit 1999 als kompromittiert, auf den Einsatz sollte verzichtet werden.
• IDEA:

  1991. International Data Encryption Algorithm. Projekt der ETH Zürich und der Ascom Systec AG. Von PES abgeleitete Blockverschlüsselung. Schlüssellänge 128 Bit, Blockgrösse 64 Bit.
• RC2:

  1987. Schlüssellänge 8 bis 1024 Bit (Standard: 64 Bit), Blockgrösse 64 Bit. Die Schlüssel sind aus heutiger Sicht zu kurz, auf den Einsatz von RC2 sollte verzichtet werden.
• RC4, ARCFOUR, ARC4:

  1987. „Rivest Cipher 4“ (RC4) ist ein kommerzielles Produkt sowie ein eingetragenes Warenzeichen, daher wird, um Trademark-Probleme zu vermeiden, oft von ARCFOUR bzw. ARC4 geredet. Das ursprünglich geheimgehaltene Protokoll wurde 1987 geleakt. Stromverschlüsselung, Schlüssellänge zwischen 40 und 2048 Bit. Mozilla und Microsoft empfehlen aufgrund von Schwachstellen, auf RC4 / ARCFOUR zu verzichten; PuTTY, SSLLabs und Nessus monieren ebenfalls den Einsatz von RC4. Im Februar 2015 wurde RFC 7465 veröffentlicht, der RC4 für Verschlüsselung verbietet.
• Rijndael:

  1998. Wurde im Jahre 2000 als Ersatz für DES zum Advanced Encryption Standard (AES) der US-Behörden erhoben, Details siehe AES.
• SEED:

  1998. Koreanische Blockverschlüsselung, ausserhalb Südkoreas kaum anzutreffen, wird in Webbrowsern auch nicht unterstützt (wurde in Firefox 27 entfernt). Schlüssellänge 128 Bit, Blockgrösse 128 Bit.

Asymmetrische Verschlüsselungsverfahren

Bei einem asymmetrischen „Public-Key-Kryptosystem“ benötigen die kommunizierenden Parteien keinen gemeinsamen geheimen Schlüssel. Ein Benutzer erzeugt hier ein Schlüsselpaar, das aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht.

Die Verfahren werden beispielsweise in SSH, TLS und im E-Mail-Verkehr (OpenPGP, S/MIME) angewendet.

Signierung und Authentifizierung

Andere Begriffe: Au

Diese Algorithmen dienen der Schlüsselerzeugung und Authentifizierung.

• DSA:

  Digital Signature Algorithm. Entworfen von der NSA (FIPS 186-2). DSA benötigt sehr viele und sehr gute Zufallszahlen, was nicht in allen Umgebungen gewährleistet ist. Zudem müssen DSA-Schlüssel exakt 1024 Bit lang sein.
• DSS:

  1991. „Digital Signature Standard“ der NIST. Der Standard umfasst DSA, ECDSA und RSA.

• ECDH

• ECDSA:

  Übertragung des DSA auf elliptische Kurven. Die ECDSA-Schlüssellänge kann 256, 384 oder 521 (richtig gelesen: 521) Bit betragen (entspricht der Grösse der elliptischen Kurve).

• KRB5

• PSK

• RSA:

  768 Bit breite Schlüssel wurden geknackt, bis ins Jahr 2019 sind Schlüssel mit einer Mindestlänge von 1976 Bit geeignet, empfohlen sind mindestens 2048 Bit.

Datenintegritätsverfahren

Andere Begriffe: MACs, Hash, Message Digest, Digest Algorithms, Hash Function

Ein „Message Authentication Code“ (MAC) sichert den Ursprung von Daten und prüft ihre Integrität. MAC-Algorithmen erfordern zwei Eingabeparameter, erstens die zu schützenden Daten und zweitens einen geheimen Schlüssel, und berechnen aus beidem eine Prüfsumme, den Message Authentication Code.

• MD5:

  1991. Message-Digest Algorithm 5. Erzeugt auf heutigen Systemen sehr performant einen 128 Bit breiten Hashwert. Gilt in kryptografischen Verfahren als nicht mehr sicher, da es mit überschaubarem Aufwand möglich ist, unterschiedliche Nachrichten zu erzeugen, die den gleichen MD5-Hashwert aufweisen.
• RIPEMD:

  1996. In Belgien offen entwickelte, kryptographische Hash-Funktion. Erzeugt 128, 160, 256 oder 320 Bit breite Hashes.
• SHA-1 / SHA1:

  1993. Von der NSA entwickelt. Erzeugt 160 Bit breite Hashes. Gilt seit 2005 als kompromittiert. Microsoft Windows und Mozilla Firefox werden ab 2017 SHA-1-Zertifikate über SSL nicht mehr akzeptieren, simpleSAMLphp erlaubt SHA-1 seit dem 01.01.2014 nicht mehr.
• SHA256:

  Hash-Funktion mit 256 Bit breitem Hashwert. SHA256 ist ein Vertreter aus der Gruppe der kryptographischen SHA-2-Funktionen (Nachfolger von SHA-1). Von der NSA entwickelt.
• SHA384:

  wie SHA256, jedoch mit 384 Bit breitem Hashwert.

MAC-Verfahren werden unterschiedlich klassifiziert:

• hmac:

  Keyed-Hash MAC. Das MAC-Verfahren basiert auf einer kryptographischen Funktion und wird auch so benannt, z.B. „hmac-md5“.
• umac:

  MAC based on Universal Hashing. Der MAC wird aus einer Gruppe von MAC-Verfahren nach einem geheimen, zufälligen Prozess ausgewählt.

Reihenfolge MAC-Berechnung vs. Verschlüsselung

Was sollte zuerst erfolgen - die MAC-Berechnung und dann die Verschlüsselung, oder umgekehrt? Siehe auch den Wikipedia-Artikel zum Thema Authenticated Encryption.

• MAC-then-Encrypt:

  Hash auf den Klartext berechnen, an den Klartext anhängen, dann beides zusammen verschlüsseln (Standard in TLS - war eine Fehlentscheidung beim Design; so wurde Padding Oracle POODLE möglich)
• Encrypt-and-MAC:

  Hash auf den Klartext berechnen, Klartext verschlüsseln, Hash anhängen (Standard in SSH)
• Encrypt-then-MAC (etm):

  Klartext verschlüsseln, Hash berechnen und anhängen (Standard in IPSec)

Encrypt-then-MAC (etm) ist in den meisten Fällen das ideale Szenario. Änderungen am verschlüsselten Text können ohne gültigen MAC schon vor der Entschlüsselung verworfen werden. Der MAC kann ausserdem nicht verwendet werden, um auf den Klartext zu schliessen.

MAC-then-Encrypt ist sicher, wenn die Verschlüsselungsfunktion im CBC- oder allgemein im Stream-Modus arbeitet; ansonsten könnten bei MAC-then-Encrypt und Encrypt-and-MAC aufgrund der auf den Klartext angewendeten MAC-Funktion Daten rekonstruiert werden.

Auf Schwachstellen prüfen

CVE-2021-44228 Log4j Unauthenticated RCE Vulnerability

So testet man am einfachsten, ob der eigene Dienst betroffen ist:

• „log4shell“-Token auf https://canarytokens.org erstellen (Select your token > Log4Shell), und die eigene E-Mail-Adresse hinterlegen. Das Token hat dann die Form ${jndi:ldap://x${hostName}.L4J.u2abcx2.canarytokens.com/a}

• Möchte man zum Beispiel seine Web-Anwendungen testen, den generierten Token-String in von der Anwendung bereitgestellte Web-Formulare einkopieren (z.B. in die Felder der Login-Maske), per curl --user-agent '<token-string>' einen Request senden, oder ähnliches. Man erhält ein Mail, wenn die Maschine den Inhalt des Tokens ausführen konnte (was nicht passieren sollte).

CVE-2022-0847 Dirty Pipe - kernel arbitrary file manipulation

Proof-of-Concept Exploit: https://dirtypipe.cm4all.com/

• Theoretisch sind nur die Kernel-Versionen 5.10, 5.15 und 5.16 betroffen. Ein Rocky 8 fährt z.B. 4.18.

• Gefixt wurde das in 5.10.102, 5.15.25 und 5.16.11.

• Fedora Server 35 mit Kernel 5.16 ist bereits gepatcht (2022-03-08).

• In der Praxis haben die üblichen Red Hat Backports aber dazu geführt, dass deren 4.18er-Kernel bis und mit 4.18.0-348 ebenfalls affected ist.

• Für den Test auf den CVE gibt es folgendes Script: https://access.redhat.com/sites/default/files/cve-2022-0847–2022-03-07-1646.sh

• Bei den RHEL-basierten Maschinen (RHEL, CentOS, Rocky, Alma etc.) warten wir auf den Patch (2022-03-08).

Built on 2024-04-18