DsiN-Blog

Der IT-Sicher­heitsblog für den Mit­tel­stand

Themen

Tipp des Monats

Machen Sie in nur zehn Minuten den IT-Sicher­heits­check von Deutschland sicher im Netz. Der Test liefert Hand­lungs­emp­feh­lungen, mit denen Sie die eigene IT-Sicher­heitslage ver­bessern können.

News­letter

Um neue Bei­träge regel­mäßig zu erhalten, können Sie hier unseren News­letter abon­nieren:

Neue Web-Tech­­no­­logien wirken auf die Pri­vat­sphäre

A‑SIT hat in einer Kurz­studie Aus­wir­kungen neuer Web-Tech­­no­­logien wie WebRTC und WebSo­ckets auf die Pri­vat­sphäre erforscht. Dabei stellte sich heraus, dass WebRTC nicht nur Informationen über das lokale Netzwerk liefert, sondern auch für DDOS-Attacken ver­wendet werden kann und die Iden­ti­fi­zierung von ein­zelnen Com­putern erleichtert. Dies hat zur Folge, dass bestehende Tracking­lö­sungen mittels neuer Web-Tech­­no­­logien noch weiter „ver­bessert“ werden können und die Pri­vat­sphären von Benut­ze­rinnen und Benutzern zusätz­lichen Gefahren aus­setzen.

 

Seit der Ent­wicklung des World Wide Webs wurden die Mög­lich­keiten und Wege, eine Besu­cherin bezie­hungs­weise einen Besucher einer Web­seite zu tracken, stetig wei­ter­ent­wi­ckelt. Tracking bezeichnet in diesem Falle, dass Akti­vi­täten von Nut­ze­rinnen und Nutzern im Internet auf­ge­zeichnet werden, um ihr Surf­ver­halten oder besuchte Web­seiten zu iden­ti­fi­zieren. Grund­sätzlich gibt es dabei zwei Mög­lich­keiten, eine Benut­zerin bezie­hungs­weise einen Benutzer zu tracken. Es kann am Web­server eine ID gene­riert werden, die anschließend an den Browser geschickt und lokal, im ein­fachsten Fall in soge­nannten Cookies, gespei­chert wird. Bei erneutem Anfragen an die­selbe Adresse wird diese ID aus­ge­lesen und wieder an den Web­server geschickt. Dadurch kann der Web­server den Browser wie­der­erkennen. Bei diesem Ansatz kann der Nutzer seine ID relativ leicht löschen und sich somit wieder anony­mi­sieren. Auch ist dieses Ver­fahren nur auf eine Domain beschränkt. Ein für example.domain gesetztes Cookie kann über example2.domain nicht abge­rufen werden.

Die zweite Mög­lichkeit besteht darin, einen Nutzer anhand der Eigen­schaften des von ihm genutzten Browsers wie­der­zu­er­kennen. Hierfür werden mög­lichst viele Infor­ma­tionen, wie bei­spiels­weise der User Agent, die ein­ge­stellte Sprache und Zeitzone, die Bild­schirm­auf­lösung, instal­lierte Schrift­arten und Brow­se­r­er­wei­te­rungen abge­fragt. Aus diesen Infor­ma­tionen wird ein Fin­ger­ab­druck des Browsers berechnet und als ID ver­wendet. Das Ziel von Tracking-Software ist es eine mög­lichst ein­deutige ID für die­selbe Browser-Instanz zu gene­rieren. Teil­weise erlauben diese Infor­ma­tionen auch das Gene­rieren der­selben IDs für mehrere Browser am selben PC.

A‑SIT hat in einer Kurz­studie Aus­wir­kungen neuer Web-Tech­­no­­logien wie WebRTC und WebSo­ckets auf die Pri­vat­sphäre erforscht, ins­be­sondere wie diese Tech­no­logien im Tracking­kontext ver­wendet werden können. Mit der Studie konnte A‑SIT belegen, dass WebRTC negative Aus­wir­kungen auf die Pri­vat­sphäre hat. So liefert WebRTC nicht nur Infor­ma­tionen über das lokale Netzwerk, sondern kann auch für DDOS-Attacken ver­wendet werden und die Iden­ti­fi­zierung von ein­zelnen Com­putern erleichtern. Dies hat zur Folge, dass bestehende Tracking­lö­sungen mittels neuer Web-Tech­­no­­logien noch weiter „ver­bessert“ werden können.

 

