Zum Hauptinhalt springen

11. Sicherheitsüberlegungen

Dieser Abschnitt analysiert die möglichen Bedrohungen für das Protokoll. Er soll Protokoll- und Anwendungsentwickler über die Sicherheitsgrenzen von CoAP informieren, wie es in diesem Dokument beschrieben ist. Da CoAP eine Teilmenge der Funktionen von HTTP/1.1 realisiert, sind auch die Sicherheitsüberlegungen in Abschnitt 15 von [RFC2616] für CoAP relevant. Dieser Abschnitt konzentriert sich auf die Beschreibung von Beschränkungen, die für CoAP spezifisch sind.

11.1. Parsen des Protokolls und Verarbeiten von URIs​

Eine netzwerkseitig exponierte Anwendung kann Schwachstellen in ihrer Verarbeitungslogik für eingehende Pakete aufweisen. Komplexe Parser sind als wahrscheinliche Quelle solcher Schwachstellen bekannt, etwa die Fähigkeit, einen Knoten aus der Ferne zum Absturz zu bringen oder sogar beliebigen Code aus der Ferne auf ihm auszuführen. CoAP versucht, die Möglichkeiten zur Einführung solcher Schwachstellen zu verringern, indem es die Parser-Komplexität reduziert, dem gesamten Bereich kodierbarer Werte nach Möglichkeit eine Bedeutung gibt und Komplexität aggressiv reduziert, die häufig durch unnötige Wahlmöglichkeiten zwischen mehreren Darstellungen mit derselben Bedeutung entsteht. Ein Großteil der URI-Verarbeitung wurde auf die Clients verlagert, wodurch die Möglichkeiten zur Einführung von Schwachstellen in die Server weiter reduziert werden. Trotzdem ist der URI-Verarbeitungscode in CoAP-Implementierungen wahrscheinlich eine große Quelle verbleibender Schwachstellen und sollte mit besonderer Sorgfalt implementiert werden. Implementierungen der CoAP-Zugriffskontrolle müssen sicherstellen, dass sie keine Schwachstellen durch Diskrepanzen zwischen dem Code, der Zugriffskontrollentscheidungen aus einer URI ableitet, und dem Code, der schließlich die durch die URI adressierte Ressource bereitstellt, einführen. Der komplexeste verbleibende Parser dürfte der für das CoRE Link Format sein, obwohl auch dieses mit dem Ziel reduzierter Implementierungskomplexität entworfen wurde [RFC6690]. (Siehe auch Abschnitt 15.2 von [RFC2616].)

11.2. Proxying und Caching​

Wie in Abschnitt 15.7 von [RFC2616] erwähnt, sind Proxys von ihrer Natur her Man-in-the-Middle und brechen jeden IPsec- oder DTLS-Schutz, den ein direkter CoAP-Nachrichtenaustausch haben könnte. Sie sind daher interessante Ziele für das Brechen der Vertraulichkeit oder Integrität von CoAP-Nachrichtenaustauschen. Wie in [RFC2616] angemerkt, sind sie auch interessante Ziele für das Brechen der Verfügbarkeit.

Die Bedrohung für Vertraulichkeit und Integrität von Request/Response-Daten wird verstärkt, wenn Proxys auch cachen. Beachten Sie, dass CoAP keine der cacheunterdrückenden Cache-Control-Optionen definiert, die HTTP/1.1 zum besseren Schutz sensibler Daten bereitstellt.

Für eine Caching-Implementierung müssen alle Zugriffskontrollüberlegungen, die für das Stellen der Anfrage gelten würden, die den Cache-Eintrag erzeugt hat, auch auf den Wert im Cache angewendet werden. Dies ist sowohl für Clients relevant, die mehrere Sicherheitsdomänen implementieren, als auch für Proxys, die mehrere Clients bedienen können. Außerdem darf ein caching proxy gecachte Werte nicht (MUST NOT) für Anfragen verfügbar machen, die geringere Transportsicherheitseigenschaften haben als die, die der Proxy für die Durchführung der Anfragenweiterleitung überhaupt voraussetzen würde.

