Wenn sie ausgenutzt werden, können diese Schwachstellen Angreifern den unbefugten Zugriff auf vertrauliche Informationen ermöglichen oder allgemein Probleme verursachen
Vor ein paar Tagen, GitHub enthüllt Durch einen Blogbeitrag, der Details zu einer Schwachstelle Dadurch können Sie auf den Inhalt von Umgebungsvariablen zugreifen, die in Containern bereitgestellt werden, die in Ihrer Produktionsinfrastruktur verwendet werden.
Die Schwachstelle wurde von einem Teilnehmer des Bug-Bounty-Programms entdeckt, das darauf abzielt, Sicherheitsprobleme zu finden und Forscher für ihre Ergebnisse zu belohnen. Dieses Problem betrifft sowohl den GitHub-Dienst als auch zu den Konfigurationen GitHub Enterprise-Server (GHES), die auf den Systemen der Benutzer ausgeführt werden.
Die Sicherheitslücke, katalogisiert unter CVE-2024-0200 mit einem hohen Schweregrad von 7.2 (CVSS), wurde in der Natur nicht ausgebeutet, Es wird erwähnt, dass nach der Analyse der Aufzeichnungen und der Prüfung der Infrastruktur keine Hinweise auf eine Ausnutzung der Schwachstelle in der Vergangenheit gefunden wurden, mit Ausnahme der Aktivität des Forschers, der das Problem gemeldet hat. Als vorbeugende Maßnahme haben wir jedoch alle Verschlüsselungsschlüssel und Anmeldeinformationen ersetzt, die gefährdet sein könnten, wenn ein Angreifer die Sicherheitslücke ausnutzt.
GitHub Enterprise Server (GHES) soll betroffen sein, aber Um die Sicherheitslücke auszunutzen, ist ein authentifizierter Benutzer mit der Rolle „Besitzer“ erforderlich der Organisation melden sich bei einem Konto auf der GHES-Instanz an, wodurch das Potenzial für Ausnutzung begrenzt wird.
Diese Schwachstelle ist auch im GitHub Enterprise Server (GHES) vorhanden. Allerdings erfordert der Exploit, dass sich ein authentifizierter Benutzer mit der Rolle „Organisationsbesitzer“ bei einem Konto auf der GHES-Instanz anmeldet, was wichtige mildernde Umstände für einen potenziellen Exploit darstellt. Ein Patch ist heute, 16. Januar 2024, für die GHES-Versionen 3.8.13, 3.9.8, 3.10.5 und 3.11.3 verfügbar. Wir empfehlen GHES-Kunden, den Patch so schnell wie möglich anzuwenden.
Die Abwanderung von Zugangsdaten auf unseren Produktionssystemen führte zwischen dem 27. und 29. Dezember zu einer Reihe von Dienstausfällen. Wir sind uns der Auswirkungen bewusst, die sie auf unsere Kunden hatten, die sich auf GitHub verlassen, und haben unsere Verfahren zur Anmeldeinformationsrotation verbessert, um das Risiko ungeplanter Ausfallzeiten in der Zukunft zu verringern.
Es lohnt sich das zu erwähnen Die Schwachstelle in GitHub wurde behoben und ein Update veröffentlicht In der Produktveröffentlichung für GHES 3.8.13, 3.9.8, 3.10.5 und 3.11.3 charakterisierte GitHub die Schwachstelle in GHES als einen Fall der „unsicheren Verwendung von Reflection“, der das Risiko von Reflection-Injection und Remote-Codeausführung birgt (wie Diese Arten von Schwachstellen führen zur Codeausführung oder zu benutzergesteuerten Methoden auf der Serverseite.
Der Austausch dieser internen Schlüssel führte vom 27. bis 29. Dezember zu einer Unterbrechung einiger Dienste. GitHub-Administratoren haben versucht, aus Fehlern zu lernen, die bei der Aktualisierung von Schlüsseln gemacht wurden, die sich auf Kunden auswirken.
Zu den ergriffenen Maßnahmen gehörten aktualisierter privater GitHub GPG-Commit-Signaturschlüssel Dies wird zum Signieren der Commits verwendet, die Sie auf GitHub erstellen. Dazu gehören Commits, die im Webeditor, über einen Codespace, über die Befehlszeile in einem Codespace oder über Pull-Request-Vorgänge oder über Codespace erstellt wurden. Der alte Schlüssel wurde am 16. Januar ungültig und seitdem wird ein neuer Schlüssel verwendet. Ab dem 23. Januar werden alle neuen Commits, die mit dem alten Schlüssel signiert wurden, auf GitHub nicht mehr als verifiziert markiert. Am 16. Januar wurden auch die öffentlichen Schlüssel aktualisiert, die zum Verschlüsseln von Benutzerdaten verwendet werden, die über die API an GitHub Actions, GitHub Codespaces und Dependabot gesendet werden.
Darüber hinaus Benutzern wird empfohlen, diese GitHub-eigenen öffentlichen Schlüssel zu verwenden, um Commits lokal zu überprüfen und verschlüsseln Sie Daten während der Übertragung, um sicherzustellen, dass Sie Ihre GitHub-GPG-Schlüssel aktualisiert haben, sodass Ihre Systeme nach einer Schlüsseländerung weiterhin funktionieren.
schließlich, wenn Sie sind daran interessiert, mehr darüber zu erfahren, Sie können die Details überprüfen im folgenden Link.