- Anzeigen -


Sie sind hier: Home » Fachbeiträge » Grundlagen

Code Signing-Attacken verhindern


Neue Anforderungen für Code-Signing-Zertifikate treten in Kraft
Was heißt das für Entwickler?

- Anzeigen -





Autor: GMO GlobalSign

Das Certification Authority Security Council (CASC) hat seine neuen Minimum Requirements für öffentlich vertrauenswürdige Code- Signing-Zertifikate offiziell bekannt gegeben. Zum ersten Mal sind Zertifizierungsstellen (CAs) damit an eine Reihe von standardisierten Ausstellungs- und Managementrichtlinien gebunden, die speziell für das Code Signing entwickelt wurden. Die Requirements gehen ausführlich auf CA-Richtlinien ein und behandeln Themen wie Zertifikatinhalte, Widerruf- und Statusprüfungen, Verifizierungspraktiken und vieles mehr. Zertifizierungsstellen haben hinter den Kulissen schon recht eifrig daran gearbeitet das Anforderungsprofil umzusetzen.

Was aber heißt das für die Benutzer? Wir wollen einen Blick darauf werfen, welche Anforderungen die User betreffen, die überhaupt Zertifikate zum Signieren von Code benutzen.

Private Schlüssel müssen auf kryptografischer Hardware gespeichert werden
Gemäß CASC ist eine der Hauptursachen für Code Signing-Attacken ein kompromittierter Schlüssel. Das heißt, ein potenzieller Angreifer kann auf den privaten Schlüssel eines legitimen, "guten" Herausgebers zugreifen und verwendet den Schlüssel, um eine schädliche Datei zu signieren. Dadurch wirkt diese Datei vertrauenswürdig und die Chancen steigen, dass sie tatsächlich heruntergeladen wird. Die übliche Methode vor den Requirements war es, den Schlüssel lokal zu speichern. Speichert man ihn aber stattdessen auf einer sicheren kryptografischen Hardware, wie beispielsweise einem USB-Token oder einem Hardware Security Module (HSM), ist es sehr viel unwahrscheinlicher, dass der Schlüssel kompromittiert wird.

Zertifizierungsstellen wie GlobalSign empfehlen schon seit längerem einen stärkeren Schutz des privaten Schlüssels - im Übrigen eine Voraussetzung für das Ausstellen von Extended Validation (EV) Code-Signing-Zertifikaten, seit sie 2014 eingeführt wurden. Unter den neuen Richtlinien wird diese Forderung aber für alle Code-Signing-Zertifikate verbindlich. Insbesondere müssen alle privaten Schlüssel auf FIPS 140-2 Level 2 HSM, einer gleichwertigen On-Premise-Hardware oder in einem sicheren Cloud-basierten Signaturdienst gespeichert werden.

Standardisierte und strikte Identitätsverifizierung
Der andere Hauptgrund für Code-Signing-Attacken, so der CASC, ist, dass Zertifikate an potenzielle Angreifer ausgegeben werden. Die nutzen das Zertifikat dann zum Signieren von Viren oder Malware. Um das zu verhindern, umreißen die neuen Requirements spezielle Vorkehrungen, die Zertifizierungsstellen vor der Ausstellung treffen müssen.

Dazu gehören:
• >> eine strikte Identitätsverifizierung des Herausgebers, wie beispielsweise die rechtliche Identität, Adresse, Gründungsdaten und weitere mehr
• >> ein Abgleich mit Listen von verdächtigen oder bereits bekannten Malware-Herausgebern, -Produzenten und -Vertreibern
• >> die Pflege und der Abgleich einer internen Liste von Zertifikaten, die widerrufen wurden, weil sie zum Signieren von verdächtigen Code- und Zertifikatanforderungen verwendet wurden, und die zuvor von der CA zurückgewiesen wurden

Viele CAs nutzen bereits die meisten dieser Prozesse. Aber eine Standardisierung erschwert es einem böswilligen Herausgeber, sich nach einer CA mit schwächeren Prüfverfahren umzusehen, wenn er von einer anderen bereits abgelehnt wurde.