Anders als beim "coap"-Schema sind Antworten auf mit "coaps" gekennzeichnete Anfragen niemals "public" und dürfen daher nicht (MUST NOT) für gemeinsames Caching wiederverwendet werden, es sei denn, der Cache ist in der Lage, äquivalente Zugriffskontrollentscheidungen zu treffen wie diejenigen, die zu dem Cache-Eintrag geführt haben. Sie können jedoch in einem privaten Cache wiederverwendet werden, wenn die Nachricht in CoAP standardmäßig cachefähig ist.

Schließlich kann ein Proxy, der Separate Responses (im Gegensatz zu piggybacked Responses) an mehrere ursprüngliche Anfrager verteilt, eine zusätzliche Verstärkung bewirken (siehe Abschnitt 11.3).

11.3. Risiko der Verstärkung​

CoAP-Server antworten auf ein Anfragepaket im Allgemeinen mit einem Antwortpaket. Dieses Antwortpaket kann deutlich größer sein als das Anfragepaket. Ein Angreifer könnte CoAP-Knoten nutzen, um ein kleines Angriffspaket in ein größeres Angriffspaket zu verwandeln, ein Ansatz, der als Verstärkung (amplification) bekannt ist. Es besteht daher die Gefahr, dass CoAP-Knoten durch die Ausnutzung der verstärkenden Eigenschaften des Protokolls in Denial-of-Service-Angriffe (DoS) verwickelt werden könnten: Ein Angreifer, der versucht, ein Opfer zu überlasten, aber in der Menge des von ihm erzeugbaren Verkehrs begrenzt ist, kann die Verstärkung nutzen, um eine größere Verkehrsmenge zu erzeugen.

Dies ist besonders problematisch bei Knoten, die NoSec-Zugriff ermöglichen, für einen Angreifer erreichbar sind und auf potenzielle Opfer (z. B. im allgemeinen Internet) zugreifen können, da das UDP-Protokoll keine Möglichkeit bietet, die im Anfragepaket angegebene Quelladresse zu überprüfen. Ein Angreifer muss nur die IP-Adresse des Opfers in die Quelladresse eines geeigneten Anfragepakets setzen, um ein größeres, an das Opfer gerichtetes Paket zu erzeugen.

Als mildernder Faktor werden viele eingeschränkte Netzwerke nur in der Lage sein, eine kleine Verkehrsmenge zu erzeugen, was CoAP-Knoten für diesen Angriff weniger attraktiv machen kann. Die begrenzte Kapazität des eingeschränkten Netzwerks macht das Netzwerk selbst jedoch zu einem wahrscheinlichen Opfer eines Verstärkungsangriffs.

Daher sollten (SHOULD NOT) in der Antwort keine großen Verstärkungsfaktoren bereitgestellt werden, wenn die Anfrage nicht authentifiziert ist. Ein CoAP-Server kann die Menge der Verstärkung, die er einem Angreifer bietet, reduzieren, indem er die Slicing-/Blocking-Modi von CoAP [BLOCK] verwendet und große Ressourcendarstellungen nur in relativ kleinen Slices anbietet. Beispielsweise könnte für eine 1000-Byte-Ressource eine 10-Byte-Anfrage zu einer 80-Byte-Antwort (mit einem 64-Byte-Block) statt zu einer 1016-Byte-Antwort führen, wodurch die bereitgestellte Verstärkung erheblich reduziert wird.

CoAP unterstützt außerdem die Verwendung von Multicast-IP-Adressen in Anfragen, eine wichtige Anforderung für M2M. Multicast-CoAP-Anfragen können die Quelle versehentlicher oder absichtlicher DoS-Angriffe sein, insbesondere über eingeschränkte Netzwerke. Diese Spezifikation versucht, die Verstärkungseffekte von Multicast-Anfragen zu reduzieren, indem sie einschränkt, wann eine Antwort zurückgegeben wird. Um die Möglichkeit böswilliger Nutzung zu begrenzen, sollten CoAP-Server Multicast-Anfragen nicht (SHOULD NOT) akzeptieren, die nicht auf irgendeine Weise authentifiziert werden können, sei es kryptografisch oder durch eine Multicast-Grenze, die die potenziellen Quellen einschränkt. Wenn möglich, sollte (SHOULD) ein CoAP-Server die Unterstützung für Multicast-Anfragen auf die spezifischen Ressourcen beschränken, bei denen die Funktion erforderlich ist.

