Mehr lesen: Ein Unternehmen, das für die Vertrauenswürdigkeit von Websites bürgt, hatte so schwache geheime Schlüssel, dass 8 davon geknackt wurden
Java, die Programmiersprache, auf der Teku und Besu basieren, prüft standardmäßig nicht, ob ein Zertifikat widerrufen wurde. Deshalb vertrauten die Docker-Images von Teku den ungültigen Zertifikaten weiterhin, obwohl Browser sie bereits nicht mehr akzeptierten.
Wie Validatoren Geld verlieren könnten
Ein Angreifer, der sich zwischen einem Validator und einem Dienst positioniert, mit dem dieser sich verbindet, könnte sich als dieser Dienst ausgeben. In seiner Sicherheitsmitteilung erklärte Teku, ein auf diese Weise getäuschter Validator könnte einen Block vorschlagen, der die Gebühren des Validators an die Adresse des Angreifers zahlt.
Ein gefälschter externer Signierer, also der separate Dienst, der die Schlüssel eines Validators verwahrt, könnte Signaturen herausgeben, mit denen sich ändern lässt, wohin die Belohnungen fließen. Teku stufte diese Konfiguration als die riskanteste ein.
„Ein standardmäßig konfigurierter Teku-Knoten im Mainnet ist nicht betroffen und erfordert keine Maßnahmen“, schrieb das Team und fügte hinzu: „Es wurden keine Ausnutzungen gemeldet.“ Consensys Diligence, Tekus Sicherheitspartner, hatte das Problem zuerst gemeldet.
Betreiber, die Teku oder Besu direkt auf ihren Rechnern und nicht in Docker ausführen, müssen Java selbst aktualisieren, da eine Aktualisierung der Ethereum-Software die Liste der vertrauenswürdigen Zertifikate in Java nicht verändert. Auch die neuen Docker-Images beheben nichts an Java, das auf dem Host installiert ist.
Wer noch Java 26 verwendet, hat es allerdings schwerer. Teku zufolge ist diese Version am Ende ihres Lebenszyklus und erhält keine korrigierte Version mehr. Diese Betreiber müssen daher zu Java 25 wechseln.