Melden von und Reagieren auf Zertifikatmissbrauch oder verdächtigen Code
Zu verhindern, dass solche Zertifikate überhaupt ausgestellt werden ist die eine Seite. Die Requirements legen aber zusätzlich fest, dass CAs ein "Certificate Problem Reporting" -System betreiben Hier können Dritte (z. B. Anti-Malware-Anbieter, vertrauenswürdige Parteien, Softwareanbieter) eine "vermutete Kompromittierung eines privaten Schlüssels, Zertifikatmissbrauch, Zertifikate, die zum Signieren von verdächtigem Code verwendet wurden, Takeover-Attacken oder andere Arten von möglichen Betrug, Kompromittierung, Missbrauch, unangemessenem Verhalten oder anderen Dingen im Zusammenhang mit Zertifikaten" melden.

Das hat auch für die CAs Folgen, denn sie müssen sich an sehr strenge Standards hinsichtlich der Reaktion auf solcherart gemeldete Probleme halten. Beispielsweise müssen sie innerhalb von 24 Stunden mit der Untersuchung beginnen und alle Vorfälle rund um die Uhr melden. Es gibt zudem strenge Richtlinien und einen Zeitrahmen hinsichtlich des Widerrufs, für den Fall, dass Malware oder eine andere Art von Missbrauch vermutet wird.

Die neuen Meldesysteme sorgen dafür, dass selbst dann, wenn ein böswilliger Herausgeber den Verifizierungsprozess übersteht, sein Zertifikat umgehend gemeldet, untersucht und widerrufen werden kann.

Alle CAs müssen Zeitstempel haben
Eine weitere Anforderung, die besonders für Entwickler von Interesse sein kann, ist, dass alle CAs jetzt eine RFC-3161-kompatible Timestamp Authority (TSA) betreiben müssen. Und sie muss für alle Code-Signing-Kunden verfügbar sein. So kann man jeder Signatur einen vertrauenswürdigen Zeitstempel zuordnen.

Der Hauptvorteil eines Zeitstempels liegt darin, dass die Signatur nicht abläuft, wenn das Zertifikat abläuft. Das würde normalerweise ohne den Zeitstempel passieren. Stattdessen können Signaturen für die Lebensdauer des Zeitstempelzertifikats gültig bleiben, laut den Requirements bis zu 135 Monaten. Es gibt aber noch ein Szenario, das von einer Zeitstempelung profitiert: Wenn ein Schlüssel kompromittiert wurde und das Zertifikat widerrufen wird. Wenn ein Schlüssel beispielsweise dazu verwendet wurde, legitimen Code zu signieren, dann aber kompromittiert und zum Signieren von bösartigem Code verwendet wurde, kann man das Widerrufsdatum zwischen die beiden Ereignisse legen. Auf diese Weise ist der legitime Code weiterhin vertrauenswürdig, der schädliche Code aber nicht.

Eine sicherere Zukunft für Code Signing
Die neuen Standards und Requirements tragen ganz entscheidend dazu bei Code- Signing-Angriffe zu reduzieren. Microsoft ist der erste Anbieter von Anwendungssoftware, der die Richtlinien übernimmt und am 1. Februar 2017 damit beginnt sie umzusetzen.
(GMO GlobalSign: ra)

eingetragen: 22.01.17
Home & Newsletterlauf: 08.02.17


GMO GlobalSign: Kontakt und Steckbrief

Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.

- Anzeigen -





Kostenloser IT SecCity-Newsletter
Ihr IT SecCity-Newsletter hier >>>>>>

- Anzeigen -