Auf einigen Allzweck-Betriebssystemen, die eine POSIX-artige API [IEEE1003.1] bereitstellen, ist es nicht einfach, herauszufinden, ob ein empfangenes Paket an eine Multicast-Adresse gerichtet war. Während viele Implementierungen wissen werden, ob sie einer Multicast-Gruppe beigetreten sind, entsteht dadurch ein Problem für Pakete, die an Multicast-Adressen der Form FF0x::1 gerichtet sind, welche von jedem IPv6-Knoten empfangen werden. Implementierungen sollten (SHOULD) moderne APIs wie IPV6_RECVPKTINFO [RFC3542] verwenden, sofern verfügbar, um diese Feststellung zu treffen.

11.4. IP-Adressen-Spoofing-Angriffe​

Aufgrund des Fehlens eines Handshakes in UDP kann ein bösartiger Endpunkt, der Nachrichten im eingeschränkten Netzwerk frei lesen und schreiben kann (d. h. NoSec- oder PreSharedKey-Bereitstellungen mit einem Knoten-/Schlüsselverhältnis > 1:1), leicht einen einzelnen Endpunkt, eine Gruppe von Endpunkten sowie das gesamte Netzwerk angreifen, z. B. durch:

  1. das Fälschen einer Reset-Nachricht als Antwort auf eine Confirmable-Nachricht oder Non-confirmable-Nachricht, wodurch ein Endpunkt "taub" gemacht wird; oder

  2. das Fälschen eines ACK als Antwort auf eine CON-Nachricht, wodurch möglicherweise der Absender der CON-Nachricht an der Neuübertragung gehindert und die tatsächliche Antwort übertönt wird; oder

  3. das Fälschen der gesamten Antwort mit gefälschtem Payload/Optionen (dies hat unterschiedliche Auswirkungen: von der Störung einer einzelnen Antwort bis hin zu weitaus kühneren Angriffen auf die unterstützende Infrastruktur, z. B. das Vergiften von Proxy-Caches oder das Täuschen von Validierungs-/Nachschlage-Schnittstellen in Ressourcenverzeichnissen; allgemeiner gesagt ist jede Komponente, die globalen Netzwerkzustand speichert und CoAP als Nachrichtenmittel verwendet, um das Setzen oder Aktualisieren von Zustand zu handhaben, ein potenzielles Ziel.); oder

  4. das Fälschen einer Multicast-Anfrage für einen Zielknoten; dies kann zu Netzwerküberlastung/-kollaps, einem DoS-Angriff auf das Opfer oder einem erzwungenen Aufwecken aus dem Schlaf führen; oder

  5. das Fälschen von observe-Nachrichten usw.

Response-Spoofing durch Off-Path-Angreifer kann auch ohne Transportschichtsicherheit erkannt und abgemildert werden, indem ein nicht triviales, randomisiertes Token in der Anfrage gewählt wird (Abschnitt 5.3.1). [RFC4086] diskutiert Zufälligkeitsanforderungen für die Sicherheit.

Im Prinzip können andere Arten des Spoofings von CoAP nur dann erkannt werden, wenn die Semantik von Confirmable-Nachrichten verwendet wird, und zwar aufgrund unerwarteter Acknowledgement- oder Reset-Nachrichten, die vom getäuschten Endpunkt kommen. Dies erfordert jedoch das Verfolgen der verwendeten Message IDs, was nicht immer möglich ist, und außerdem wird die Erkennung meist erst verfügbar, nachdem der Schaden bereits eingetreten ist. Diese Art von Angriff kann durch die Verwendung anderer Sicherheitsmodi als NoSec verhindert werden.

