Aufgrund der nicht korrekten Einhaltung von Richtlinien zur Ausstellung entzieht DigiCert TLS-Zertifikaten das Vertrauen.

Die Zertifikate müssen bis 11.07.2020 um 20:00 Uhr MESZ ersetzt werden. Die Information erreichte uns sehr kurzfristig, sodass dringender Handlungsbedarf bei allen Kunden besteht, die EV-Zertifikate einsetzen. Davon betroffen sind Zertifikate folgender Aussteller:

• CertCentral
• Symantec
• Thawte
• GeoTrust

bzw. alle Zertifikate, die von folgenden Root-CAs unterschrieben wurden

• DigiCert Global CA G2
• GeoTrust TLS RSA CA G1
• Secure Site CA
• Thawte TLS RSA CA G1
• Cybertrust Japan Secure Server ECC CA
• DigiCert Global CA G3
• GeoTrust TLS ECC CA G1
• Thawte TLS ECC CA G1
• NCC Group Secure Server CA G3
• Aetna Inc. Secure CA2
• DigiCert SHA2 High Assurance Server CA
• NCC Group Secure Server CA G2
• Plex Devices High Assurance CA2
• TERENA SSL High Assurance CA 3
  
  

Weiterführende Informationen:

• https://www.heise.de/news/Jetzt-handeln-DigiCert-erklaert-zehntausende-TLS-Zertifikate-fuer-ungueltig-4840972.html
• https://knowledge.digicert.com/alerts/DigiCert-ICA-Replacement

Apple, die Mozilla Foundation (FireFox) und Google haben beschlossen, dass ihre Browser für alle ab dem 01.09.2020 ausgestellten Zertifikate nur noch eine maximale Gültigkeitsdauer von einem Jahr (398 Tage, d. h. 1 Jahr + 1 Monat Karenz) akzeptieren. Damit wurde die erst von 5 Jahren auf 3 und dann auf 2 Jahre verkürzte Gültigkeitsdauer von Zertifikaten erneut beschnitten, was letztlich in einem erhöhtem Administrationsaufwand für nicht bspw. per Let's Encrypt automatisierbare Zertifikate mündet.

Begründet wird das immer wieder mit der nicht unumstrittenen Meinung der Browserhersteller, dass Mechanismen zur Gültigkeitsprüfung (wie z. Bsp. CRLs oder OCSP) ungeeignet oder sogar wirkungslos sind.

Da automatisierbare Alternativen wie Let's Encrypt aufgrund der geltenden Standards keine Class 3- oder EV- Zertifikate ausstellen dürfen, bleibt für alle Zertifikate mit Identitätsnachweis nur die jährliche Erneuerung inklsuive des damit verbundenen Aufwands.

Wir empfehlen deshalb, alle Zertifikate die bis Ende des ersten Halbjahres 2021 ablaufen, noch vor dem 01.09.2020 um die dann letzmalig möglichen 2 Jahre zu verlängern.

Mitarbeiter des Streaming- Dienstes NetFlix haben Sicherheitslücken im Netzwerkstack des Linux-Kernels entdeckt, welche sich für DoS- Angriffe ausnutzen lassen.

Die Sicherheitslücke CVE-2019-11477 (TCP SACK Panic), für die alle Linux-Kernel ab einschließlich Version 2.6.29 anfällig sind, wird von RedHat als "wichtig" eingestuft, da sich dadurch aus der Ferne eine Kernel Panic und damit ein Neustart des Systems auslösen lassen. Betroffene Systeme sollten kurzfristig aktualisiert werden.

Ob Ihr System betroffen ist, kann man unter RHEL 6/7 oder CentOS 6/7 mit dem von Red Hat bereitgestellten Script überprüfen. Das Script kann auch über den am Ende des Artikels befindlichen Link heruntergeladen werden.

Für RHEL 6/7 oder CentOS 6/7 liegen mit dem aktuellen Kernel- Versionen bereits Patches vor, die nicht mehr für o.g. Sicherheitslücken anfällig sind:

• RHEL 7 / CentOS 7: Ab Kernel Version 3.10.0-957.21.3.el7
• RHEL 6: Ab Kernel Version 2.6.32-754.15.3.el6
• CentOS 6: Derzeit noch kein aktueller Kernel verfügbar.

Eine von NetFlix als schneller Workaround empfohlene Methode für alle Systeme ist die Kontrolle der SACK-Pakete mittels entsprechender Regeln:

-A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP

Alternativ kann man TCP SACK auch komplett deaktivieren:

echo 0 >  /proc/sys/net/ipv4/tcp_sack

Permanent sind diese Einstellungen per sysctl möglich. Dazu sind in /etc/sysctl.conf folgende Ergänzungen nötig:

net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Diese Einstellungen können anschließen mittels sysctl -p aktiviert werden und bleiben auch nach einem Neustart des Systems wirksam.