Meldungen: Grundlagen

  • Was ist Certificate Transparency?

    Möglicherweise haben Sie schon vor einigen Jahren von Certificate Transparency (CT) gehört, als Google die Anforderung für alle Extended Validation (EV) SSL/TLS-Zertifikate ankündigte, die nach dem 1. Januar 2015 ausgestellt worden sind. Seitdem hat Google die Anforderung auf alle Arten von SSL-Zertifikaten ausgedehnt und zuletzt eine Frist bis zum April 2018 gesetzt. Zertifikaten, die nicht CT-qualifiziert sind und die nach diesem Datum ausgestellt werden, wird in Chrome nicht vertraut. GlobalSign hat im Hintergrund bereits daran gearbeitet, dass alle Zertifikate mit CT ausgestattet werden - Extended Validation (EV) seit 2015, Domain Validated (DV) seit August 2016 und Organisation Validated (OV) ab Oktober 2017 - GlobalSign-Kunden sind damit für den Fristablauf seitens Google gerüstet.

  • Wo ist der Authentifizierungsprozess fehlbar?

    Ich habe den größten Teil meines beruflichen Lebens damit verbracht Authentifizierungslösungen zu programmieren, zu implementieren, weiterzuentwickeln und zu patentieren. Daher nehme ich mir das Recht heraus zu sagen, letzten Endes funktioniert Authentifizierung einfach nicht. Mit "funktionieren" im engeren Sinne meine ich, dass es zu 100Prozent garantiert ist, dass es sich tatsächlich um eine vertrauenswürdige Identität handelt, wenn eine Benutzeridentität von einer Authentifizierungslösung an den betreffenden Partner weitergeleitet wird. Und genau das lässt sich nicht garantieren. Es lässt sich belegen, dass und wie der eigentliche Validierungsprozess innerhalb der Authentisierung funktioniert. Das bedeutet, wir verifizieren mathematisch und empirisch, dass die von einem Authentifizierungsmechanismus zusammengestellte Entität mit den Werten übereinstimmt, die in der Datenbank des akzeptierenden Dritten gespeichert sind, also "matched". Das kann ein Passwort sein, ein Einmal-Passwort, OTP, X.509-basierte Verschlüsselung, biometrische Merkmale, mobile Push-Werte oder eine Gesichtserkennung. In einem Satz: Der Authentisierungsprozess lässt sich validieren und damit auch, dass das technische System korrekt arbeitet.

  • Rollende Sicherheitslücken

    Viele Fahrzeuge sind heutzutage längst zu rollenden Computern geworden, denn bereits jetzt stecken in der Software eines modernen Oberklasse-PKW etwa 100 Millionen Codezeilen. Zum Vergleich: Die Flugsoftware einer Boeing 787 Dreamliner kommt mit etwa 14 Millionen Zeilen aus. Die Erwartungen an das zukünftige autonom fahrende Auto sind vielzählig: Mehr Sicherheit auf den Straßen, mehr Komfort, beispielsweise durch selbstständiges Einparken, die Nutzung eines Autopiloten im Stau oder komplett fahrerlose Roboterautos, welche im Car-Sharing-Verfahren neue Infrastrukturmöglichkeiten bieten könnten. Dem gegenüber stehen die Ängste: Bei Technikfehlern nur noch ein hilfloser Passagier an Board zu sein oder Opfer eines Hacker-Angriffs zu werden.

  • Warum BYOD an den Geräten scheitert

    Bring Your Own Device (BYOD) genießt im Geschäftsumfeld seit einigen Jahren den Ruf als innovatives Konzept. Der zeitlich uneingeschränkte Zugang zu Unternehmensdaten kann Firmen verbesserte Effizienz in den Arbeitsabläufen bescheren und den Mitarbeitern wiederum mehr Komfort im täglichen Arbeiten. Sie können auf ihren gewohnten Geräten arbeiten, zu flexiblen Arbeitszeiten. Insbesondere bei neu gegründeten Unternehmen, in denen die Mitarbeiter viel unterwegs sind, wird es überaus geschätzt, wenn kein weiteres, unternehmenseigenes Gerät mitgeführt werden muss. Die Zufriedenheit der Mitarbeiter mit der Arbeitsweise wiederum trägt auch zur Attraktivität des Unternehmens bei.

  • Offensichtlich lukrativste Angriffsmethode

    In regelmäßigen Abständen sehen wir uns einer neuen Bedrohung gegenüber, die bei Angreifern gerade Konjunktur hat. Gezielte Langzeitangriffe, sogenannte Advanced Persistent Threats (APTs) beherrschen die Schlagzeilen und Unternehmen beeilen sich, diese Attacken zu stoppen, deren Urheber sich gut versteckt durch das Netzwerk bewegen. Neben Phishing ist Ransomware die erfolgreichste und offensichtlich lukrativste Angriffsmethode für Cyber-Kriminelle. Schätzungen zufolge kosteten Ransomware-Scams die Opfer allein im letzten Jahr fast 1 Milliarde US-Dollar weltweit. Und es ist kein Wunder, dass sie so gut funktionieren: Sie beruhen auf dem althergebrachten Modell der Schutzgelderpressung, das bereits lange von Banden und der Mafia genutzt und jetzt in digitalem Format erfolgreich wieder aufgelegt wird. Die digitale Transformation ist nicht nur für Unternehmen Realität, sondern längst auch für Kriminelle eine lohnenswerte Einnahmequelle.