Mit oder ohne Quelladress-Spoofing kann ein Client versuchen, einen Server zu überlasten, indem er Anfragen, vorzugsweise komplexe, an einen Server sendet; Adress-Spoofing macht das Zurückverfolgen und Blockieren dieses Angriffs schwieriger. Da die Kosten einer CON-Anfrage gering sind, lässt sich dieser Angriff leicht ausführen. Unter diesem Angriff kann ein eingeschränkter Knoten mit begrenzter Gesamtenergie diese Energie viel schneller als geplant erschöpfen (Battery-Depletion-Angriff). Wenn der Client außerdem eine Confirmable-Nachricht verwendet und der Server mit einer Confirmable Separate Response an eine (möglicherweise gefälschte) Adresse antwortet, die nicht antwortet, muss der Server für jede Antwort Puffer und Neuübertragungslogik bis zur Erschöpfung von MAX_TRANSMIT_SPAN zuweisen, wodurch es wahrscheinlicher wird, dass ihm die Ressourcen für die Verarbeitung legitimen Verkehrs ausgehen. Das letztere Problem kann etwas abgemildert werden, indem die Antwortrate begrenzt wird, wie in Abschnitt 4.7 diskutiert. Ein Angreifer könnte auch die Adresse eines legitimen Clients fälschen; dies könnte bewirken, dass der Server, wenn er Separate Responses verwendet, legitime Antworten an diesen Client wegen NSTART=1 blockiert. All diese Angriffe können durch die Verwendung eines anderen Sicherheitsmodus als NoSec verhindert werden, sodass nur Angriffe auf das Sicherheitsprotokoll selbst verbleiben.

11.5. Cross-Protocol-Angriffe​

Die Fähigkeit, einen CoAP-Endpunkt dazu zu bringen, Pakete an eine gefälschte Quelladresse zu senden, kann nicht nur für die Verstärkung genutzt werden, sondern auch für Cross-Protocol-Angriffe gegen ein Opfer, das an einer bestimmten Adresse (IP-Adresse und Port) auf UDP-Pakete lauscht. Dies würde wie folgt ablaufen:

  • Der Angreifer sendet eine Nachricht an einen CoAP-Endpunkt mit der gegebenen Adresse als gefälschter Quelladresse.

  • Der CoAP-Endpunkt antwortet mit einer Nachricht an die gegebene Quelladresse.

  • Das Opfer an der gegebenen Adresse empfängt ein UDP-Paket, das es nach den Regeln eines anderen Protokolls interpretiert.

Dies kann genutzt werden, um Firewall-Regeln zu umgehen, die eine direkte Kommunikation vom Angreifer zum Opfer verhindern, aber zufällig die Kommunikation vom CoAP-Endpunkt (der möglicherweise auch eine gültige Rolle im anderen Protokoll innehat) zum Opfer erlauben.

Ebenso können CoAP-Endpunkte Opfer eines Cross-Protocol-Angriffs werden, der über einen Endpunkt eines anderen UDP-basierten Protokolls wie DNS erzeugt wird. In beiden Fällen sind Angriffe möglich, wenn die Sicherheitseigenschaften der Endpunkte auf der Prüfung von IP-Adressen beruhen (und direkte, von außen mit gefälschten IP-Adressen gesendete Angriffe per Firewall abgeschirmt werden). Im Allgemeinen sind UDP-basierte Protokolle aufgrund ihres fehlenden Kontexts relativ leichte Ziele für Cross-Protocol-Angriffe.

Schließlich könnten auf andere Weise transportierte CoAP-URIs dazu genutzt werden, Clients dazu zu bringen, Nachrichten an Endpunkte anderer Protokolle zu senden.

