RSS-Feed
News
Jul
10
EV-Zertifikate von DigiCert werden kurzfristig für ungültig erklärt
Gepostet von Andreas Wolske an 10 Juli 2020 16:23

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:

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:


Lesen Sie weiter »



Jul
1

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.



Lesen Sie weiter »



Jun
24
CVE-2019-11477/78/79 - Sicherheitslücke im Linux Kernel (TCP SACK Panic)
Gepostet von Andreas Wolske an 24 Juni 2019 15:00

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.

CVE Betroffenes OS Auswirkung
CVE-2019-11477 Linux mit Kernel > 2.6.29 "Integer Overflow" bei der Verarbeitung von SACK- Anfragen.
Führt zur "Kernel Panic" und Neustart des betroffenen Systems.
CVE-2019-11478 Linux mit Kernel < 4.14.127 Langsame Verarbeitung von SACK- Anfragen.
Führt zur Überlastung des betroffenen Systems.
CVE-2019-11479 Linux Führt zur Überlastung des betroffenen Systems.

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:

 


Lesen Sie weiter »



Mai
6
Fehler in Firefox - Add-Ons werden deaktiviert
Gepostet von Andreas Wolske an 06 Mai 2019 08:32

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:

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:

Die Erweiterung kann folgendermassen installiert werden:

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

 

 


Lesen Sie weiter »



Aug
22
CVE-2018-3620 & CVE-2018-3646 - Sicherheitslücken in CPUs
Gepostet von Andreas Wolske an 22 August 2018 13:48

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:

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:

 


Lesen Sie weiter »



Mai
14
CVE-2018-0886 - CredSSP - Windows RDP funktioniert nach Update nicht mehr
Gepostet von Andreas Wolske an 14 Mai 2018 11:32

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

 


Lesen Sie weiter »