WebRTC

Web Real-Time Com­mu­ni­cation (WebRTC) ermög­licht die Echt­zeit­kom­mu­ni­kation zwi­schen zwei Browsern, ohne dass Daten über einen Server geschickt werden müssen. Ein Server wird nur zur Her­stellung der Ver­bindung benötigt. Primär wurde WebRTC zum Video und Audio Streaming zwi­schen End­ge­räten ent­wi­ckelt und bietet daher eine gute und ein­fache Inte­gration. Außerdem stellt die API Roh­­daten-Kanäle bereit, um beliebige Daten über­tragen zu können. Dadurch ermög­licht WebRTC bei­spiels­weise die Erstellung von brow­ser­ba­sierten Videokonferenz‑, Daten­­transfer- oder Chat-Anwen­­dungen.

WebRTC ver­sucht, unge­achtet der vor­herr­schenden Netz­werk­in­fra­struktur, eine direkte Ver­bindung zwi­schen zwei Browsern auf­zu­bauen. Befinden sich zwei Nodes also bei­spiels­weise im selben pri­vaten Netzwerk, so wird zuerst ver­sucht über dieses private Netzwerk eine Ver­bindung auf­zu­bauen. Schlägt dies fehl, wird ver­sucht, die Ver­bindung über die öffent­lichen Adressen her­zu­stellen. Falls keine direkte Ver­bindung möglich ist, kommen öffent­liche TURN Server ins Spiel. In diesem Fall ver­binden sich beide Nodes zu TURN Servern, welche wie­derum die Daten an das ent­spre­chende Gegenüber wei­ter­leiten. Um eine mög­lichst direkte Ver­bindung zu ermög­lichen muss WebRTC alle lokalen IP-Adressen (inklusive der pri­vaten Adressen) per Java­Script zugänglich machen. Zur Ermittlung von öffent­lichen Adressen werden externe STUN Server ver­wendet. Diese ant­worten auf Anfragen mit der IP-Adresse der anfra­genden Node. Auf diesem Wege können Nodes bei­spiels­weise hinter NAT-Gateways ihre öffent­liche IP-Adresse ermitteln.

Erfor­schen des lokalen Netz­werkes

Die Liste aller lokalen IP-Adressen kann auch wert­volle Infor­ma­tionen für eine Angrei­ferin bzw. einen Angreifer liefern. Nor­ma­ler­weise muss eine Angrei­ferin bzw. ein Angreifer zuerst den lokalen IP-Adres­s­­be­­reich erraten, um einen Netz­werkscan durch­führen zu können. Mittels WebRTC kann diese Infor­mation effi­zient gesammelt und benutzt werden, um Angriffe zu ver­bessern. Für einen Netz­werkscan könnte bei­spiels­weise die Java­script Anwendung jslan­scanner ver­wendet werden. Auch das Browser Explo­itation Framework (BeEF) Project könnte mittels der per WebRTC gewon­nenen Infor­ma­tionen ver­bessert werden. BeEF ist ein Framework, das unter anderem ein­zelne Geräte in einem lokalen Netzwerk iden­ti­fi­zieren kann.

WebRTC Fin­ger­printing

Die Liste der lokalen und öffent­lichen IP-Adressen kann außerdem zur Iden­ti­fi­zierung des Rechners ver­wendet werden. Die Liste umfasst häufig mehrere lokale und eine öffent­liche IP-Adresse. Die lokalen IP-Adressen werden unter anderem für den Zugriff auf das lokale Netzwerk benötigt, oft gibt es mehrere, z.B. LAN und WLAN. Für die Kom­mu­ni­kation mit vir­tu­ellen Rechnern (VMWare, Vir­tu­alBox, …) oder ange­schlos­senen Geräten (z.B. Mobil­te­lefon) wird auch häufig ein vir­tu­eller Adapter mit einer lokalen IP-Adresse ein­ge­richtet. Die gesam­melten IP-Adressen erlauben es einen Rechner zu iden­ti­fi­zieren. Wenn bei­spiels­weise kurz hin­ter­ein­ander Anfragen von der­selben öffent­lichen IP-Adresse kommen und eine oder mehrere lokale Adressen über­ein­stimmen, kann man mit großer Wahr­schein­lichkeit davon aus­gehen, dass es sich um Anfragen vom selben Rechner handelt. Dadurch können Anfragen, egal von welchem Browser sie kommen, bzw. ob der normale oder der private Modus ver­wendet wurde, dem­selben Rechner zuge­ordnet werden. Nebenbei bekommt man noch die Infor­mation, welche Rechner sich im selben Netzwerk befinden. Dazu muss die öffent­liche IP-Adresse über­ein­stimmen und zumindest eine lokale IP-Adresse sollte im gleichen Adress­be­reich liegen.