Eine Gegenmaßnahme gegen Cross-Protocol-Angriffe ist die strikte Prüfung der Syntax empfangener Pakete, kombiniert mit ausreichenden Syntaxunterschieden. Als Beispiel könnte es helfen, wenn es schwierig wäre, einen DNS-Server dazu zu bringen, eine DNS-Antwort zu senden, die die Prüfungen eines CoAP-Endpunkts bestehen würde. Leider sind die ersten beiden Bytes einer DNS-Antwort eine ID, die der Angreifer wählen kann und die auf den interessanten Teil des CoAP-Headers abbildet, und die nächsten beiden Bytes werden dann als Message ID von CoAP interpretiert (d. h. jeder Wert ist akzeptabel). Die DNS-Zählwörter können als mehrere Instanzen einer (nicht existierenden, aber wählbaren) CoAP-Option 0 interpretiert werden, oder möglicherweise als Token. Die zurückgespiegelte Abfrage schließlich kann vom Angreifer so konstruiert werden, dass sie eine gewünschte Wirkung auf den CoAP-Endpunkt erzielt; die vom Server hinzugefügte Antwort (falls vorhanden) könnte dann einfach als zusätzlicher Payload interpretiert werden.

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Abbildung 15: DNS-Header ([RFC1035], Abschnitt 4.1.1) im Vergleich zur CoAP-Nachricht

Im Allgemeinen kann bei jedem Protokollpaar eines der Protokolle durchaus so entworfen worden sein, dass es einem Angreifer ermöglicht, die Erzeugung von Antworten zu bewirken, die wie Nachrichten des anderen Protokolls aussehen. Es ist oft viel schwieriger, das Fehlen praktikabler Angriffe sicherzustellen oder zu beweisen, als Beispiele zu erzeugen, die einen Angriff noch nicht vollständig ermöglichen, aber von kreativeren Köpfen weiterentwickelt werden könnten. Cross-Protocol-Angriffe können daher nur dann vollständig abgemildert werden, wenn Endpunkte vom Angreifer gewünschte Aktionen nicht allein auf der Grundlage des Vertrauens in die Quell-IP-Adresse eines Pakets autorisieren. Umgekehrt muss eine NoSec-Umgebung, die sich für die CoAP-Sicherheit vollständig auf eine Firewall verlässt, nicht nur die CoAP-Endpunkte per Firewall abschirmen, sondern auch alle anderen Endpunkte, die dazu gebracht werden könnten, mittels irgendeines anderen UDP-basierten Protokolls UDP-Nachrichten an CoAP-Endpunkte zu senden.

Zusätzlich zu den obigen Überlegungen gelten die Sicherheitsüberlegungen für DTLS in Bezug auf Cross-Protocol-Angriffe. Wenn beispielsweise dieselbe DTLS-Sicherheitsassoziation ("Verbindung") verwendet wird, um Daten mehrerer Protokolle zu übertragen, bietet DTLS keinen Schutz mehr gegen Cross-Protocol-Angriffe zwischen diesen Protokollen.

11.6. Überlegungen zu eingeschränkten Knoten​

Implementierer auf eingeschränkten Knoten haben oft keine gute Entropiequelle [RFC4086]. Ist dies der Fall, darf der Knoten nicht (MUST NOT) für Prozesse verwendet werden, die gute Entropie erfordern, wie etwa die Schlüsselgenerierung. Stattdessen sollten Schlüssel extern erzeugt und während der Fertigung oder Inbetriebnahme in das Gerät eingebracht werden.

Aufgrund ihrer geringen Rechenleistung sind eingeschränkte Knoten besonders anfällig für Timing-Angriffe. Bei der Implementierung kryptografischer Primitive muss besondere Sorgfalt walten.

Eine große Anzahl eingeschränkter Knoten wird in exponierten Umgebungen installiert werden und nur wenig Widerstand gegen Manipulation bieten, einschließlich der Wiedererlangung von Schlüsselmaterial. Dies muss bei der Festlegung des Umfangs der ihnen zugewiesenen Credentials berücksichtigt werden. Insbesondere kann die Zuweisung eines gemeinsamen Schlüssels an eine Gruppe von Knoten jeden einzelnen eingeschränkten Knoten zu einem Ziel machen, um die gesamte Gruppe zu untergraben.