![Gliederung ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Risikoanalyse von Twitter
- 1. Risikoanalyse von Twitter Abschlussvortrag zur Diplomarbeit Christian Hops
- 15. Bewertung eines einzelnen Risikos
- 16. Bewertungsmuster
Hinweis der Redaktion
- Mikroblogging: -> Juli 2006 -> 140 Zeichen -> Echtzeit (Schnelllebig: 96,9% der Reaktionen innerhalb 1. Stunde) -> Ubiquität: SMS, Mail, Web, RSS, Clients für mob. Geräte, API (+ Interaktion mit anderen Webanwendungen)
- * Eingabe * Timeline * Favorisieren, Antworten, Retweeten (mit Beispiel) * Kurz-URLs * Follower & Following * Trends * Drittanbieter-Anwendungen (last.fm) * Direktnachrichten
- *Priorisierung der Risiken Angreifer: * Benötigte Fähigkeiten des Angreifers (AF) * Motivation des Angreifers (AM) * benötigte Ressourcen, um Sicherheitslücke zu finden und auszunutzen (AR) * Größe der Gruppe von Angreifern (AG) Schwachstelle: * Möglichkeit der Entdeckung/Ausnutzung der Schwachstelle (SA) * Bekanntheit der Schwachstelle bei Angreifern (SB) Schutzziele: * Vertraulichkeit * Integrität * Verfügbarkeit * Zurechenbarkeit Benutzer: * Anonymität * Echtheit der Nachrichten * Malware-Infektion Gegenmaßnahmen: Risikovermeidung (teuer): Einsatz einer anderen Software, Risikominimierung: Backup/USV, Risikoakzeptierung (schwierig): XSS-Schwachstelle eines privaten Feldes, Risikotransfer(AGB, Versicherung)
- *Keine Quelltextanalyse, keine firmen-iInternen Dokumente *Und nicht: Organisation, Standort, Personal *Und nicht: Risiken aus der Nutzung von Drittanwendungen
- * Typische Angriffe auf Webanwendungen * JSON Injection: Einfügen von zusätzlichen Elementen in JSON-Ressourcen * XSS-Tweet aus September 2010 *XSS: im Kontext der Webanwendung ausgeführt, Umgehung der Same Origin Policy * XSS-Schwachstelle ausnutzen, um ** Eingegebene Zugangsdaten unzuleiten ** Links auf schadhafte Seite setzen ** Weiterleiten des Sitzungstoken ** Abfragen von Browser-Eigenschaften -> Ausnutzung der Schwachstellen zur Installation von Malware
- * XSRF: Der bei Twitter angemeldete Benutzer wird auf die Seite des Angreifers gelockt, auf der dem Besucher eine Anfrage für Twitter untergeschoben wird (z.B. Schreiben eines Tweets). * Clickjacking: Die Seite des Angreifers ist so präperiert, dass im IFrame eine transparente Seite von Twitter geladen wird. Klickt ein Opfer auf einen Link auf der sichtbaren Seite, wird der Klick auf der transparenten Seite ausgeführt. * JSON Hijacking: Wie beim XSRF wird beim JSON Hijacking der Umstand ausgenutzt, dass das Opfer bei Twitter angemeldet ist. Es werden private Daten im JSON-Format durch die Seite des Angreifers abgefragt und verarbeitet.
- * Twitter und die Benutzer von Twitter verwenden teilweise externe Dienste die ebenfalls angreifbar sind * Google Apps -> @twitter.com Mail-Adresse -> Social Engineering Angriff
- * Zugangsdaten sind nicht geheim, sondern werden ausgetauscht -> besser: Zugangsdaten sind geheim und Rechte werden erweitert * Server-Passwort für Twitter war „password“ * Admintools wurden bereits 2x gehackt * Webserver gaben Statusinformationen aus * FTC hat Sicherheitsaudits bei Twitter etabliert
- * Der Sitzungstoken sollte normalerweise *** bei der Anmeldung generiert werden (ohne Vorgabe, da sonst Fixation) *** zufällig (& aus keinen Daten/Infos zusammengesetzt sein), Angreifer darf keinen gültigen ST erzeugen können *** bei Abmeldung oder wenn Benutzer für eine gewisse Dauer inaktiv ist, sollte der Sitzungstoken seine Gültigkeit verlieren
- * Brute-Force Schutz mit CAPTCHA, die zu 30% gelöst werden können. Problem: Angreifer hat beliebig viele Versuche, um das CAPTCHA zu lösen UND Twitter meldet zurück, ob das CAPTCHA erfolgreich gelöst wurde. * Direktnachrichten können von bösartigen Drittanwendungen verwendet werden (privater Kanal) * “Sign in with Twitter“ -> nichts ungewöhnliches, dass Webseiten Twitter-Zugangsdaten abfragen -> Angreifer könnte Replik dieser Abfrage ohne Einblendung der falschen Adresse bauen
- ** Auch Zugriff auf Direktnachrichten über API abrufbar ** Keine Feingliederung des Zugriffs ** Keine Sensibilisierung (100.000 Anwender gaben Spiele-App Zugriff) ** Auch ausschließlich lesende Anwendungen verlangen schreibenden Zugriff (weil oAuth-Zugriff auf Twitter nicht ausgeweitet werden kann)
- * passive Nutzer haben keine vertraulichen Daten bei Twitter gespeichert * Organisationen mit vielen Followern geben ein lohnenderes Ziel ab (Motivation) * Journalisten
- Vorgehen bei der Bewertung: * Definition eines Standardfalls * Berücksichtigung: Relationen verschiedener Risiken * Berücksichtigung: Relationen eines Risikos verschiedener Nutzergruppen AF: Benötigte Fähigkeiten AM: Angreifer-Motivation AR: Benötigte Ressourcen AG: Größe der Angreifer-Gruppe SA: Ausnutzungswahrscheinlichkeit SB: Bekanntheit der Schwachstelle TV: Verlust von Vertraulichkeit TI: Integrität TA: Verfgbarkeit TZ: Zurechenbarkeit BA: Anonymität BE: Echtheit der Nachrichten BP: Auswirkungen auf Betriebssystem/Programme (Malware)
- * Die Nutzergruppen Aktive Nutzer, Organisationen & Journalisten sind sehr ähnlich * Man könnte meinen, dass Risiken bei Organisationen und Journalisten immer ein höheres Potential aufweisen, denn diese Konten haben mehr Follower * Gleich bleibendes Potential: Bedrohungen, die nicht zielgerichtet gegen eine bestimmte Nutzergruppe verwendet werden * Sinkendes Potential: Es sind spezielle Ressourcen nötig, um einen erfolgreichen Angriff auf Organisationen/Journalisten durchzuführen. Ein breit angelegter Angriff auf die Anwender ist erfolgversprechender.
- * Passiv -> Aktiv: Vertrauliche Daten * Passiv -> Aktiv: Code-Injection ist serverseitig handhabbar; Angriffe auf Benutzer gefährlicher, da User sensibilisiert sein muss; Kompromittierung der Zugangsdaten hat fatale Auswirkungen
- * In der Dipl.arbeit werden zu den 44 Risiken dienst- sowie clientseitig GM vorgeschlagen -> das würde den Rahmen dieses Vortrags sprengen * Bei 17 Risiken können keine clientseitigen Maßnahmen vorgeschlagen werden -> Benutzer sind von den GM von Twitter abhängig * Ungenügende Umsetzung: HTTPS optional, PIN für SMS optional, bekannte Sicherheitslücken werden nicht geschlossen (Sitzungsmanagement) * Vorgeschlagene Gegenmaßnahmen, die umgesetzt wurden: Für Direktnachrichten muss explizit Zugriff gewährt werden, URLs werden immer durch den Twitter-eigenen Kurz-URL Dienst umgewandelt und so geprüft, ob Link auf infizierte Malware-Seite zeigt