Risikoanalyse von Twitter

937 Aufrufe

Veröffentlicht am

Veröffentlicht in: Karriere
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
937
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
326
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 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
  • Risikoanalyse von Twitter

    1. 1. Risikoanalyse von Twitter Abschlussvortrag zur Diplomarbeit Christian Hops
    2. 2. Gliederung <ul><li>Einführung </li></ul><ul><li>Twitter </li></ul><ul><li>Grundlagen der Risikoanalyse </li></ul><ul><li>Risikoanalyse von Twitter </li></ul><ul><li>Fragen </li></ul>
    3. 3. Twitter: Allgemeines & Zahlen <ul><li>Mikroblogging </li></ul><ul><li>190 Mio Nutzer </li></ul><ul><li>140 Mio Nachrichten/Tag </li></ul><ul><li>300.000 registrierte Drittanwendungen </li></ul>
    4. 4. Twitter: Funktionen
    5. 5. Grundlagen: Risikoanalyse <ul><li>Risikopotential als Eintrittswahrscheinlichkeit multipliziert mit Konsequenzen </li></ul><ul><li>Eintrittswahrscheinlichkeit </li></ul><ul><ul><li>Angreifer </li></ul></ul><ul><ul><li>Schwachstelle </li></ul></ul><ul><li>Konsequenzen </li></ul><ul><ul><li>Verletzte Schutzziele </li></ul></ul><ul><ul><li>Verletzte Benutzer-Annahmen </li></ul></ul><ul><li>Strategien zum Umgang mit Risiken </li></ul>
    6. 6. Prämissen der Risikoidentifizierung <ul><li>Mittel: Literaturrecherche & Analyse des Front-Ends </li></ul><ul><li>Vor allem Risiken durch Sicherheitslücken in der Software </li></ul><ul><li>Beschränkung auf Webanwendung und API </li></ul>
    7. 7. Code-Injection <ul><li>Shell Injection </li></ul><ul><li>Programmcode Injection </li></ul><ul><li>SQL Injection </li></ul><ul><li>JSON Injection </li></ul><ul><li>File Inclusion </li></ul><ul><li>Cross-Site Scripting (XSS) </li></ul>
    8. 8. Angriffe auf Benutzer <ul><li>Cross-Site Request Forgery (XSRF) </li></ul><ul><li>Clickjacking </li></ul><ul><li>JSON Hijacking </li></ul>
    9. 9. Angriffe auf Dienste <ul><li>Distributed Denial of Service-Angriffe </li></ul><ul><li>DNS Hijacking </li></ul><ul><li>Kurz-URL Anbieter </li></ul><ul><li>Google Apps </li></ul>
    10. 10. Unzureichende Sicherheitspolitik <ul><li>Verschicken von geheimen Zugangsdaten per Mail </li></ul><ul><li>Administrationstools </li></ul><ul><li>Versteckte Befehle </li></ul><ul><li>Unsichere Serverkonfiguration </li></ul>
    11. 11. Unsicheres Sitzungsmanagement <ul><li>Sitzungstoken bleibt gültig </li></ul><ul><li>Mithören des Sitzungstokens </li></ul>
    12. 12. Angriffe auf Zugangsdaten <ul><li>Zugangsdaten per Brute-Force erraten </li></ul><ul><li>Phishing-Angriff per </li></ul><ul><ul><li>Mail </li></ul></ul><ul><ul><li>Tweet </li></ul></ul><ul><ul><li>Direktnachricht </li></ul></ul><ul><ul><li>„ Sign in with Twitter“ auf Third-Party Webseite </li></ul></ul>
    13. 13. Schwachstellen durch Drittanwendungen <ul><li>Bösartige/Kompro-mittierte Anwendung </li></ul><ul><li>Zu grobe Rechtevergabe </li></ul><ul><li>Anwender kaum sensibilisiert </li></ul>
    14. 14. Risikobewertung: Nutzergruppen <ul><li>Bewertung des Risikopotentials abhängig vom Nutzertyp </li></ul><ul><li>Fünf Nutzergruppen </li></ul><ul><ul><li>passive Nutzer </li></ul></ul><ul><ul><li>aktive Nutzer </li></ul></ul><ul><ul><li>Organisationen </li></ul></ul><ul><ul><li>Journalisten </li></ul></ul><ul><ul><li>Entwickler von Third-Party Anwendungen </li></ul></ul>
    15. 15. Bewertung eines einzelnen Risikos
    16. 16. Bewertungsmuster
    17. 17. Ergebnisse der Bewertung I <ul><li>Passive Benutzer </li></ul><ul><ul><li>18 Risiken </li></ul></ul><ul><ul><li>Top: Code-Injection, unzureichende Sicherheitspolitik </li></ul></ul><ul><li>Aktive Benutzer </li></ul><ul><ul><li>42 Risiken </li></ul></ul><ul><ul><li>Top: Angriffe auf Zugangsdaten, unzureichende Sicherheitspolitik </li></ul></ul><ul><li>Organisationen </li></ul><ul><ul><li>Zusätzliches Risiko: Austausch von Twitter-Zugangsdaten innerhalb der Organisation </li></ul></ul>
    18. 18. Ergebnisse der Bewertung II <ul><li>Journalisten </li></ul><ul><ul><li>42 Risiken </li></ul></ul><ul><ul><li>Astroturfing: Von Platz 38 auf 33 </li></ul></ul><ul><li>Entwickler von Drittanwendungen </li></ul><ul><ul><li>7 Risiken </li></ul></ul><ul><ul><li>Top: Kompromittierung der Anwendung, zu grobe Rechtevergabe </li></ul></ul>
    19. 19. Gegenmaßnahmen <ul><li>17 von 44 identifizierten Risiken können ausschließlich durch Twitter begegnet werden </li></ul><ul><li>Oftmals ungenügend umgesetzt </li></ul><ul><li>Vorgeschlagene Gegenmaßnahmen wurden im letzten halben Jahr implementiert </li></ul>
    20. 20. Fragen & Diskussion

    ×