CWE-Referenz › CWE-1259: Improper Restriction of Security Token Assignment
CWE-1259: Improper Restriction of Security Token Assignment
CWE ID: 1259
Name: Improper Restriction of Security Token Assignment
Beschreibung
Der System-On-A-Chip (SoC) implementiert einen Security Token Mechanismus, um zu differenzieren, welche Aktionen erlaubt oder verboten sind, wenn eine Transaktion von einer Entität ausgeht. Allerdings sind die Security Tokens unzureichend geschützt.
Erweiterte Beschreibung
System-On-A-Chips (SoCs) implement Security Tokens, die dazu dienen, Aktionen zu differenzieren und zu identifizieren, welcher Agent sie initiiert hat. Diese Aktionen können eine von mehreren Direktiven sein: ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’ usw. Security Tokens werden jedem Agenten im System zugewiesen, der in der Lage ist, eine Aktion zu generieren oder eine Aktion von einem anderen Agenten zu empfangen. Mehrere Security Tokens können einem Agenten zugewiesen werden und können basierend auf dem Vertrauenslevel oder den erlaubten Privilegien des Agenten einzigartig sein. Da Security Tokens integral für die Aufrechterhaltung der Sicherheit in einem SoC sind, müssen sie ordnungsgemäß geschützt werden. Eine häufige Schwachstelle, die Security Tokens betrifft, ist die unsachgemäße Beschränkung der Zuweisung an vertrauenswürdige Komponenten. Folglich kann ein unzureichend geschützter Security Token von einem bösartigen Agenten programmiert werden (d.h., der Security Token ist mutable), um die Aktion so zu fälschen, als ob sie von einem vertrauenswürdigen Agenten stammt.
Verwandte Schwachstellen
Ist Ihre IT-Infrastruktur betroffen?
Schwachstellen wie CWE-1259: Improper Restriction of Security Token Assignment werden von Angreifern gezielt gesucht — meist automatisiert und ohne Rücksicht darauf, wie groß das betroffene Unternehmen ist. Ob eine solche Lücke bei Ihnen tatsächlich offen steht, lässt sich nur durch Prüfung feststellen:
- Schwachstellen-Scan — wiederkehrende Prüfung Ihrer Infrastruktur auf bekannte Lücken wie diese
- Penetrationstest — manuelle Prüfung eigener Software auf Schwachstellen, die kein Werkzeug findet
- Threat Modeling — Schwachstellenklassen im Entwurf vermeiden, statt sie später zu suchen