Dis­tri­buted Denial of Service (DDoS) Attacken

Um mittels WebRTC eine Ver­bindung zwi­schen zwei Nodes her­zu­stellen, ver­langt das Pro­tokoll, dass Nodes ihre eigene IP-Adresse, ver­wendete Ports und Pro­to­kolle, an die Gegen­stelle senden. Die Ver­bin­dungs­kan­di­daten des emp­fan­genden und des sen­denden Clients werden kom­bi­niert und für den Ver­bin­dungs­aufbau ver­wendet. Im Prozess des Ver­bin­dungs­aufbaus werden bereits Daten über­tragen. Wird nun ein kom­pro­mit­tierter Client ver­wendet, hat dieser die Mög­lichkeit, die über­tra­genen Ver­bin­dungs­daten zu mani­pu­lieren. Ein kom­pro­mit­tierter Client kann also andere Clients dazu bringen, Daten an beliebige IP-Adressen zu über­tragen. Eine Vielzahl von Para­metern kann variiert werden, um ein Optimum an Durchsatz zu erreichen. Während des Expe­ri­ments wurde ein maxi­maler Durchsatz von 0,8 Mbit/s erreicht. Durch die gleich­zeitige Ver­wendung vieler Nodes kann der Angriff deutlich ver­stärkt werden.

Fazit

Neue Web­tech­no­logien ermög­lichen es immer leis­tungs­stärkere Web­ap­pli­ka­tionen zu ent­wi­ckeln. Auf einigen Platt­formen sind sie bereits heute kaum noch von nativen Appli­ka­tionen zu unter­scheiden. Dieser Trend wird sich auch in Zukunft fort­setzen. Dennoch sollten sich Benut­ze­rinnen und Benutzer über die Impli­ka­tionen bei Ver­wendung dieser Appli­ka­tionen bewusst sein und den Zugriff auf diese Tech­no­logien nur selektiv ermög­lichen.  

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Andreas Reiter & Alex­ander Mar­salek, TU Graz / A‑SIT

Alex­ander Mar­salek ist seit 2013 an der TU Graz als Pro­jekt­mit­ar­beiter im Bereich IT-Sicherheit tätig. Im Rahmen seiner Akti­vi­täten erstellt er für das Zentrum für Sichere Infor­ma­ti­ons­tech­no­logie — Austria (A‑SIT) unter anderem Sicher­heits­ana­lysen.

Andreas Reiter ist seit 2013 an der TU Graz als Pro­jekt­mit­ar­beiter im Bereich IT-Sicherheit tätig. Im Rahmen seiner Akti­vi­täten unter­stützt er das Zentrum für Sichere Infor­ma­ti­ons­tech­no­logie — Austria (A‑SIT) im Bereich Cloud-Security.

A‑SIT ist ein gemein­nüt­ziger Verein, der den Gesetz­geber und Behörden bei der Infor­ma­ti­ons­si­cherheit unter­stützt. Mit­glieder sind das Öster­rei­chische Bun­des­mi­nis­terium für Finanzen, die Öster­rei­chische Natio­nalbank, die Bun­des­re­chen­zentrum GmbH und die TU Graz.

 

Koope­ra­ti­ons­partner

Für DATEV sind Daten­schutz und Daten­si­cherheit seit Gründung des Unter­nehmens zen­trale Ele­mente in der Geschäfts­po­litik. Daher enga­giert sich DATEV mit dem Blog für mehr IT-Sicherheit im Mit­tel­stand.