Signatur der Installationsdaten / Updates?

Technische Grundlagen
1

Moin!

Ich habe gerade ein verinice Update installiert und die Eclipse Platform fragte mich, ob ich unsignierten Paketen trauen wolle.

Nun arbeiten wir ja hier mit einem kommerziellen Produkt, dass sich auch noch auf IT-Sicherheitsthemen spezialisiert. Da erwarte ich eigentlich, dass die Updates korrekt signiert sind, um Supply-Chain-Angriffen wenigstens etwas entgegenzustellen. (vgl NotPetya)

Ich hab hier genau genommen auch eine Policy, die genau das besagt: „Unsignierte Programm-Updates sollen nicht installiert werden“ - Wenn ich mich als ISB da schon nicht dran halten kann…

Wann ist hier mit korrekt signierten Updates zu rechnen? Ist ja kein Hexenwerk (das weiss ich, weil ich auch bei uns die Pipelines dafür gebaut habe)

LG

2 „Gefällt mir“
2

Hallo msiebert,

die besagte Meldung stammt vom Eclipse-Update-Prozess, der die Signatur der Java-Archive (JAR-Files) mit Hilfe des „JAR Signing“ Mechanismus der Java Plattform überprüft. Wir verwenden diesen Mechanismus derzeit nicht. Das liegt zum einen daran, dass fast keine der von uns eingesetzten OpenSource-Komponenten signierte JAR-Files veröffentlicht. Zum anderen verwenden wir stattdessen aktuell gängigere Methoden, um die Integrität unserer Programmdateien zu gewährleisten:

  • wir veröffentlichen die SHA256-Signaturen für alle Download-Artefakte auf unserem Server, z.B.:
5d744e6ed4834c00ef8f18d412416dc73b3291e74f9e144c3a0f1e2ee7406eca  ./verinice-linux.gtk.x86_64-1.26.1.zip
0ab35e9405c4f6c7c618476b3fb0c5d7aebf444c861b6ad69ec0effea1e31621  ./verinice-win32.win32.x86_64-1.26.1.zip
cfd14ae806f5f06b0899523fb2eeec5a8f861e2671fe2eb59b62b2e5696ed3d6  ./verinice-macosx.cocoa.x86_64-1.26.1.zip
5d744e6ed4834c00ef8f18d412416dc73b3291e74f9e144c3a0f1e2ee7406eca  ./verinice-linux.gtk.x86_64-1.26.1.zip
0ab35e9405c4f6c7c618476b3fb0c5d7aebf444c861b6ad69ec0effea1e31621  ./verinice-win32.win32.x86_64-1.26.1.zip
cfd14ae806f5f06b0899523fb2eeec5a8f861e2671fe2eb59b62b2e5696ed3d6  ./verinice-macosx.cocoa.x86_64-1.26.1.zip
  • wir verteilen Software-Updates ausschließlich über HTTPS von unserem eigenen Repository-Server https://update.verinice.com. Die von dort bezogenen Pakete sind vertrauenswürdig und ihre Integrität wird durch die Transportverschlüsselung per TLS gewährleistet.
  • wir signieren die verinice Programmdatei mit einem offiziellen EV Code Signing Certificate von Globalsign, welches die geprüfte Identität der SerNet GmbH als Herausgeber der Software bestätigt:
    Screenshot 2023-09-05 085420
    Screenshot 2023-09-05 085420819×591 32.9 KB

Diese Signatur wird von Endpoint-Security Tools wie MS Smart Screen und Applocker unterstützt.

Wir prüfen, ob das Signieren der JAR-Dateien einen Sicherheitsgewinn bedeuten würde - dabei müssen wir allerdings damit umgehen, dass wie o.g. kaum ein OpenSource-Projekt seine JAR-Files signiert. Auch dort werden stattdessen die SHA-Checksums veröffentlicht, die im Build-Prozess verifiziert werden können (z.B. https://repo1.maven.org/maven2/org/springframework/boot/spring-boot/3.1.3/ ). Ich habe einen Vorgang angelegt, um diesen Sachverhalt erneut in der Entwicklung zu prüfen und mögliche Lösungsansätze (Re-Packaging und Signieren unserer Dependencies) zu diskutieren.

2 „Gefällt mir“
3

Verinice wird vom Virenscanner blockiert/gemeldet ist da ein guter reminder - das waere so nicht passiert, oder?