Nach unserer Einschätzung dürften diese Lücken künftig eher zu Angriffen auf im Internet erreichbare IoT-Geräte ausgenutzt werden, da diese in vielen Fällen keine oder nur verspätete Updates durch die Hersteller erhalten. Serversysteme, die im Internet auch per ICMP oder SSH erreichbar sind, lassen sich mit einfachen DoS-Amplification Angriffen seit jeher überlasten. Wir empfehlen die zeitnahe Aktualisierung des Kernels und den vorsorglichen Einsatz der Filterregeln zur Vermeidung einer "Kernel Panic".

Weiterführende Informationen:

• NetFlix: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
• Red Hat: https://access.redhat.com/security/vulnerabilities/tcpsack
• Red Hat Test Script: https://access.redhat.com/sites/default/files/cve-2019-11477--2019-06-17-1629.sh
• Ubuntu: https://usn.ubuntu.com/4017-1
• Debian: https://www.debian.org/security/2019/dsa-4465
• SUSE: https://www.suse.com/de-de/support/kb/doc/?id=7023928
• Cloudflare: https://twitter.com/jgrahamc/status/1140724787242819585
• Amazon: https://aws.amazon.com/security/security-bulletins/AWS-2019-005

Mozilla hat es es versäumt, interne Zertifikate für Firefox rechtzeitig zu erneuern. In der Folge werden Add-Ons als ungültig deaktiviert, weil die Zertifikate nicht mehr stimmen:

• https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047
• https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox

In der Zwischenzeit sollten die von Mozilla angekündigten Updates Firefox 66.0.4 für Desktop und Android sowie Firefox 60.6.2 ESR verfügbar sein, die diesen Fehler beheben. Unabhängig von den Updates gibt es folgende Workarounds für ältere Versionen:

Für alle Nutzer älterer ESR Versionen ist folgendes zu tun, bis die Zertifikate erneuert sind:

• Add-Ons deaktiviert lassen, auf keinen Fall deinstallieren
• Konfiguration öffnen: about:config
• Einstellung ändern: xpinstall.signatures.required = false
• FF neu starten

Für neuere Versionen ist ein inoffizieller Hotfix erhältlich:

• https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi

Die Erweiterung kann folgendermassen installiert werden:

• .xpi mit einem anderen Browser runterladen
• In FF über "Erweiterung as Datei installieren" installieren
• FF neu starten

Nach den bereits im Januar veröffentlichen Spectre-Lücken sind jetzt 3 weitere Angriffsvektoren bekannt geworden. Die drei neuen Sicherheitsücken hören auf die Namen:

• Foreshadow (L1 Terminal Fault — SGX) / CVE-2018–3615
• L1 Terminal Fault — OS Kernel, SMM / CVE-2018–3620
• L1 Terminal Fault — Virtual Machines / CVE-2018–3646

Alle Sicherheitslücken ermöglichen, dass Angreifer aus ihren zugewiesenen Speicherbereichen ausbrechen und Daten bzw. Speicherbereiche anderer Prozesse auslesen können, auf die sie eigentlich keinen Zugriff haben sollten. Das ist insbesondere für Serviceprovider kritisch, da hier mehrere VMs von verschiedenen Kunden auf einem physischen Host laufen.

Für die von managedhosting.de betriebene Infrastruktur auf Basis von VMware vSphere hat der Hersteller umfassende Updates zur Schließung der Sicherheitslücke bereitgestellt. Aktuell arbeiten wir bereits an der Aktualisierung der betroffenenen Komponenten. Die Updates der Managed Service Plattformen sowie der vCloud - Director Selfservice Datacenter werden nach jetzigem Stand bis zum 31.08.2018 abgeschlossen sein.

Weiterführenden Informationen finden Sie in der VMware- Wissensdatenbank in folgenden Artikeln:

• https://kb.vmware.com/s/article/54913
• https://kb.vmware.com/s/article/55636
• https://kb.vmware.com/s/article/55767
• https://kb.vmware.com/s/article/55806

Mit Windows Client Updates zu CVE-2018-0886 funktioniert möglicherweise der Fernzugriff per RDP auf Server nicht mehr, wenn der Pachtlevel von Client und Server unterschiedlich ist.

Je nach Patchlevel gibt es verschiedene Fehlermeldungen, z. Bsp. "Windows 7 RDP Authentifizierungsfehler. Die angeforderte Funktion wird nicht unterstützt."

Einzelheiten dazu hat Microsoft in KB4093492 veröffentlicht. Für Nutzer, die dadurch keine Möglichkeit mehr haben auf VMs zuzugreifen, hat Microsoft einen Workaround bereitgestellt. Einzelheiten dazu finden Sie im entsprechenden Blogbeitrag:

Öffnen Sie auf dem Client die Eingabeaufforderung als Administrator und geben Sie folgenden Befehl ein:
 
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

Damit kann der Client in Abhängigkeit des Patchlevel auf dem Ziel eine sichere oder noch veraltete Verbindung aufbauen.

Weiterführende Informationen unter:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

https://blogs.technet.microsoft.com/mckittrick/unable-to-rdp-to-virtual-machine-credssp-encryption-oracle-remediation